view Side-By-Side changes
Network Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
<draft-aboba-radius-02.txt>
5
Category: Experimental
<draft-aboba-radius-03.txt>
2 February 1998 1999
Lightweight Directory Access Protocol (v3):
Schema for the Remote Access Dialin User Service (RADIUS)
1. Status of this Memo
This document is an Internet-Draft. Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working docu-
ments documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute work-
ing working documents as Internet-Drafts.
Internet-Drafts Internet-
Drafts are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference mate-
rial material or to cite
them other than as ``work "work in progress.'' progress."
To learn the current status of any Internet-Draft, please check view the
``1id-abstracts.txt'' listing contained in the Internet-Drafts list Internet-Draft Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Directories, see
http://www.ietf.org/shadow.html.
The distribution of this memo is unlimited. It is filed as <draft-
aboba-radius-02.txt>,
aboba-radius-03.txt>, and expires August 1, 1998. 1999. Please send com-
ments comments
to the authors.
2. Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
3. Abstract
This document defines a schema for the Remote Access Dialin User Ser-
vice Service
(RADIUS). This schema makes it possible to integrate a RADIUS server
with an LDAP-based directory service, making it possible for an
organization to maintain a single store of user information. This con-
solidation
consolidation is desirable since it results in a reduction in the admin-
istrative
administrative workload, and eliminates the need to synchronize across mul-
tiple
multiple user information stores.
3.
Aboba Experimental [Page 1]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
4. Introduction
Today enterprises are looking to simplify the process of user adminis-
tration.
administration by replacing application-specific directories with a
unified directory service based on LDAP v3, described in [5]-[6].
Operating multiple stores of user information is unappealing, since this
may require rekeying of information or sychronization between multiple
stores, resulting in increased administrative costs. Maintaining
multiple stores also raises concerns about inconsistency and replication
delays.
With the advent of HR enterprise resource planning (ERP) and personnel
management systems, information on a user is typically entered at the
time of hiring, and is retained until termination. If an LDAP-based
directory is also deployed, this necessitates synchronization with the
of the personnel database in order to maintain consistency. Should the
enterprise then deploy NAS devices or layer 2 tunneling solutions, there
may be a need to add a RADIUS server or if extended
Aboba [Page 1]
INTERNET-DRAFT 5 February 1998 security is
required, a backend security server. Each of these may require their own
user information store.
Operating multiple stores of user information is not appealing, since
this may require rekeying of information or sychronization between
multiple stores, resulting in increased administrative costs. Main-
taining multiple stores also raises concerns about inconsistency and
replication delays. In order to avoid these problems, it is
desirable to consolidate stores of user information. One way this can be
achieved is to make it possible for RADIUS servers and security add-
ons add-ons
to store their user information in an LDAP-based directory.
This document is one of three related specifications which describe
how a RADIUS server may be integrated with an LDAP-based directory
service. Reference [12] describes a schema designed for tracking ses-
sions in progress. Such information can be useful for a variety of
purposes including security incident response; simultaneous usage con-
trol; or monitoring of connection quality, login time, packet size or
bandwidth usage. Since this data change frequently, dynamic attributes
must be employed as described in [9]. Reference [13] describes how
user credentials submitted during PPP authentication may be validated
by the RADIUS server.
This document defines an LDAP schema for the Remote Access Dialin User
Service (RADIUS). The RADIUS protocol, described in [6]-[8], [1]-[4], supports
authentication, authorization and accounting for dialup users. To date,
RADIUS servers have stored user data in a variety of ways, including
databases and flat files. A goal of this schema is tomake to make it possible
to add support for LDAP-based directory services to existing RADIUS
server implementations. In order to permit this schema to be used with a
wide range of directory service implementations, we it is necessary to
avoid reliance on features that have not been widely implemented, such
as multiple inheritance.
3.1. Objects and attributes
4.1. Administrative model
The RADIUS schema defined in this document requires support for sev-
eral new classes: radiusProfileClass, radiusPolicyClass, radiusDic-
tionaryClass, includes user object attributes, as
well as profile and eapDictionaryClass. The radiusProfileClass is used
to store RADIUS policy objects.
User object attributes relevant to groups of users. The radiusPol-
icyClass is are used to describe conditions under which a given profile in situations where it may be applied. The radiusDictionaryClass is used to store the RADIUS
Dictionary. This provides extensibility and allows RADIUS profile
objects to be self describing. The eapDictionaryClass is used to store
a list mapping EAP Types desirable
to names.
The attributes in radiusProfileClass fall into two categories:
attributes present override behavior supplied in the Access-Reply, and attributes representing
access constraints. An access constraint is a set of conditions profile, or where it is desired that
must
individual users be satisfied in order given an unique value for access to be granted. These are
expressed in the form of matching rules involving attributes present
in the Access-Reply, as well as other attributes such as the time of
day. an attribute. For example,
where static addresses are assigned, each user will typically have a matching rule involving the calledStationId and
different IP address. Similarly, where callback is used, callbackNumber
will typically differ between users.
Aboba Experimental [Page 2]
INTERNET-DRAFT 5 RADIUS Schema for LDAP v3 2 February 1998
time of day can be created in order 1999
However, it is not desirable to limit access depend exclusively on user object
attributes. Since it is likely that groups of users will tend to those calling a
given phone number during specified hours.
Attributes present in have
the Access-Reply are stored same parameter values, an implementation based solely on user-object
attributes results in unnecessary replication, and also makes it
difficult to change attributes for all members of a group.
To reduce the directory so
that the RADIUS server can retrieve them replication problem, enable more effective caching, and include them in
ease the
Access-Reply. Access constraints administrative burden, profile objects are stored in the directory so that
the RADIUS server required. Profiles
support definition of parameter sets which apply to a group of users in
a particular situation. Since it is expected that profiles will apply to
large group of users, they can test be effectively cached.
Network administrators typically manage the incoming Access-Request authorization process via
group assignments, and therefore will typically desire to determine
whether fit profiles
within the existing administrative model. In particular, it is highly
desirable to proceed with authentication, or immediately send allow an Access-
Reject. Note that only static attributes present in Access-Reply need
be stored in administrator to change the directory; attributes profile values
applying to a group without having to edit the user objects for each
member of the group.
Within this schema, the mapping from profiles to groups is achieved via
policy objects which are computed on contain the fly
can be recreated as needed.
The attributes in radiusPolicyClass represent conditions which that must
hold be satisfied for the a
profile indicated in radiusProfilePointer to be applied.
As with access constraints, these conditions may involve matching
rules applied to attributes in the Access-Request, assigned, as well as condi-
tions involving time of day, Nas-Port-Type, or group memberships.
For example, it a pointer to that profile. Group
membership may be desirable to give users different Session-Time
or Port-Limit attributes depending on included among the time conditions evaluated in assignment
of day, or group mem-
berships. This a profile. Thus, profile/group binding can be accomplished by creating policy expressions and
profiles for each time expressed as a
condition (group membership) resulting in assignment of day/group membership combination. Simi-
larly, it may a profile (the
profile for that group).
It should be desirable to require noted that analog and ISDN callers do
callback or call from a particular callingStationId, while this may policy objects are not make sense for users connecting over the only way to bind
profiles to groups, nor are they necessarily the most efficient. For
example, it is also possible to handle profile/group binding via a VPN. This can be accom-
plished
table, or even by creating a encoding policy expression restrictions on a user certificate.
The later may prove popular in the long term, given that returns different pro-
files, depending today many
firms already encode privileges relating to time of day and
organizational function on nasPortType.
3.2. Administrative model employee badges.
4.2. Objects and attributes
The RADIUS schema defined in this document includes user object attributes,
as well as profile requires support for several
new classes: radiusProfileClass, radiusPolicyClass,
radiusDictionaryClass, and policy objects.
User object eapDictionaryClass. The radiusProfileClass is
used to store RADIUS attributes are relevant to groups of users. The
radiusPolicyClass is used in situations where it may be desir-
able to override behavior supplied in describe conditions under which a profile, or where it is
desired that individual users be given an unique value for an
attribute. For example, where static addresses are assigned, each user
will typically have a different IP address; similarly, where callback
is used, callbackNumber will typically differ between users.
In the early versions of this document, it was envisaged that all
attributes would
profile may be contained within the user object. This is wasteful
because it applied. The radiusDictionaryClass is likely that groups of users will tend used to have store the same
parameter values. Thus a schema based solely on user-object results in
unnecessary replication,
RADIUS Dictionary. This provides extensibility and also makes it difficult allows RADIUS profile
objects to change
attributes for all members of a group.
To reduce the replication problem, enable more effective caching, and
ease the administrative burden, profiles were added to the schema.
Profiles support definition of parameter sets which apply be self describing. The eapDictionaryClass is used to store a group
of users in a particular situation. Since it
mapping EAP types to user friendly names. EAP is expected that profiles described in [7].
Aboba Experimental [Page 3]
INTERNET-DRAFT 5 RADIUS Schema for LDAP v3 2 February 1998
will apply to large group of users, they can be effectively cached.
Reference [14] describes how object caching can be supported within
LDAP-based directory services.
In an earlier version 1999
The attributes in radiusProfileClass fall into two categories:
attributes present in the Access-Reply, and attributes representing
access constraints. An access constraint is a set of this document, profiles could conditions that
must be related satisfied in order for access to
users via the radiusProfilePointer attribute included be granted. These are expressed
in the user
object. While this method form of mapping users to profiles is still sup-
ported matching rules involving attributes present in this revision, this approach does not scale well, since it
requires administrators to modify the directory entries for each user,
Access-Reply, as well as other attributes such as the time of day. For
example, a matching rule involving the calledStationId and time of day
can be created in order to add limit access to those calling a given phone
number during specified hours.
Attributes present in the required radiusProfilePointer. Network administra-
tors typically manage Access-Reply are stored in the authorization process via group assignments, directory so
that the RADIUS server can retrieve them and therefore will typically desire to fit profiles within include them in the exist-
ing administrative model. In particular, it is highly desirable to
allow an administrator to change Access-
Reply. Access constraints are stored in the profile values applying to a
group without having to edit directory so that the user objects for each member of
RADIUS server can test the
group.
Several methods for binding a profile incoming Access-Request to a group suggest themselves.
Within this schema, determine whether
to proceed with authentication, or immediately send an Access-Reject.
Note that only static attributes present in Access-Reply need be stored
in the mapping is achieved via a policy object directory; attributes which
may include group membership among are computed on the conditions evaluated in assign-
ment of a profile. It should fly can be noted that policy objects are not
recreated as needed.
The attributes in radiusPolicyClass represent conditions which must hold
for the
only way profile indicated in radiusProfilePointer to bind profiles be applied. As
with access constraints, these conditions may involve matching rules
applied to groups, nor are they necessarily attributes in the most
efficient. Access-Request, as well as conditions
involving time of day, Nas-Port-Type, or group memberships.
For example, it is also possible may be desirable to handle profile/group
binding via a table, give users different Session-Time or even by encoding policy restrictions
Port-Limit attributes depending on a user
certificate. The later may prove popular in the long term, given that
today many firms already encode privileges relating to time of day day, or group
memberships. This can be accomplished by creating policy expressions and
organizational function on employee badges.
The profile/group binding method chosen in this document was selected
primarily since
profiles for each time of day/group membership combination. Similarly,
it proved to may be desirable to require that analog and ISDN callers do callback
or call from a degenerate case of the general con-
ditional profile problem. In particular callingStationId, while this schema, we support the conditional
application of profiles, with the policy object expressing the condi-
tions that must be satisfied may not make
sense for users connecting over a profile to be executed. Thus, pro-
file/group binding virtual private network (VPN). This
can be expressed as a condition (group membership)
resulting in assignment of accomplished by creating a profile (the profile for policy expression that group).
3.2.1. returns
different profiles, depending on nasPortType.
4.2.1. User object attributes
This schema proposes addition of attributes to the user object. As noted
earlier, to enhance scalability, it is recommended that user object
attributes only be used in cases where profile overide is nec-
essary, necessary, or
assignment of per-user attributes is required. Overide can in principle
be required for any attribute that may be included in the Access-Reply,
and so these attributes are among those that are added to the user
object. Examples of attributes that may be assigned on a per-user basis
include radiusFramedIPAddress, radiusCallbackNumber and
radiusFramedRoute.
Aboba Experimental [Page 4]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
Since many RADIUS parameters are expected to be identical for a group of
users, typically the user object will contain a small set of Radius
attributes. No user object attributes may be present if profiles are
being applied conditionally and no per-user values are required.
Aboba [Page 4]
INTERNET-DRAFT 5 February 1998
If it desired that a profile be unconditionally executed, then this can
be achieved either by creating a policy object with a radiusPro-
filePointer
radiusProfilePointer attribute but no npConstraint attribute, or by
adding radiusPolicyPointer (a distinguished name pointing to a RADIUS
Profile Object) as a user object attribute.
3.2.2.
4.2.2. Profiles
Profile attributes fall into two major categories. One category of
attributes are static attributes that may be returned in an Access-
Reply. These attributes use a prefix of 'radius' and are included
within the profile so that the RADIUS server may copy the values into
the Access-Reply.
Another category of attributes are those which represent conditions that
must be satisfied for an Access-Accept to be sent. These attributes use
a prefix of 'np', which stands for Network Policy. These attributes
include npIPPoolName, npSessionsAllowed, npEAPType, npConstraint, and
npAuthenticationType. npSessionsAllowed is used to limit the number of
simultaneous sessions; npAuthenticationType indi-
cates indicates the acceptable
authentication types (PAP, CHAP, MS-CHAP, EAP); npEAPType indicates the
EAP-Type to be used to authenticate the user if EAP is negotiated as an
authentication type; npIPPoolName indicates the name of the IP address
pool that should be used in assigning the user's IP address.
npConstraint is a string attribute used to express constraints based on
time of day, or attributes present in the Access-
Request, Access-Request, such as NAS-Port-Type NAS-
Port-Type or NAS-Identifier.
Within this document, we allow profiles to include pointers to other
profiles, so that profiles may form a linked list. This allows a hier-
archy
hierarchy of profiles to be provided. More specific attributes overide
more general ones.
3.2.3.
4.2.3. Example
All BIGCO employees are required to use token card authentication, and
thus in the company profile the radiusAuthenticationType attribute is
set to only allow EAP, and the radiusEAPType attribute is set for
BIGCO's token card type. BIGCO also sets up a marketing profile pro-
viding
providing a radiusSessionTimeout value of 30 minutes, a radiusPortLimit
of one, and radiusFramedIpAddress set to indicate dynamic address
Aboba Experimental [Page 5]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
allocation. However, Fred requires a static IP address, and thus his
user object will contain a radiusFramedIpAddress attribute.
Since BIGCO profiles are unconditionally applied, a policy object with a
condition of (group == marketing) is used to assign a profile to
marketing personnel. Another policy object of lower priority is used
with no npConstraint attribute in order to assign a default profile.
Aboba [Page 5]
INTERNET-DRAFT 5 February 1998
3.3.
4.3. Policy support
The schema described in this document provides for the conditional
application of a profile to a user via policy objects. Policy objects
make it possible to have profile A apply to a user in one set of cir-
cumstances,
circumstances, and profile B apply in another set of circumstances.
They also enable binding of profiles to groups.
Each policy object corresponds to an IF/THEN statement; multiple pol-
icy policy
objects may be required to express complex policies. Attributes in the
policy object include npConstraint, a string attribute which expresses
the conditions under which a profile will be applied; npSe-
quence, npSequence, an
integer attribute which describes the order in which the policy object
will be evaluated; and radiusProfilePointer, a Distin-
guished Distinguished Name
pointing to the RADIUS profile that will be applied if the conditions
hold. The matching rule stored in npConstraint is an expression which
may reference other attribute values and include pat-
tern pattern matching and
other operations, such as equality tests. Policy objects without an
npConstraint attribute can be used to indicate unconditional execution
of a profile.
Although a simple Policy Object is presented in this schema, more com-
plex
complex versions are possible. For example, a wider variety of operators
and pattern matches might be supported within npConstraint.
3.3.1.
4.3.1. Example
Let us assume that BIGCO wishes to offer dialin access to their domes-
tic domestic
sales force, as well as VPN access to contractors and to individu-
als individuals
from the finance group travelling overseas. In order to consis-
tently consistently
manage and account for the use of their NAS devices and Layer 2 tunnel
servers (PPTP/L2F/L2TP), BIGCO has chosen to adopt the RADIUS protocol.
However, given the large number of employees and contrac-
tors contractors that need
to be managed, BIGCO desires a RADIUS solution inte-
grated integrated with their
existing LDAP-based directory service and group structure. This will
allow the network administrator to edit the user's RADIUS attributes
with the same user-interface as they use to edit other user attributes,
profiles, and policies, and will eliminate the need to maintain multiple
Aboba Experimental [Page 6]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
stores of user information.
As part of this service offering, BIGCO may wish to implement a number
of policies. For example, in order to make sure that high speed dialin
access is available to the sales force when they need it, BIGCO may wish
to restrict use of the ISDN ports to sales personnel only during the
hours of 9-5, 9 AM - 5 PM, and permit the use of multilink. Since contractors
are only to be given access to selected subnets, BIGCO may wish to apply
a filter filter to their traffic. Since individuals in the finance group often
access highly confidential information over the VPN, BIGCO may wish to
require that these users authenticate via a smartcard, and use only
128-bit encryption so as to provide for extended security. For security
reasons, BIGCO may wish to restrict contractors and finance users to a
single login at a time.
In certain cases, BIGCO may also wish to implement policies that depend
on the type of port that the user is connecting to. For example, if the
user is connecting via dialup, then it may be appropriate to include
tunnel attributes within the Access-Accept, so as to set up a tunnel for
the user. However, if the user is already connected via a tunnel, this
would not be necessary. Similarly, if BIGCO only has a limited number of
ISDN ports available, it may be desirable to set a shorter Session-
Timeout or Idle-Timeout on these ports, or to set Port-Limit to one so
as to not allow multi-link. The schema defined in this document permits
enforcement of these and many other policies.
4.4. Caching
The schema presented in this document will benefit from caching, since
it is expected that profiles and policies will apply to large numbers of
users. The first time the RADIUS server encounters a pointer to their traffic. Since individuals in a given
profile or policy, the finance
group often access highly confidential information over profile or policy will be retrieved from the VPN, BIGCO
directory and cached. Subsequently, the profile or policy may wish be
retrieved from the cache, speeding the retrieval process. As a result,
it is to require be expected that these users authenticate via caching should result in a smartcard, substantial
performance gain.
5. Consistency and
use only 128-bit encryption so as to provide for extended security.
For security reasons, BIGCO may wish transaction issues
While LDAP v3, described in [5], permits a list of modifications to restrict contractors and
finance users a
single object to be made as a single login at atomic operation, it does not
support transacted modifications to multiple objects. In SNMP this
functionality is supported through a time. "conceptual two-phase commit"
applied to SET operations, as well as constructs such as the TextAndIncr
textual convention, defined in [10]. In addition, within a globally
replicated directory system, it is likely that directory replicas will
Aboba Experimental [Page 6] 7]
INTERNET-DRAFT 5 RADIUS Schema for LDAP v3 2 February 1998
In certain cases, BIGCO may also wish to implement policies that
depend on the type 1999
be partially out of port synchronization at any given time. This means that the user is connecting to. For exam-
ple, if the user is connecting via dialup, then
in any given replica it may is possible for related objects to be appropriate in an
inconsistent state. As a result, in order to include tunnel attributes within the Access-Accept, so as ensure correctness, it is
necessary to implement mechanisms for detecting and handling directory
inconsistencies.
This schema includes related objects which need to be consistently
maintained. For example, policy objects contain an 'IF' (conditions) as
well as a 'THEN' (a pointer to set up a tunnel for the user. However, if the user profile object). In addition, it is already connected via
a tunnel,
possible for this would not be necessary. Similarly, if BIGCO only has a
limited number schema to store data which relates to two ends of ISDN ports available, it a
link. For example, the Framed-Route and Framed-Routing attributes may be desirable
used to set up a
shorter Session-Timeout routed dialup or Idle-Timeout on VPN connection.
In either of these ports, or to set
Port-Limit two examples, if mechanisms are not provided to one so as
guarantee consistency of related objects, then inconsistent policies can
be propagated. This is particularly dangerous with respect to not allow multi-link. The schema defined link
policies, since propagation of inconsistent policies could result in
this document permits enforcement the
links going down. This in turn could stop directory replication from
proceeding, preventing resolution of these and many other policies.
3.4. Caching
Reference [14] describes a simple caching scheme for LDAP-based direc-
tories. A new operational attribute, ttl, is defined which specifies the maximum time an object may inconsistency. The network
would thus remain in the cache. Such a caching
scheme is particularly beneficial for the schema presented in this
document, since it is expected that deadlocked state requiring manual intervention.
Directory-induced network lockup can be prevented through careful
implementation. For example, policy objects and profiles may be
maintained within the same containment hierarchy, edited within a
temporary work area, and policies will apply then propagated to large numbers of users. The first time the RADIUS server encounters final location with a pointer to
"transacted move."
Consistency between related objects may be maintained through use of a given profile or policy,
version attribute. When retrieving a set of related objects, the profile or policy will version
number can be
retrieved from checked to make sure that it is consistent within the directory and cached. Subsequently, set.
If an entire set of objects cannot be obtained with the profile or
policy latest version
number, then it may be retrieved from the cache, speeding necessary to revert to use of a previous
consistent set of objects at an earlier version. Note that support for
reversion implies that storage of related objects is archival; that is,
addition of a new set of objects does not overwrite the retrieval pro-
cess. As previous
version.
Since support for object versioning is a result, generally useful capability, it is
makes the most sense to be expected that caching should result support this in a substantial performance gain. As noted general way rather than doing
it in [14], the ttl a schema-specific manner. As a result, we have chosen not to add a
version number attribute
denotes to the number of seconds that an entry may remain objects described in the cache
before becoming stale. this document. A value of 0 implies that the object must
not
general mechanism for supporting versioning will be cached.
3.5. the subject of a
future document.
Aboba Experimental [Page 8]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
5.1. Extensibility
Today vendors distinguish their RADIUS servers by a variety of means,
including the range of supported attributes (standard and vendor-spe-
cific), vendor-
specific), and the breadth of policies that may be represented. As a
result, while it is desirable to provide a common base set of classes
and attributes which all RADIUS schemas will share, RADIUS server
capabilities differ substantially from implementation to implementa-
tion, implementation,
and a successful RADIUS schema definition must support this dif-
ferentiation.
differentiation.
The schema described in this document provides support for most of the
attributes defined in [6]-[8], [1]-[4], as well as including support for the
RADIUS Dictionary and vendor-specific attributes, as well as condi-
tional conditional
application of profiles. Within this framework, vendor differ-
entiation differentiation
can be achieved via two methods: adding attributes to the base RADIUS
profile and policy classes, or creating subclasses inher-
iting inheriting from the
base classes. Adding attributes to the base class is recommended in
cases where the new attributes to be added do not con-
flict conflict with those
described in this document or in [6]-[8]. [1]-[4].
Where conflicts do not arise, new attributes, including vendor-spe-
cific vendor-specific
attributes, may be added to the RADIUS dictionary, which allows RADIUS
Profile objects to be self-describing. The goal is to allow
Aboba [Page 7]
INTERNET-DRAFT 5 February 1998 attributes
to be added without having to require an update to the RADIUS server
code. Note however that a conventional RADIUS dictionary is only
designed to describe attributes that are sent on the wire, while the
RADIUS Dictionary object defined in this schema may also be used to
define additional non-wire attributes (such as radiusAuthenti-
cationType).
radiusAuthenticationType). This provides an additional element of
flexibility, allowing new attributes to be defined and used within
existing policy objects, without code changes.
Creating a sub-class is desirable in cases where conflicts are possi-
ble. possible.
Such conflicts can arise for example, when vendors have defined
attributes which conflict with the standard RADIUS attribute space
described in [6]-[8]. [1]-[4]. In this case, the radiusVendorId attribute should
included and set to the SMI Vendor Code, indicating that the profile is
specific to a given vendor, and contains potentially con-
flicting conflicting
elements. Since a RADIUS server searching for a profile with
objectclass=radiusProfileClass will encounter both base class profiles
and subclasses, the radiusVendorId attribute is critical in allowing an
implementation to differentiate the profiles it can understand from
those that it cannot. Typically an implementation will only wish to work
with profiles whose radiusVendorId is either not present, zero (IETF
RADIUS) or set to their own SMI Vendor Code. As with addition of
attributes to the base class, when attributes are added to a subclass,
the RADIUS Dictionary class should modified to allow the subclass to be
Aboba Experimental [Page 9]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
self-describing.
Since it is conceivable that RADIU RADIUS servers from two vendors may be
deployed simultaneously, both desiring to store objects in the same
LDAP-based directory service, and each implementing their own profile
subclass, a method must be provided to allow a user to have more than
one set of RADIUS profile and policy objects. This can be achieved by
allowing the radiusProfilePointer to point to a container object rather
than pointing to an object itself. The RADIUS server would then search
the container for a RADIUS profile or policy with an appropri-
ate appropriate
radiusVendorId.
In order to prevent name conflicts, it is recommended that vendors
adding their own attributes prepend a suffix to all attribute names.
The IETF Schema Working Group has announced its intention to manage
suffix allocation in order names, so
as to avoid name conflicts. Rather than redefining existing attributes,
vendor should create their own attributes using suffixes in order to
avoid conflict.
To illustrate how extensibility features may be used, the additional
attributes supported by a hypothetical BIGCO Profile Class are included.
4.
6. User object additions
The RADIUS schema proposes addition of the following attributes to the
user object:
Aboba [Page 8]
INTERNET-DRAFT 5 February 1998
MAY ( radiusServiceType $ radiusFramedProtocol $
radiusFramedIPAddress $ radiusFramedIPNetmask $
radiusFramedRoute $ radiusFramedRouting $
radiusFilterId $ radiusFramedMTU $
radiusFramedCompression $ radiusLoginIPHost $
radiusLoginService $ radiusLoginTCPPort $
radiusCallbackNumber $ radiusCallbackId $
radiusFramedRoute $ radiusFramedIPXNetwork $
radiusClass $ radiusVSA $ radiusSessionTimeout $
radiusIdleTimeout $ radiusTerminationAction $
radiusCalledStationId $ radiusCallingStationId $
radiusLoginLATService $ radiusLoginLATNode $
radiusLoginLATGroup $ radiusFramedAppleTalkLink $
radiusFramedAppleTalkNetwork $
radiusFramedAppleTalkZone $ radiusPortLimit $
radiusLoginLATPort $ radiusTunnelType $
radiusTunnelMediumType $ radiusTunnelServerEndpoint $
radiusTunnelPrivateGroupId $ radiusTunnelAssignmentId $
radiusTunnelClientEndpoint $ radiusTunnelPreference $
radiusTunnelPassword $ radiusArapFeatures $
Aboba Experimental [Page 10]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
radiusArapZoneAccess $ radiusArapSecurity $
radiusPasswordRetry $ radiusPrompt $ npSessionsAllowed $
npAuthenticationType $ npEAPType $ npConstraint $
npIPPoolName $ radiusProfilePointer $ radiusVendorId
)
5.
7. Object definitions
The RADIUS schema includes definition of the following objects:
RADIUS Profile Class
RADIUS Policy Class
RADIUS Dictionary Class
EAP Dictionary Class
5.1.
7.1. RADIUS Profile Class
( radiusProfileClass 1
NAME 'radiusProfile'
SUP profile
PARENT (country $ organization $ organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
cn
)
MAY ( radiusServiceType $ radiusFramedProtocol $
radiusFramedIPAddress $ radiusFramedIPNetmask $
radiusFramedRoute $ radiusFramedRouting $
radiusFilterId $ radiusFramedMTU $
radiusFramedCompression $ radiusLoginIPHost $
radiusLoginService $ radiusLoginTCPPort $
radiusCallbackNumber $ radiusCallbackId $
radiusFramedRoute $ radiusFramedIPXNetwork $
radiusClass $ radiusVSA $ radiusSessionTimeout $
radiusIdleTimeout $ radiusTerminationAction $
radiusCalledStationId $ radiusCallingStationId $
radiusLoginLATService $
Aboba [Page 9]
INTERNET-DRAFT 5 February 1998 radiusLoginLATNode $
radiusLoginLATGroup $ radiusFramedAppleTalkLink $
radiusFramedAppleTalkNetwork $
radiusFramedAppleTalkZone $ radiusPortLimit $
radiusLoginLATPort $ radiusTunnelType $
radiusTunnelMediumType $
radiusTunnelServerEndpoint $
radiusTunnelPrivateGroupId $
radiusTunnelAssignmentId $
Aboba Experimental [Page 11]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
radiusTunnelClientEndpoint $
radiusTunnelPreference $
radiusTunnelPassword $ radiusArapFeatures $
radiusArapZoneAccess $ radiusArapSecurity $
radiusPasswordRetry $ radiusPrompt $
npSessionsAllowed $ npAuthenticationType $
npEAPType $ npConstraint $ npIPPoolName $
radiusProfilePointer $ radiusVendorId $
radiusDictionaryPointer
)
)
5.2.
7.2. RADIUS Policy Class
( radiusPolicyClass 1
NAME 'radiusPolicy'
SUP policy
PARENT (country $ organization $
organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
cn $ radiusProfilePointer
)
MAY ( npConstraint $ npSequence
)
)
5.3.
7.3. RADIUS Dictionary Class
( radiusDictionaryClass 1
NAME 'radiusDictionaryClass'
SUP top
PARENT (country $ organization $
organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
cn $ radiusDictionaryEntry
)
)
5.4.
Aboba Experimental [Page 12]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
7.4. EAP Dictionary Class
( eapDictionaryClass 1
NAME 'eapDictionaryClass'
SUP top
PARENT (country $ organization $
organizationalUnit $
locality $ container)
Aboba [Page 10]
INTERNET-DRAFT 5 February 1998
STRUCTURAL
MUST (
cn $ eapDictionaryEntry
)
)
5.5.
7.5. BIGCO Profile Class
As described earlier, the base classes may be extended by attribute
addition, subclassing, or both. An example of the subclassing approach
is illustrated below. Here the bigcoProfileClass is created as a sub-
class
subclass of the radiusProfileClass and adds several attributes, each of
which uses bigco as a suffix to avoid name collisions.
( bigcoProfileClass 1
NAME 'bigcoProfile'
SUP radiusProfileClass
PARENT (country $ organization $ organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
)
MAY ( bigcoBapRequired $ bigcoBapLinednLimit $
bigcoBapLinednTime $ bigcoDynDirServer
)
)
6.
8. Attribute definitions
6.1.
8.1. New Attribute Types Used in the user object and RADIUS Profile
Class
( radius radiusProfileClass 6
NAME 'radiusServiceType'
DESC 'The service to be provided to the user.
Values include: Login(1), Framed(2),
Aboba Experimental [Page 13]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
Callback Login(3), Callback Framed(4),
Outbound(5), Administrative(6), NAS Prompt(7),
Authenticate Only(8), Callback NAS Prompt(9)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 7
NAME 'radiusFramedProtocol'
DESC 'For Framed service, the protocol to be
provided to the user. Values include
PPP(1), SLIP(2), ARAP(3), Gandalf(4),
Xylogics(5)'
Aboba [Page 11]
INTERNET-DRAFT 5 February 1998
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 8
NAME 'radiusFramedIPAddress'
DESC 'IP address to be assigned to the user
in dotted decimal notation'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 9
NAME 'radiusFramedIPNetmask'
DESC 'Netmask to apply to the user
in dotted decimal notation'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 10
NAME 'radiusFramedRouting'
DESC 'Routing method for the user.
Values include None(1), Send(2),
Listen(3), Send & Listen(4)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 11
Aboba Experimental [Page 14]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
NAME 'radiusFilterId'
DESC 'String representing the filter list
for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 12
NAME 'radiusFramedMTU'
DESC 'Maximum Transmission Unit for the user'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 13
NAME 'radiusFramedCompression'
DESC 'Compression protocol to be used on
the link. Values include: None(1),
VJ compression(2),
IPX header compression(3)'
Aboba [Page 12]
INTERNET-DRAFT 5 February 1998
EQUALITY integerMatch
SYNTAX 'INTEGER'
)
( radius radiusProfileClass 14
NAME 'radiusLoginIPHost'
DESC 'System with which to connect the user
in dotted decimal notation'
EQUALITY integerMatch
SYNTAX 'INTEGER'
)
( radius radiusProfileClass 15
NAME 'radiusLoginService'
DESC 'Service to be used to connect the user to
the login host. Values include Telnet(1), Rlogin(2),
TCP Clear(3), PortMaster(4), and LAT(5)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 16
NAME 'radiusLoginTCPPort'
DESC 'The TCP port with which the user is useris
to be connected'
EQUALITY integerMatch
Aboba Experimental [Page 15]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 19
NAME 'radiusCallbackNumber'
DESC 'Number to be called'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 20
NAME 'radiusCallbackId'
DESC 'Name of place to be called'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 22
NAME 'radiusFramedRoute'
DESC 'Routes to be plumbed for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
Aboba [Page 13]
INTERNET-DRAFT 5 February 1998
( radius radiusProfileClass 23
NAME 'radiusFramedIPXNetwork'
DESC 'IPX Network number to be configured
for the user'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 24
NAME 'radiusClass'
DESC 'Class attribute for the user'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass 25
NAME 'radiusVSA'
DESC 'Vendor Specific Attribute
for the user'
SYNTAX 'OCTETSTRING'
)
Aboba Experimental [Page 16]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
( radius radiusProfileClass 27
NAME 'radiusSessionTimeout'
DESC 'Per-session time limit in seconds.
After this expires, the action specified
in Termination-Action is taken'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 28
NAME 'radiusIdleTimeout'
DESC 'The maximum number of consecutive
seconds of idle connection allowed
before session termination'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 29
NAME 'radiusTerminationAction'
DESC 'Action taken when specified service is
completed. Values include Default(1)
or RADIUS-Request(2)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 34
NAME 'radiusLoginLATService'
Aboba [Page 14]
INTERNET-DRAFT 5 February 1998
DESC 'Identity of the LAT service to use'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 35
NAME 'radiusLoginLATNode'
DESC 'The node with which the user is to be
automatically connected by LAT'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 36
Aboba Experimental [Page 17]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
NAME 'radiusLoginLATGroup'
DESC 'The LAT group codes which this user
is authorized to use'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 37
NAME 'radiusFramedAppleTalkLink'
DESC 'The AppleTalk network number which
should be used for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 38
NAME 'radiusFramedAppleTalkNetwork'
DESC 'The AppleTalk network number which
the NAS should probe to allocate an
AppleTalk node for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'INTEGER'
)
( radius radiusProfileClass 39
NAME 'radiusFramedAppleTalkZone'
DESC 'The name of the Default AppleTalk Zone'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 62
NAME 'radiusPortLimit'
DESC 'Maximum number of ports to be provided'
EQUALITY integerMatch
Aboba [Page 15]
INTERNET-DRAFT 5 February 1998
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 39
NAME 'radiusLoginLATPort'
DESC 'The Port with which the user is to
connected by LAT'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
Aboba Experimental [Page 18]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
SINGLE-VALUE
)
( radius radiusProfileClass 64
NAME 'radiusTunnelType'
DESC 'String representing the type of tunnel to
be set up, of the form Tag: Value. Values
include PPTP(1), L2F(2), L2TP(3), ATMP(4),
VTP(5), AH(6), IP-IP(7).'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass 65
NAME 'radiusTunnelMediumType'
DESC 'String representing the medium for the tunnel to
run over, of the form Tag: Value. Values
include IP(1), X.25(2), ATM(3), Frame Relay(4).'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass 67
NAME 'radiusTunnelServerEndpoint'
DESC 'String representing the address of the tunnel
server, of the form Tag: Value. The format
of the value field depends on the tunnelMediumType
attribute'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass ? 66
NAME 'radiusTunnelPrivateGroupId' 'radiusTunnelClientEndpoint'
DESC 'String representing the Private Group Id Tunnel Client Endpoint
for the tunnel, of the form Tag: Value.'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass ? 67
NAME 'radiusTunnelPreference' 'radiusTunnelServerEndpoint'
DESC 'String representing the tunnel preference for the
tunnel, address of the form Tag: Value.'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass ?
Aboba [Page 16]
INTERNET-DRAFT 5 February 1998
NAME 'radiusTunnelAssignmentId'
DESC 'String representing the Tunnel Assignment Id for the
tunnel, tunnel
server, of the form Tag: Value.'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass ?
NAME 'radiusTunnelClientEndpoint'
DESC 'String representing the Tunnel Client Endpoint for the
tunnel, Value. The format
of the form Tag: Value.' value field depends on the
tunnelMediumType attribute'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass 71
NAME 'radiusArapFeatures'
DESC 'This is a compound string containing info that
the NAS should send to the user in the ARAP
feature flags packet'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 72
NAME 'radiusArapZoneAccess'
Aboba Experimental [Page 19]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
DESC 'This field controls access to ARAP zones.
Values include
Only allow access to default zone(1),
Use zone filter inclusively(2),
Use zone filter exclusively (4)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 73
NAME 'radiusArapSecurity'
DESC 'This field contains an integer
specifying the security module signature,
which is a Macintosh OSType'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 75
NAME 'radiusPasswordRetry'
DESC 'This is an integer specifying the number
of password retry attempts to permit the user'
EQUALITY integerMatch
SYNTAX 'INTEGER' 'INTEGER
SINGLE-VALUE
)
Aboba [Page 17]
INTERNET-DRAFT 5 February 1998
( radius radiusProfileClass 76
NAME 'radiusPrompt'
DESC 'This attribute is used only in RADIUS
Access-Challenge packets and indicates
if the NAS should echo NAS should echo the user's response
as entered. Values include No Echo (0), or Echo(1).'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 81
NAME 'radiusTunnelPrivateGroupId'
DESC 'String representing the Private Group Id for the
tunnel, of the form Tag: Value.'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass 82
Aboba Experimental [Page 20]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
NAME 'radiusTunnelAssignmentId'
DESC 'String representing the Tunnel Assignment Id
for the tunnel, of the form Tag: Value.'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass 83
NAME 'radiusTunnelPreference'
DESC 'String representing the tunnel preference for the
tunnel, of the user's response
as entered. Values include No Echo (0), or Echo(1).'
EQUALITY integerMatch form Tag: Value.'
SYNTAX 'INTEGER'
SINGLE-VALUE 'OCTETSTRING'
)
( radius radiusProfileClass 257
NAME 'npEAPType'
DESC 'Allowable EAP types, in order of preference.
If this attribute has a value, EAP must be
included in the allowable authentication types.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 258
NAME 'npConstraint'
DESC 'A string expressing conditions which must hold
in order for an Access-Accept to be sent. The
string is of the format MATCH ( <attribute> =
<pattern/value> OR <pattern/value>) <AND/OR>
TIMEOFDAY. Brackets () can be used to group.
When multiple msNPConstraints are present, all
of them must be satisfied in order for a profile
to be executed.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String'
)
( radius radiusProfileClass 259
NAME 'npIPPoolName'
DESC 'The name of the IP Address Pool out of which
the user's IP address should be allocated.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String'
)
( radius radiusProfileClass 260
NAME 'npSessionsAllowed'
DESC 'This attribute indicates the number of
Aboba Experimental [Page 21]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
simultaneous sessions allowed for this user.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 261
NAME 'npAuthenticationType'
Aboba [Page 18]
INTERNET-DRAFT 5 February 1998
DESC 'Allowable authentication types (EAP, CHAP, PAP,
MS-CHAP, etc.) in order of preference.
If an attribute isn't included, it isn't allowed.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 262
NAME 'radiusProfilePointer'
DESC 'Distinguished Name of a RADIUS Profile Object.'
EQUALITY distinguishedNameMatch
SYNTAX 'DN'
SINGLE-VALUE
)
( radius radiusProfileClass 263
NAME 'radiusVendorId'
DESC 'SMI Vendor Id. A non-zero value denotes a
profile non-compliant with RFC 2138 and 2139.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 264
NAME 'radiusDictionaryPointer'
DESC 'A Distinguished Name pointing to
the RADIUS dictionary for this profile. If
not present the default dictionary is used.'
EQUALITY distinguishedNameMatch
SYNTAX 'DN'
SINGLE-VALUE
)
6.2.
Aboba Experimental [Page 22]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
8.2. New Attribute Types Used in the RADIUS Policy Class
( radius radiusPolicyClass 2
NAME 'npSequence'
DESC 'An integer indicating the order in which
policy objects are to be evaluated.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
6.3.
8.3. New Attribute Types Used in the RADIUS Dictionary Class
( radius radiusDictionaryClass 1
NAME 'dictionaryEntry'
Aboba [Page 19]
INTERNET-DRAFT 5 February 1998
DESC 'A dictionary entry in the RADIUS dictionary,
of the form
Attribute-Number:[Vendor-Type:]ldapDisplayName:Type.
Vendor-Type may only be present with
Attribute-Number=26 (Vendor Specific).'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
6.4.
8.4. New Attribute Types Used in the BIGCO Profile Class
( bigco bigcoProfileClass 263
NAME 'bigcoBapRequired'
DESC 'This attribute indicates whether Bandwidth
Allocation Protocol (BAP) is required for
this user. Values include
BAP Not Required (0) and BAP Required (1).'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( bigco bigcoProfileClass 264
NAME 'bigcoBapLinednLimit'
DESC 'Percent of capacity utilized at which to
bring a line down for this user. '
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
Aboba Experimental [Page 23]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
)
( bigco bigcoProfileClass 265
NAME 'bigcoBapLinednTime'
DESC 'Time in seconds for the capacity
utilization calculation.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( bigco bigcoProfileClass 266
NAME 'bigcoDynDirServer'
DESC 'Fully qualified domain name or IP address of
the dynamic directory server for this user.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
7.
9. Security issues
Integration of a RADIUS server with an LDAP-based directory service can
result in a variety of several security threats, issues, including:
Aboba [Page 20]
INTERNET-DRAFT 5 February 1998
Rogue LDAP-servers
Theft of passwords
Inappropriate use
These threats are discussed in turn.
7.1.
9.1. Rogue LDAP servers
Were a rogue LDAP server to respond to queries from the RADIUS server
and have its responses accepted, it is possible that users could gain
inappropriate access to the network. In order to protect against this,
the conversation between the RADIUS server and the LDAP-based direc-
tory directory
service SHOULD be mutually authenticated via SSL/TLS or IPSEC.
7.2. Theft of passwords
RADIUS servers supporting PAP authentication or attributes such as
Tunnel-Password SHOULD provide for confidentiality of packets sent to
and from the LDAP server. This can be achieved using SSL/TLS TLS [8] or IPSEC
ESP.
7.3. [9].
9.2. Inappropriate use
This schema is intended for use by a RADIUS server integrating with an
LDAP-enabled directory. This schema SHOULD NOT be used was not designed for use by devices
looking to directly access the directory directly.
LDAP-enabling of devices would introduce several security problems. As
described in [13], directory.
Aboba Experimental [Page 24]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
LDAP-enabling a RADIUS server requires that the RADIUS server be given
permissions to access a user's RADIUS objects and attributes. If the dynamic attributes described in [12] are sup-
ported, then the RADIUS service must also be able to write those
attributes to the DS. As a
result, the administrator of the RADIUS server should exercise care to
ensure that the RADIUS account password is not compromised. If at all
possible, the RADIUS server should be physically secured.
In contrast, LDAP-enabling of devices requires that devices be given
these access-rights. This can be achieved by making the devices mem-
bers members
of a group, and giving the group access rights to this portion of the
schema. However, such an expansion of access rights is undesir-
able, since while RADIUS servers can often be physically secured,
widely deployed devices typically cannot be.
Furthermore,
It should also be noted that direct use of LDAP across a WAN typically
requires that LDAP pass through a firewall. This is problematic since
LDAP-based directories can be used to store a wide variety of data, much
of it sensitive. Thus without implementing an LDAP proxy to limit access
only to appropriate portions of the schema, it is difficult to enforce
security. Since humans are notoriously lax in administration of access
rights, an attacker obtaining a device password would typically also
Aboba [Page 21]
INTERNET-DRAFT 5 February 1998
obtain access not only to RADIUS attributes for every user, but to other
information as well.
Beyond the security issues,
LDAP-enabling of devices has other potential downsides as well. It
increases the size of the device binaries, and may in some cases
introduce dependen-
cies dependencies in the device boot sequence that can be
problematic.
8.
10. Acknowledgments
Thanks to Steven Judd, Ashwin Palekar, David Eitelbach, Narendra Gid-
wani Gidwani
and Donald Rule of Microsoft for useful discussions of this prob-
lem problem
space.
9.
11. References
[1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Pro-
tocol." RFC 1777, March 1995.
[2] "Information Processing Systems - Open Systems Interconnection -
The Directory: Overview of Concepts, Models and Service." ISO/IEC JTC
1/SC21, International Standard 9594-1, 1988.
[3] "Information Processing Systems - Open Systems Interconnection -
The Directory: Selected Object Classes." Recommendation X.521 ISO/IEC
JTC 1/SC21, International Standard 9594-7, 1993.
[4] M.Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions." Internet Draft
(work in progress), draft-ietf-asid-ldapv3-attributes-08.txt, Critical
Angle, Isode, Netscape, October 1997.
[5] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access
Protocol (v3): Extensions for Dynamic Directory Services." Internet
Draft (work in progress), draft-ietf-asid-ldapv3-dynamic-06.txt,
Microsoft, Critical Angle, September 1997.
[6] C. Rigney, A. C., Rubens, W. Simpson, A., Simpson W., and S. Willens. Willens, "Remote Authenti-
cation
Authentication Dial In User Service (RADIUS)." (RADIUS)", RFC 2138, Livingston, Merit,
Daydreamer, April 1997.
[7] C. Rigney.
[2] Rigney, C., "RADIUS Accounting." Accounting", RFC 2139, Livingston, April 1997.
[8] C. Rigney, W. Willats.
[3] Zorn, G., Leifer, D., Rubens, A., and J. Shriver, "RADIUS Extensions." Work in progress,
draft-ietf-radius-ext-01.txt, Livingston, June 1997.
[9] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access
Protocol: Dynamic Attributes." Attributes
for Tunnel Protocol Support", Internet Draft draft (work in progress),
draft-ietf-asid-dynatt-00.txt, Microsoft, Critical Angle, July 1997.
[10] J. Hodges, R.L. Morgan, M. Wahl, "Lightweight Directory Access
Protocol (v3): Extension for Transport Layer Security." draft-
ietf-radius-tunnel-auth-06.txt, September 1998.
[4] Rigney, C., Willats, W., "RADIUS Extensions", Internet Draft draft (work
in progress), draft-ietf-radius-ext-02.txt, October 1998.
Aboba Experimental [Page 22] 25]
INTERNET-DRAFT 5 RADIUS Schema for LDAP v3 2 February 1998
(work in progress), draft-ietf-asid-ldapv3-tls-01.txt, Stanford, Crit-
ical Angle, June 1997.
[11] M. 1999
[5] Wahl, T. Hoews, S. M., Howes, T., Kille, S., "Lightweight Directory Access Proto-
col (v3)." Internet Draft (work in progress), draft-ietf-asid-proto-
col-08.txt, Critical Angle, Netscape, Isode, October
Protocol (v3)", RFC 2251, December 1997.
[12] B. Aboba,
[6] Wahl, M., Coulbeck, A., Howes, T., Kille S., "Lightweight Directory
Access Protocol (v3): Dynamic
Attributes for the Remote Access Dialin User Service (RADIUS)." Inter-
net Draft (work in progress), draft-aboba-dynradius-01.txt, Microsoft,
November Attribute Syntax Definitions", RFC 2252, December
1997.
[13] B. Aboba, "Lightweight Directory Access
[7] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (v3): Extension
(EAP)", RFC 2284, March 1998.
[8] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246,
November 1998.
[9] Atkinson, R., Kent, S., "Security Architecture for PPP Authentication" the Internet Draft (work in progress), draft-
aboba-ppp-01.txt, Microsoft,
Protocol", RFC 2401, November 1997.
[14] T. Howes, L. Howard, "A Simple Caching Scheme for LDAP 1998.
[10] Case, J., McCloghrie, K., Rose, M., and X.500
Directories." Internet Draft (work in progress), draft-ietf-asid-
ldap-cache-01.txt, Netscape, October 1997.
10. S. Waldbusser, "Textual
Conventions for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1903, January 1996.
12. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
13. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except s needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are
Aboba Experimental [Page 23] 26]
INTERNET-DRAFT RADIUS Schema for LDAP v3 2 February 1999
perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
14. Expiration Date
This memo is filed as <draft-aboba-radius-03.txt>, and expires August
1, 1999
Aboba Experimental [Page 27]
----