Internet DRAFT - draft-ietf-asid-ldapv3-radius
draft-ietf-asid-ldapv3-radius
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:53:27 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 07 Nov 1997 19:18:00 GMT
ETag: "2e9d45-cdfd-34636968"
Accept-Ranges: bytes
Content-Length: 52733
Connection: close
Content-Type: text/plain
ASID Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
<draft-ietf-asid-ldapv3-radius-00.txt>
7 November 1997
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-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as 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 or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts 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).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-asid-ldapv3-radius-00.txt>, and expires May 1, 1998. Please send
comments to the authors.
2. Abstract
This document defines a schema for the Remote Access Dialin User Ser-
vice (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 is desirable since it results in a reduction in the admin-
istrative workload, and eliminates the need to synchronize across mul-
tiple user information stores.
3. Introduction
Today enterprises are looking to simplify the process of user adminis-
tration. With the advent of HR and personnel management systems,
information on a user is typically entered at the time of hiring, is
retained until termination. If an LDAP-based directory is also
deployed within the enterprise, this necessities synchronization of
the HR or personnel database with the LDAP-based directory in order to
maintain consistency.
Aboba [Page 1]
INTERNET-DRAFT 7 November 1997
Should the enterprise then seek to deploy NAS devices or layer 2 tun-
neling solutions, there may be a need to add a RADIUS server or if
extended security is required, a backend security server. Each of
these may require their own store of user information.
The possibility of operating multiple stores of user information is
not appealing, since this may require rekeying of information or
sychronization between multiple stores. Maintaining multiple stores
also results in increased maintenance costs, and raises concerns about
inconsistency and replication delays. In order to avoid this problem,
it is desirable to consolidate stores of user information. One way
this can be achieved is to make it possible for a RADIUS server to
store its 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. Due to the frequency of changes to this data, dynamic
attributes must be employed, as described in [9].
Reference [13] describes an LDAP extension supporting validation of
user credentials submitted during PPP authentication. This makes it
possible for the RADIUS server to validate user credentials received
in the Access-Request packet. We believe that such an extension is
needed since current LDAP security mechanisms do not support PPP
authentication methods. In addition, requiring a BIND and UNBIND for
each authentication results in an unacceptable level of overhead.
Rather than having to do a BIND and UNBIND for every authentication,
as described in [13], when the RADIUS service starts up, it binds to
the LDAP-based directory service using a special account, and when the
RADIUS service shuts down, it unbinds. In between, during the time
that the RADIUS service is running, the LDAP extension for PPP authen-
tication is used to validate user credentials.
This document defines an LDAP schema for the Remote Access Dialin User
Service (RADIUS). The RADIUS protocol, described in [6]-[8], supports
authentication, authorization and accounting for dialup users. To
date, RADIUS servers have stored and retrieved user data in a variety
of ways, including databases and flat files. The goal of the schema
described in this document is to make it as easy as possible to add
support for LDAP-based directory services to existing RADIUS server
implementations. In order to allow RADIUS servers to interoperate with
a variety of LDAP-based directory services, this schema is designed to
be implementable on a wide range of directory service implementations.
This requires avoiding reliance on features that have not been widely
implemented, such as multiple inheritance.
Aboba [Page 2]
INTERNET-DRAFT 7 November 1997
3.1. Objects and attributes
The RADIUS schema defined in this document requires support for sev-
eral new classes: radiusProfileClass, radiusPolicyClass, radiusDic-
tionaryClass, and eapDictionaryClass. The radiusProfileClass is used
to store RADIUS attributes relevant to groups of users. The radiusPol-
icyClass is used to describe conditions under which a given profile
may be applied. The radiusDictionaryClass is used to store the RADIUS
Dictionary corresponding to a particular profile. This along with the
vendorId attribute allows RADIUS profile objects to be self describ-
ing. The eapDictionaryClass is used to store a list mapping EAP Types
to names.
The attributes in the radiusProfileClass fall into three categories:
attributes present in the Access-Request, attributes present in the
Access-Reply, and attributes that do not travel over the wire.
Attributes present in the Access-Reply are stored in the directory so
that the RADIUS server can retrieve them and include them in the
Access-Reply. Note that only static attributes present in Access-Reply
need be stored in the directory; attributes which are computed on the
fly can be recreated as needed.
When stored in the directory, attributes included in the Access-
Request are used to represent conditions required for an Access-Accept
to be sent. For example, a callingStationId attribute can be stored in
the directory in order to indicate that the Calling-Station-Id
attribute should have a certain value for a given user.
Attributes that do not travel over the wire also typically represent
information which is useful in determining whether to return an
Access-Accept. For example, a timeOfDay attribute can be stored in the
directory in order to restrict a user's access by time of day.
The attributes in the radiusPolicyClass represent conditions which may
be evaluated in order to determine whether a given profile should be
applied. For example, rather than just restricting access, it may be
desirable to give users different Session-Time or Port-Limit
attributes depending on the time of day. Similarly, it may be desir-
able to require that modem callers do callback or call from a particu-
lar callingStationId, while this may not make sense for users connect-
ing over a VPN. If this functionality is needed then policy objects
will need to be created, and attributes such as timeOfDay or portType
will be set.
3.2. Profiles
The RADIUS schema defined in this document is designed to support
attributes which apply to individual users, as well as attributes
which apply to groups of users.
In the early versions of this document, it was envisaged that all
attributes would be contained within the user object. However, this
approach allows a user to only have a single set of attributes. This
Aboba [Page 3]
INTERNET-DRAFT 7 November 1997
is problematic in the case that the enterprise were to attempt to
deploy RADIUS servers from more than one vendor, or where use of dif-
ferent profiles is required according to the situation.
Furthermore, since in many cases RADIUS attributes are shared by large
groups of users, storing attributes in every user object creates
unnecessary difficulty in changing the attributes of all members of a
group, and requires replication of large amounts of redundant data.
As a result, the notion of a RADIUS profile was introduced. Within
this document, we allow profiles to include pointers to other profiles
or to a series of policies, so that profiles may form a linked list.
This allows a hierarchy of profiles to be provided. More specific
attributes overide more general ones. Since many RADIUS parameters are
expected to be identical for a group of users, typically the user
object contains either a small number of attributes (perhaps only a
radiusProfilePointer or radiusPolicyPointers) while subsequent RADIUS
profiles contain more attributes.
In the schema that follows we allow (but do not require) RADIUS
attributes to be stored in the user object. The user object also must
contain either a RADIUSProfilePointer or a RADIUSPolicyPointer. These
are distinguished names pointing to RADIUS Profile Objects or RADIUS
Policy Objects, respectively. Similarly, RADIUS profiles may them-
selves contain a RADIUSProfilePointer or a RADIUSPolicyPointer.
3.2.1. Example
All BIGCO employees are required to use token card authentication, and
thus in the company profile the authenticationType attribute is set to
only allow EAP, and the EAP-Type attribute is set for BIGCO's token
card type. BIGCO also sets up a marketing profile providing a session-
Timeout value of 30 minutes, a portLimit of one, and framedIpAddress
set to indicate dynamic allocation. However, Fred requires a static IP
address, and thus his user object will contain a framedIpAddress
attribute as well as a radiusProfilePointer to the Marketing profile.
3.3. Policy support
The schema described in this document provides for the unconditional
application of a profile to a user via the RADIUSProfilePointer
attribute. The RADIUSProfilePointer is a distinguished name pointing
to a RADIUS profile. This pointer is used when a given profile is to
be applied in all circumstances (unconditional).
However it may be desirable to have profile A apply to a user in one
set of circumstances, and profile B apply in another set of circum-
stances. Where a profile needs to be applied based on a set of condi-
tions, a user object or profile object may contain one or more RADIUS-
PolicyPointer attributes. The RADIUSPolicyPointer is a distinguished
name pointing to a RADIUS Policy Objet. The RADIUSPolicyPointerClass
contains attributes reflecting the conditions under which a given
Aboba [Page 4]
INTERNET-DRAFT 7 November 1997
RADIUS profile is to be applied, along with a RADIUSProfilePointer to
the RADIUS profile itself that should be applied when the conditions
hold. Since a RADIUSPolicyPointer need only be used when there are
multiple conditions to evaluate, the RADIUSPolicyPointer attribute is
multi-valued. A RADIUSPolicyPointer may be an attribute in the user
object or in a RADIUS profile.
Although a relatively simple RADIUS Policy Object is presented in this
schema, more complex versions are possible. For example, it has been
suggested that regular expressions be allowed in policy attributes so
as to provide more advanced matching capabilities.
3.3.1. Example
Let us assume that BIGCO wishes to offer dialin access to their domes-
tic sales force, as well as VPN access to contractors and to finance
employees travelling overseas. In order to 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. How-
ever, given the large number of employees and contractors that need to
be managed, BIGCO desires a RADIUS solution integrated with their
existing LDAP-based directory service. 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, and will elimi-
nate the need to maintain multiple stores of user information.
As part of this service offering, BIGCO may wish to implement a number
of access 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, and permit the use of multilink. Since con-
tractors are only to be given access to a selected group of machines,
BIGCO may wish to apply a filter to their traffic. Since travelling
finance users 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 or network 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 the administration of these
and other policies.
Aboba [Page 5]
INTERNET-DRAFT 7 November 1997
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 remain in the cache. Such a caching
scheme is particularly beneficial for the schema presented in this
document, 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 a given profile or policy, the profile or policy will be
retrieved from the directory and cached. Subsequently, the profile or
policy may be retrieved from the cache, speeding the retrieval pro-
cess. As a result, it is to be expected that caching should result in
a substantial performance gain.
Since the schema presented in this document is designed to be used
across several directory implementations and the operational ttl
attribute is not yet widely implemented, a ttl attribute is included
in the radiusProfileClass and radiusPolicyClass. As in [14], the ttl
attribute denotes the number of seconds that an entry may remain in
the cache before becoming stale. A value of 0 implies that the
object must not be cached.
3.5. Extensibility
Today vendors distinguish their RADIUS servers by a variety of means,
including the range of supported attributes (standard and vendor-spe-
cific), 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, and a successful RADIUS schema definition must support this dif-
ferentiation.
The schema described in this document provides support for most of the
attributes defined in [6]-[8], but does not include vendor-specific
attributes or attempt to cover the full range of policies that might
be desirable. Thus we expect that vendor extensions will be required
in most cases.
Vendor differentiation can be achieved via two methods: adding
attributes to the base RADIUS profile and policy classes, or creating
subclasses inheriting from the base classes. Adding attributes to the
base class is recommended in cases where the new attributes to be
added do not conflict with those described in this document or in
[6]-[8].
Where conflicts do not arise, the vendorId attribute within the RADIUS
profile should be set to zero, indicating that the profile supports
IETF standard RADIUS. As with many RADIUS server implementations, a
RADIUS dictionary capability is supported through the RADIUS Dictio-
nary Class, allowing the RADIUS profile to be self-describing. The
goal is to allow attributes to be added without having to require an
update to the RADIUS server code. Note however that the RADIUS
Aboba [Page 6]
INTERNET-DRAFT 7 November 1997
dictionary is only designed to describe attributes that are sent on
the wire; non-wire attributes (such as authenticationType) are not
included, and thus such attributes typically cannot be supported with-
out code changes.
Creating a sub-class is desirable in cases where conflicts are possi-
ble. Such conflicts can arise for example, when vendors have defined
attributes which conflict with the standard RADIUS attribute space
described in [6]-[8]. In this case, the vendorId attribute should be
set to the SMI Vendor Code, indicating that the profile is specific to
a given vendor, and contains potentially conflicting elements. Since a
RADIUS server searching for a profile with objectclass=radiusProfile-
Class will encounter both base class profiles and subclasses, the ven-
dorId attribute is critical in allowing an implementation to differen-
tiate the profiles it can understand from those that it cannot. Typi-
cally an implementation will only wish to work with profiles whose
vendorId is either 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
also be modified to allow the subclass to be self-describing.
Since it is conceivable that 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 or radiusPolicyPointer 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 appropriate vendorId.
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 to avoid name conflicts. Such precautions
are particularly necessary when dealing with attributes which may
appear in the Access-Request. Note that such attributes are included
in the schema in order to express conditions under which an Access-
Accept may be sent, not in order to provide guidance about what the
RADIUS server should return in the Access-Accept. Since vendors may
wish to provide sophisticated facilities for expressing such condi-
tions, it is likely that there will be disagreement on how these con-
ditions should be formulated. However, rather than redefining existing
attributes, vendor should create their own attributes using suffixes
for conflict avoidance.
To illustrate how extensibility features may be used, the additional
attributes supported by a hypothetical BIGCO Profile Class are
included.
Aboba [Page 7]
INTERNET-DRAFT 7 November 1997
4. Object definitions
The RADIUS schema includes definition of the following objects:
RADIUS Profile Class
RADIUS Policy Class
RADIUS Dictionary Class
EAP Dictionary Class
4.1. RADIUS Profile Class
( radiusProfileClass 1
NAME 'radiusProfile'
SUP profile
PARENT (country $ organization $ organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
cn
)
MAY ( serviceType $ framedProtocol $ framedIPAddress $
framedIPNetmask $ framedRouting $
filterId $ framedMTU $ framedCompression $
loginIPHost $ loginService $ loginTCPPort $
callbackNumber $ callbackId $ framedRoute $
framedIPXNetwork $ sessionTimeout $ idleTimeout $
terminationAction $ calledStationId $ callingStationId $
loginLATService $ loginLATNode $ loginLATGroup $
framedAppleTalkLink $ framedAppleTalkNetwork $
framedAppleTalkZone $ portLimit $ loginLATPort $
tunnelType $ tunnelMediumType $ tunnelServerEndpoint $
tunnelPrivateGroupId $ arapFeatures $ arapZoneAccess $
arapSecurity $ passwordRetry $ prompt $ ttl $
eapType $ sessionsAllowed $ authenticationType $
vendorId $ timeOfDay $ radiusDictionary $
radiusProfilePointer $ radiusPolicyPointer
)
)
4.2. RADIUS Policy Class
( radiusPolicyClass 1
NAME 'radiusPolicy'
SUP policy
PARENT (country $ organization $ organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
cn $ radiusProfilePointer
)
MAY ( portType $ nasPrefixes $ clientPrefixes $
timeOfDay $ ttl $ vendorId
Aboba [Page 8]
INTERNET-DRAFT 7 November 1997
)
)
4.3. RADIUS Dictionary Class
( radiusDictionaryClass 1
NAME 'radiusDictionaryClass'
SUP top
PARENT (country $ organization $ organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
cn $ dictionaryEntry
)
)
4.4. EAP Dictionary Class
( eapDictionaryClass 1
NAME 'eapDictionaryClass'
SUP top
PARENT (country $ organization $ organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
cn $ dictionaryEntry
)
)
4.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 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 ( bigcoAllowedPortType $ bigcoEncryptionType $ bigcoBapRequired $
bigcoBapLinednLimit $ bigcoBapLinednTime $ bigcoDynDirServer
)
)
Aboba [Page 9]
INTERNET-DRAFT 7 November 1997
5. Attribute definitions
5.1. New Attribute Types Used in the RADIUS Profile Class
( radius radiusProfileClass 6
NAME 'serviceType'
DESC 'The service to be provided to the user.
Values include: Login(1), Framed(2),
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 'framedProtocol'
DESC 'For Framed service, the protocol to be
provided to the user. Values include
PPP(1), SLIP(2), ARAP(3), Gandalf(4),
Xylogics(5)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 8
NAME 'framedIPAddress'
DESC 'IP address to be assigned to the user
in dotted decimal notation'
EQUALITY caseIgnoreIA5Match
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 9
NAME 'framedIPNetmask'
DESC 'Netmask to apply to the user
in dotted decimal notation'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 10
NAME 'framedRouting'
DESC 'Routing method for the user.
Values include None(1), Send(2),
Listen(3), Send & Listen(4)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
Aboba [Page 10]
INTERNET-DRAFT 7 November 1997
SINGLE-VALUE
)
( radius radiusProfileClass 11
NAME 'filterId'
DESC 'String representing the filter list for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 12
NAME 'framedMTU'
DESC 'Maximum Transmission Unit for the user'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 13
NAME 'framedCompression'
DESC 'Compression protocol to be used on
the link. Values include: None(1),
VJ compression(2),
IPX header compression(3)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
)
( radius radiusProfileClass 14
NAME 'loginIPHost'
DESC 'System with which to connect the user
in dotted decimal notation'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 15
NAME 'loginService'
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 'loginTCPPort'
DESC 'The TCP port with which the user is
to be connected'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
Aboba [Page 11]
INTERNET-DRAFT 7 November 1997
( radius radiusProfileClass 19
NAME 'callbackNumber'
DESC 'Number to be called'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 20
NAME 'callbackId'
DESC 'Name of place to be called'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 22
NAME 'framedRoute'
DESC 'Routes to be plumbed for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 23
NAME 'framedIPXNetwork'
DESC 'IPX Network number to be configured
for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 27
NAME 'sessionTimeout'
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 'idleTimeout'
DESC 'The maximum number of consecutive
seconds of idle connection allowed
before session termination'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 29
NAME 'terminationAction'
Aboba [Page 12]
INTERNET-DRAFT 7 November 1997
DESC 'Action taken when specified service is
completed. Values include Default(1)
or RADIUS-Request(2)'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 30
NAME 'calledStationId'
DESC 'Indicates that access is only allowed to these numbers'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 31
NAME 'callingStationId'
DESC 'Indicates that access is restricted and
only allowed from this phone number.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 34
NAME 'loginLATService'
DESC 'Identity of the LAT service to use'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 35
NAME 'loginLATNode'
DESC 'The node with which the user is to be
automatically connected by LAT'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 36
NAME 'loginLATGroup'
DESC 'The LAT group codes which this user
is authorized to use'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 37
NAME 'framedAppleTalkLink'
DESC 'The AppleTalk network number which
should be used for the user'
EQUALITY caseIgnoreIA5Match
Aboba [Page 13]
INTERNET-DRAFT 7 November 1997
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 38
NAME 'framedAppleTalkNetwork'
DESC 'The AppleTalk network number which
the NAS should probe to allocate an
AppleTalk node for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 39
NAME 'framedAppleTalkZone'
DESC 'The name of the Default AppleTalk Zone'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 62
NAME 'portLimit'
DESC 'Maximum number of ports to be provided'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 39
NAME 'loginLATPort'
DESC 'The Port with which the user is to
connected by LAT'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 64
NAME 'tunnelType'
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).'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 65
NAME 'tunnelMediumType'
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).'
Aboba [Page 14]
INTERNET-DRAFT 7 November 1997
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 67
NAME 'tunnelServerEndpoint'
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'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass ?
NAME 'tunnelPrivateGroupId'
DESC 'String representing the Private Group Id for the
tunnel, of the form Tag: Value.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 71
NAME 'arapFeatures'
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 'arapZoneAccess'
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 'arapSecurity'
DESC 'This field contains an integer
specifying the security module signature,
which is a Macintosh OSType'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
Aboba [Page 15]
INTERNET-DRAFT 7 November 1997
( radius radiusProfileClass 75
NAME 'passwordRetry'
DESC 'This is an integer specifying the number
of password retry attempts to permit the user'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 76
NAME 'prompt'
DESC 'This attribute is used only in RADIUS
Access-Challenge packets and indicates
if the 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 256
NAME 'ttl'
DESC 'Time in seconds that this profile may remain in a profile cache.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 257
NAME 'eapType'
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 'sessionsAllowed'
DESC 'This attribute indicates the number of
simultaneous sessions allowed for this user.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 259
NAME 'authenticationType'
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}'
Aboba [Page 16]
INTERNET-DRAFT 7 November 1997
SINGLE-VALUE
)
( radius radiusProfileClass 260
NAME 'vendorId'
DESC 'RADIUS Vendor ID for the object. ID=0 indicates
a standard IETF RADIUS profile.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 261
NAME 'timeOfDay'
DESC 'Times of day when the user may be granted access.
Format: 1:00-3:00,4:15-6:35,9:00-13:00,23:10-23:50'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 262
NAME 'radiusDictionary'
DESC 'Distinguished Name pointing to the RADIUS Dictionary
for this object.'
EQUALITY distinguishedNameMatch
SYNTAX 'DN'
SINGLE-VALUE
)
( radius radiusProfileClass 263
NAME 'radiusProfilePointer'
DESC 'Distinguished Name of a RADIUS Profile Object.'
EQUALITY distinguishedNameMatch
SYNTAX 'DN'
SINGLE-VALUE
)
( radius radiusProfileClass 264
NAME 'radiusPolicyPointer'
DESC 'Distinguished Name of a RADIUS policy object.'
EQUALITY distinguishedNameMatch
SYNTAX 'DN'
)
5.2. New Attribute Types Used in the RADIUS Policy Class
( radius radiusPolicyClass 1
NAME 'portType'
DESC 'Bitstring representing port types for which
access is allowed. Values include Async(1), Sync(2),
ISDN Sync(3), V.120(4), V.110(5), Virtual(6) and ATM(7).
If not present, any type is allowed.'
Aboba [Page 17]
INTERNET-DRAFT 7 November 1997
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusPolicyClass 2
NAME 'nasPrefixes'
DESC 'String representing originating nasIPAddress
prefixes to which this profile will apply.
If not present, this profile applies to all
prefixes.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusPolicyClass 3
NAME 'clientPrefixes'
DESC 'String representing originating RADIUS Client
prefixes to which this profile will apply.
If not present, this profile applies to all
prefixes.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
5.3. New Attribute Types Used in the RADIUS Dictionary Class
( radius radiusDictionaryClass 1
NAME 'dictionaryEntry'
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}'
)
5.4. New Attribute Types Used in the BIGCO Profile Class
( bigco bigcoProfileClass 262
NAME 'bigcoAllowedPortType'
DESC 'This attribute is a bitstring representing
port types to which access is allowed. Values
include Async(1), Sync(2), ISDN Sync(3),
V.120(4), V.110(5), and Virtual(6).'
EQUALITY bitStringMatch
SYNTAX 'BitString'
SINGLE-VALUE
)
Aboba [Page 18]
INTERNET-DRAFT 7 November 1997
( 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
)
( bigco bigcoProfileClass 265
NAME 'bigcoBapLinednTime'
DESC 'Time in seconds for the capacity utilization calculation.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( bigco bigcoProfileClass 266
NAME 'bigcoEncryptionType'
DESC 'Bitstring representing allowable encryption types.
Types include No encryption (0), 40-bit RC4 (1),
128-bit RC4 (2).'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( bigco bigcoProfileClass 267
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
)
6. Security issues
Integration of a RADIUS server with an LDAP-based directory service
can result in a variety of security threats, including:
Rogue LDAP-servers
Theft of passwords
Aboba [Page 19]
INTERNET-DRAFT 7 November 1997
Inappropriate use
These threats are discussed in turn.
6.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 service SHOULD be mutually authenticated via SSL/TLS or IPSEC.
6.2. Theft of passwords
RADIUS servers supporting PAP authentication SHOULD provide for confi-
dentiality of packets sent to and from the LDAP server. This can be
achieved using SSL/TLS or IPSEC ESP.
6.3. Inappropriate use
This schema is intended for use by a RADIUS server integrating with an
LDAP-enabled directory. This schema SHOULD NOT be used by devices
looking to access the directory directly.
LDAP-enabling of devices would introduce several security problems. As
described in [13], 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 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, 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
obtain access not only to RADIUS attributes for every user, but to
other information as well.
Aboba [Page 20]
INTERNET-DRAFT 7 November 1997
Beyond the security issues, LDAP-enabling of devices increases the
size of the device binaries, and may in some cases introduce dependen-
cies in the device boot sequence that can be problematic.
7. Acknowledgments
Thanks to Steven Judd, Ashwin Palekar, David Eitelbach, Narendra Gid-
wani and Donald Rule of Microsoft for useful discussions of this prob-
lem space.
8. 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. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April 1997.
[7] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April
1997.
[8] C. Rigney, W. Willats. "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." Internet 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." Internet Draft
(work in progress), draft-ietf-asid-ldapv3-tls-01.txt, Stanford, Crit-
ical Angle, June 1997.
Aboba [Page 21]
INTERNET-DRAFT 7 November 1997
[11] M. Wahl, T. Hoews, S. Kille, "Lightweight Directory Access Proto-
col (v3)." Internet Draft (work in progress), draft-ietf-asid-proto-
col-08.txt, Critical Angle, Netscape, Isode, October 1997.
[12] B. Aboba, "Lightweight Directory Access Protocol (v3): Dynamic
Attributes for the Remote Access Dialin User Service (RADIUS)." Inter-
net Draft (work in progress), draft-ietf-asid-ldapv3-dynradius-00.txt,
Microsoft, November 1997.
[13] B. Aboba, "Lightweight Directory Access Protocol (v3): Extension
for PPP Authentication" Internet Draft (work in progress), draft-ietf-
asid-ldapv3-ppp-00.txt, Microsoft, November 1997.
[14] T. Howes, L. Howard, "A Simple Caching Scheme for LDAP and X.500
Directories." Internet Draft (work in progress), draft-ietf-asid-
ldap-cache-01.txt, Netscape, October 1997.
9. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Aboba [Page 22]
