view Side-By-Side changes
Date: Mon, 08 Apr 2002 22:24:56 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 21 Nov 1997 16:57:00 GMT
ETag: "2e7c99-cadd-3475bd5c"
Accept-Ranges: bytes
Content-Length: 51933
Connection: close
Content-Type: text/plain
Network Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
<draft-aboba-radius-01.txt>
19 November 1997
<draft-aboba-radius-02.txt>
5 February 1998
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-
aboba-radius-01.txt>,
aboba-radius-02.txt>, and expires June August 1, 1998. Please send comments com-
ments 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, and
is retained until termination. If an LDAP-based directory is also
deployed within the enterprise,
deployed, this necessities necessitates synchronization with the of the HR or personnel
database with the LDAP-based directory in order to maintain consistency.
Aboba [Page 1]
INTERNET-DRAFT 19 November 1997
Should the enterprise then seek to deploy NAS devices or layer 2 tun-
neling 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 store of user information.
The possibility of operating information store.
Operating multiple stores of user information is not appealing, since
this may require rekeying of information or sychronization between
multiple stores. Maintaining stores, resulting in increased administrative costs. Main-
taining multiple stores also results in increased maintenance costs, and raises concerns about inconsistency and
replication delays. In order to avoid this problem, these problems, it is desirable
to consolidate stores of user information. One way this can be
achieved is to make it possible for a RADIUS server servers and security add-
ons to store its 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. Due to the frequency of changes to Since this data, data change frequently, dynamic attributes
must be employed, employed as described in [9]. Reference [13] describes how
user credentials submitted during PPP authentication and
sent by the NAS in the RADIUS Access-Request 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], 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 A goal of the schema
described in this document schema is to make tomake 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, permit this schema is designed to be implementable on
used with a wide range of directory service implementations.
This requires avoiding implementations, we avoid
reliance on features that have not been widely implemented, such as
multiple inheritance.
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.
Dictionary. This along with the
vendorId attribute provides extensibility and allows RADIUS profile
objects to be self describ-
ing. describing. The eapDictionaryClass is used to store
a list mapping EAP Types to names.
Aboba [Page 2]
INTERNET-DRAFT 19 November 1997
The attributes in the radiusProfileClass fall into three two categories:
attributes present in the Access-Request, Access-Reply, and attributes representing
access constraints. An access constraint is a set of conditions that
must be satisfied in order for access to be granted. These are
expressed in the form of matching rules involving attributes present
in the Access-Reply, and as well as other attributes that do not travel over such as the time of
day. For example, a matching rule involving the wire. calledStationId and
Aboba [Page 2]
INTERNET-DRAFT 5 February 1998
time of day can be created in order to limit access to those calling a
given phone number during specified hours.
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. Access constraints are stored in the directory so that
the RADIUS server can test the incoming Access-Request to 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 directory; attributes which are computed on the fly
can be recreated as needed.
When stored in the directory,
The attributes included in the Access-
Request are used to radiusPolicyClass represent conditions required which must
hold for an Access-Accept
to be sent. For example, a callingStationId attribute can be stored in the directory profile indicated in order radiusProfilePointer 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 applied.
As with access by time of day.
The attributes in the radiusPolicyClass represent constraints, these conditions which may
be evaluated in order involve matching
rules applied to determine whether a given profile should be
applied. attributes in the Access-Request, as well as condi-
tions involving time of day, Nas-Port-Type, or group memberships.
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, day, or group mem-
berships. This can be accomplished by creating policy expressions and
profiles for each time of day/group membership combination. Simi-
larly, it may be desir-
able desirable to require that modem analog and ISDN callers do
callback or call from a particu-
lar particular callingStationId, while this may
not make sense for users connect-
ing connecting over a VPN. If this functionality is needed then policy objects
will need to be created, and attributes such as timeOfDay or portType
will This can be set. accom-
plished by creating a policy expression that returns different pro-
files, depending on nasPortType.
3.2. Profiles Administrative model
The RADIUS schema defined in this document is designed to support
attributes which apply to individual users, includes user object attributes,
as well as profile and policy objects.
User object attributes
which apply are used in situations where it may be desir-
able to groups of override behavior supplied in 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 be contained within the user object. However, this
approach allows a user to only have a single set of attributes. This is problematic in the case wasteful
because it is likely that the enterprise were groups of users will tend to attempt have the same
parameter values. Thus a schema based solely on user-object results in
unnecessary replication, and also makes it difficult to
deploy RADIUS servers from change
attributes for all members of a group.
To reduce the replication problem, enable more than one vendor, effective caching, and
ease the administrative burden, profiles were added to the schema.
Profiles support definition of parameter sets which apply to a group
of users in a particular situation. Since it is expected that profiles
Aboba [Page 3]
INTERNET-DRAFT 5 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 of this document, profiles could be related to
users via the radiusProfilePointer attribute included in the user
object. While this method of mapping users to profiles is still sup-
ported in this revision, this approach does not scale well, since it
requires administrators to modify the directory entries for each user,
in order to add the required radiusProfilePointer. Network administra-
tors typically manage the authorization process via group assignments,
and therefore will typically desire to fit profiles within the exist-
ing administrative model. In particular, it is highly desirable to
allow an administrator to change the profile values applying to a
group without having to edit the user objects for each member of the
group.
Several methods for binding a profile to a group suggest themselves.
Within this schema, the mapping is achieved via a policy object which
may include group membership among the conditions evaluated in assign-
ment of a profile. It should be noted that policy objects are not 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 table, or even by encoding policy restrictions 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 and
organizational function on employee badges.
The profile/group binding method chosen in this document was selected
primarily since it proved to be a degenerate case of the general con-
ditional profile problem. In this schema, we support the conditional
application of profiles, with the policy object expressing the condi-
tions that must be satisfied for a profile to be executed. Thus, pro-
file/group binding can be expressed as a condition (group membership)
resulting in assignment of a profile (the profile for that group).
3.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 use profile overide is nec-
essary, or assignment of dif-
ferent 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.
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 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. 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 required according used to
limit the situation.
Furthermore, since in many cases RADIUS attributes are shared by large
groups number of users, storing attributes in every simultaneous sessions; npAuthenticationType indi-
cates the acceptable authentication types (PAP, CHAP, MS-CHAP, EAP);
npEAPType indicates the EAP-Type to be used to authenticate the user object creates
unnecessary difficulty in changing
if EAP is negotiated as an authentication type; npIPPoolName indicates
the attributes of all members name of the IP address pool that should be used in assigning the
user's IP address. npConstraint is a
group, and requires replication of large amounts string attribute used to express
constraints based on time of redundant data.
As a result, day, or attributes present in the notion of a RADIUS profile was introduced. Access-
Request, such as NAS-Port-Type or NAS-Identifier.
Within this document, we allow profiles to include pointers to other profiles
or to a series of policies,
profiles, so that profiles may form a linked list. This allows a hierarchy hier-
archy of profiles to be provided. More specific
Aboba [Page 3]
INTERNET-DRAFT 19 November 1997 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.
3.2.3. Example
All BIGCO employees are required to use token card authentication, and
thus in the company profile the authenticationType radiusAuthenticationType attribute is
set to only allow EAP, and the EAP-Type radiusEAPType attribute is set for
BIGCO's token card type. BIGCO also sets up a marketing profile providing pro-
viding a session-
Timeout radiusSessionTimeout value of 30 minutes, a portLimit radiusPortLimit
of one, and framedIpAddress radiusFramedIpAddress set to indicate dynamic address
allocation. However, Fred requires a static IP address, and thus his
user object will contain a framedIpAddress
attribute as well as radiusFramedIpAddress attribute.
Since BIGCO profiles are unconditionally applied, a radiusProfilePointer policy object with
a condition of (group == marketing) is used to the Marketing 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. Policy support
The schema described in this document provides for the unconditional conditional
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 policy objects. Policy objects
make it may be desirable possible to have profile A apply to a user in one set of circumstances, cir-
cumstances, and profile B apply in another set of circum-
stances. Where a profile needs to be applied based on a set circumstances. They
also enable binding of condi-
tions, a user object or profile profiles to groups.
Each policy object corresponds to an IF/THEN statement; multiple pol-
icy objects may contain one or more RADIUS-
PolicyPointer attributes. The RADIUSPolicyPointer is a distinguished
name pointing be required to express complex policies. Attributes
in the policy object include npConstraint, a RADIUS Policy Objet. The RADIUSPolicyPointerClass
contains attributes reflecting string attribute which
expresses the conditions under which a given
RADIUS profile is to will be applied, along with applied; npSe-
quence, an integer attribute which describes the order in which the
policy object will be evaluated; and radiusProfilePointer, a RADIUSProfilePointer Distin-
guished Name pointing to the RADIUS profile itself that should will be applied when if
the conditions hold. Since a RADIUSPolicyPointer need only be used when there are
multiple conditions to evaluate, the RADIUSPolicyPointer attribute The matching rule stored in npConstraint is
multi-valued. A RADIUSPolicyPointer an
expression which may be reference other attribute values and include pat-
tern matching and other operations, such as equality tests. Policy
objects without an npConstraint attribute in the user
object or in can be used to indicate
unconditional execution of a RADIUS profile.
Although a relatively simple RADIUS Policy Object is presented in this schema, more complex com-
plex versions are possible. For example, it has been
suggested that regular expressions a wider variety of operators
and pattern matches might be allowed in policy attributes so
as to provide more advanced matching capabilities.
Aboba [Page 4]
INTERNET-DRAFT 19 November 1997 supported within npConstraint.
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 individu-
als from the finance
employees group travelling overseas. In order to consistently consis-
tently 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, However, given the large number of employees and contractors contrac-
tors that need to be managed, BIGCO desires a RADIUS solution integrated inte-
grated with their existing LDAP-based directory service. service and group
structure. This will allow the network administrator to edit the
user's RADIUS attributes with the same user-
interface user-interface as they use to
edit other user attributes, profiles, and policies, and will elimi-
nate eliminate
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 contractors
are only to be given access to a selected group of machines, subnets, BIGCO may wish to
apply a filter to their traffic. Since travelling individuals in the finance users
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.
Aboba [Page 6]
INTERNET-DRAFT 5 February 1998
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, exam-
ple, 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 enforcement 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 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.
Aboba [Page 5]
INTERNET-DRAFT 19 November 1997
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, retrieval pro-
cess. As a ttl attribute result, it is included to be expected that caching should result in the radiusProfileClass and radiusPolicyClass.
a substantial performance gain. As noted 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 as well as including support for the full range
RADIUS Dictionary and vendor-specific attributes, as well as condi-
tional application of policies that might
be desirable. Thus we expect that profiles. Within this framework, vendor extensions will be required
in most cases.
Vendor differentiation differ-
entiation can be achieved via two methods: adding attributes to the
base RADIUS profile and policy classes, or creating subclasses inheriting inher-
iting from the base classes. Adding attributes to the base class is
recommended in cases where the new attributes to be added do not conflict con-
flict with those described in this document or in [6]-[8].
Where conflicts do not arise, the vendorId attribute within the RADIUS
profile should new attributes, including vendor-spe-
cific attributes, may be set added 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 dictionary, which allows
RADIUS profile 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 the a conventional RADIUS dictio-
nary dictionary
is only designed to describe attributes that are sent on the
wire; wire,
while the RADIUS Dictionary object defined in this schema may also be
used to define additional non-wire attributes (such as authenticationType) are not
included, and thus such radiusAuthenti-
cationType). This provides an additional element of flexibility,
allowing new attributes typically cannot to be supported with-
out defined and used within
existing policy objects, without 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 radiusVendorId attribute
should be included and set to the SMI Vendor Code, indicating that the
profile is specific to a given vendor, and contains potentially conflicting con-
flicting elements. Since a RADIUS server searching for a profile with objectclass=radiusProfile-
Class
objectclass=radiusProfileClass will encounter both base class profiles
and subclasses, the ven-
dorId radiusVendorId attribute is critical in allowing
an implementation to
Aboba [Page 6]
INTERNET-DRAFT 19 November 1997 differentiate the profiles it can understand from
those that it can-
not. cannot. Typically an implementation will only wish to
work with profiles whose vendorId 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
also be modified to allow the subclass to
be self-describing.
Since it is conceivable that RADIUS RADIU 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. appropri-
ate 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 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 Working Group has announced its intention to manage
suffix allocation in order to avoid name conflicts. Rather than
redefining existing attributes, vendor should create their own
attributes using suffixes
for conflict avoidance. 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. 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 $ radiusArapZoneAccess $
radiusArapSecurity $ radiusPasswordRetry $ radiusPrompt $
npSessionsAllowed $ npAuthenticationType $ npEAPType $
npConstraint $ npIPPoolName $ radiusProfilePointer $
radiusVendorId
)
5. 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.
5.1. RADIUS Profile Class
( radiusProfileClass 1
NAME 'radiusProfile'
SUP profile
PARENT (country $ organization $ organizationalUnit $
locality $ container)
Aboba [Page 7]
INTERNET-DRAFT 19 November 1997
STRUCTURAL
MUST (
cn
)
MAY ( serviceType radiusServiceType $ framedProtocol radiusFramedProtocol $ framedIPAddress radiusFramedIPAddress $
framedIPNetmask
radiusFramedIPNetmask $ framedRouting radiusFramedRoute $
filterId radiusFramedRouting $ framedMTU
radiusFilterId $ framedCompression radiusFramedMTU $
loginIPHost radiusFramedCompression $ loginService
radiusLoginIPHost $ loginTCPPort radiusLoginService $
callbackNumber radiusLoginTCPPort $ callbackId
radiusCallbackNumber $ framedRoute radiusCallbackId $
framedIPXNetwork radiusFramedRoute $ sessionTimeout
radiusFramedIPXNetwork $ idleTimeout radiusClass $
terminationAction radiusVSA $ calledStationId
radiusSessionTimeout $ radiusIdleTimeout $ callingStationId
radiusTerminationAction $
loginLATService radiusCalledStationId $ loginLATNode
radiusCallingStationId $ loginLATGroup radiusLoginLATService $
framedAppleTalkLink
Aboba [Page 9]
INTERNET-DRAFT 5 February 1998
radiusLoginLATNode $ framedAppleTalkNetwork radiusLoginLATGroup $
framedAppleTalkZone
radiusFramedAppleTalkLink $ portLimit radiusFramedAppleTalkNetwork $ loginLATPort
radiusFramedAppleTalkZone $
tunnelType radiusPortLimit $ tunnelMediumType radiusLoginLATPort $ tunnelServerEndpoint
radiusTunnelType $
tunnelPrivateGroupId radiusTunnelMediumType $ arapFeatures
radiusTunnelServerEndpoint $ arapZoneAccess radiusTunnelPrivateGroupId $
arapSecurity
radiusTunnelAssignmentId $ passwordRetry radiusTunnelClientEndpoint $ prompt
radiusTunnelPreference $ ttl radiusTunnelPassword $
radiusArapFeatures $ radiusArapZoneAccess $
eapType
radiusArapSecurity $ sessionsAllowed radiusPasswordRetry $ authenticationType radiusPrompt $
vendorId
npSessionsAllowed $ timeOfDay npAuthenticationType $ radiusDictionary npEAPType $
npConstraint $ npIPPoolName $ radiusProfilePointer $ radiusPolicyPointer
radiusVendorId $ radiusDictionaryPointer
)
)
4.2.
5.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 npConstraint $ ttl $ vendorId npSequence
)
)
4.3.
5.3. RADIUS Dictionary Class
( radiusDictionaryClass 1
NAME 'radiusDictionaryClass'
SUP top
PARENT (country $ organization $ organizationalUnit $
locality $ container)
STRUCTURAL
MUST (
cn $ dictionaryEntry radiusDictionaryEntry
)
)
Aboba [Page 8]
INTERNET-DRAFT 19 November 1997
4.4.
5.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 $ dictionaryEntry eapDictionaryEntry
)
)
4.5.
5.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
)
)
5.
6. Attribute definitions
5.1.
6.1. New Attribute Types Used in the user object and RADIUS Profile
Class
( radius radiusProfileClass 6
NAME 'serviceType' 'radiusServiceType'
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
)
Aboba [Page 9]
INTERNET-DRAFT 19 November 1997
( radius radiusProfileClass 7
NAME 'framedProtocol' '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 'framedIPAddress' 'radiusFramedIPAddress'
DESC 'IP address to be assigned to the user
in dotted decimal notation'
EQUALITY caseIgnoreIA5Match integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 9
NAME 'framedIPNetmask' 'radiusFramedIPNetmask'
DESC 'Netmask to apply to the user
in dotted decimal notation'
EQUALITY caseIgnoreIA5Match integerMatch
SYNTAX 'IA5String{128}' 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 10
NAME 'framedRouting' '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
NAME 'filterId' 'radiusFilterId'
DESC 'String representing the filter list for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 12
NAME 'framedMTU' 'radiusFramedMTU'
DESC 'Maximum Transmission Unit for the user'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
Aboba [Page 10]
INTERNET-DRAFT 19 November 1997
( radius radiusProfileClass 13
NAME 'framedCompression' '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 'loginIPHost' 'radiusLoginIPHost'
DESC 'System with which to connect the user
in dotted decimal notation'
EQUALITY caseIgnoreIA5Match integerMatch
SYNTAX 'IA5String{128}' 'INTEGER'
)
( radius radiusProfileClass 15
NAME 'loginService' '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 'loginTCPPort' 'radiusLoginTCPPort'
DESC 'The TCP port with which the user is
to be connected'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 19
NAME 'callbackNumber' 'radiusCallbackNumber'
DESC 'Number to be called'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 20
NAME 'callbackId' 'radiusCallbackId'
DESC 'Name of place to be called'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 22
Aboba [Page 11]
INTERNET-DRAFT 19 November 1997
NAME 'framedRoute' '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 'framedIPXNetwork' 'radiusFramedIPXNetwork'
DESC 'IPX Network number to be configured
for the user'
EQUALITY caseIgnoreIA5Match integerMatch
SYNTAX 'IA5String{128}' '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'
)
( radius radiusProfileClass 27
NAME 'sessionTimeout' '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 'idleTimeout' '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 'terminationAction' '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 30
NAME 'calledStationId'
DESC 'Indicates that access is only allowed to these numbers'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
)
( radius radiusProfileClass 31
NAME 'callingStationId'
Aboba [Page 12]
INTERNET-DRAFT 19 November 1997
DESC 'Indicates that access is restricted and
only allowed from this phone number.' Default(1)
or RADIUS-Request(2)'
EQUALITY caseIgnoreIA5Match integerMatch
SYNTAX 'IA5String{128}' 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 34
NAME 'loginLATService' '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 'loginLATNode' '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
NAME 'loginLATGroup' 'radiusLoginLATGroup'
DESC 'The LAT group codes which this user
is authorized to use'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 37
NAME 'framedAppleTalkLink' 'radiusFramedAppleTalkLink'
DESC 'The AppleTalk network number which
should be used for the user'
EQUALITY caseIgnoreIA5Match
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 38
NAME 'framedAppleTalkNetwork' 'radiusFramedAppleTalkNetwork'
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' 'radiusFramedAppleTalkZone'
DESC 'The name of the Default AppleTalk Zone'
Aboba [Page 13]
INTERNET-DRAFT 19 November 1997
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 62
NAME 'portLimit' '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 'loginLATPort' 'radiusLoginLATPort'
DESC 'The Port with which the user is to
connected by LAT'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 64
NAME 'tunnelType' '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).'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' 'OCTETSTRING'
)
( radius radiusProfileClass 65
NAME 'tunnelMediumType' '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).'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' 'OCTETSTRING'
)
( radius radiusProfileClass 67
NAME 'tunnelServerEndpoint' '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'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' 'OCTETSTRING'
)
( radius radiusProfileClass ?
NAME 'tunnelPrivateGroupId' 'radiusTunnelPrivateGroupId'
DESC 'String representing the Private Group Id for the
tunnel, of the form Tag: Value.'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass ?
NAME 'radiusTunnelPreference'
DESC 'String representing the tunnel preference for the
tunnel, of the form Tag: Value.'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass ?
Aboba [Page 14] 16]
INTERNET-DRAFT 19 November 1997 5 February 1998
NAME 'radiusTunnelAssignmentId'
DESC 'String representing the Tunnel Assignment Id for the
tunnel, of the form Tag: Value.'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' 'OCTETSTRING'
)
( radius radiusProfileClass ?
NAME 'radiusTunnelClientEndpoint'
DESC 'String representing the Tunnel Client Endpoint for the
tunnel, of the form Tag: Value.'
SYNTAX 'OCTETSTRING'
)
( radius radiusProfileClass 71
NAME 'arapFeatures' '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 'arapZoneAccess' 'radiusArapZoneAccess'
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' '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 'passwordRetry' 'radiusPasswordRetry'
DESC 'This is an integer specifying the number
of password retry attempts to permit the user'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
Aboba [Page 17]
INTERNET-DRAFT 5 February 1998
( radius radiusProfileClass 76
NAME 'prompt' 'radiusPrompt'
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'
Aboba [Page 15]
INTERNET-DRAFT 19 November 1997
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' '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 'sessionsAllowed' '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
simultaneous sessions allowed for this user.'
EQUALITY integerMatch
SYNTAX 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 259 261
NAME 'authenticationType' '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 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' included, it isn't allowed.'
EQUALITY caseIgnoreIA5Match
Aboba [Page 16]
INTERNET-DRAFT 19 November 1997
SYNTAX 'IA5String{128}'
SINGLE-VALUE
)
( radius radiusProfileClass 262
NAME 'radiusDictionary' 'radiusProfilePointer'
DESC 'Distinguished Name pointing to the of a RADIUS Dictionary
for this object.' Profile Object.'
EQUALITY distinguishedNameMatch
SYNTAX 'DN'
SINGLE-VALUE
)
( radius radiusProfileClass 263
NAME 'radiusProfilePointer' 'radiusVendorId'
DESC 'Distinguished Name of 'SMI Vendor Id. A non-zero value denotes a RADIUS Profile Object.'
profile non-compliant with RFC 2138 and 2139.'
EQUALITY distinguishedNameMatch integerMatch
SYNTAX 'DN' 'INTEGER'
SINGLE-VALUE
)
( radius radiusProfileClass 264
NAME 'radiusPolicyPointer' 'radiusDictionaryPointer'
DESC 'Distinguished 'A Distinguished Name of a pointing to
the RADIUS policy object.' dictionary for this profile. If
not present the default dictionary is used.'
EQUALITY distinguishedNameMatch
SYNTAX 'DN'
SINGLE-VALUE
)
5.2.
6.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.'
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
Aboba [Page 17]
INTERNET-DRAFT 19 November 1997
NAME 'clientPrefixes' 'npSequence'
DESC 'String representing originating RADIUS Client
prefixes to 'An integer indicating the order in which this profile will apply.
If not present, this profile applies policy objects
are to all
prefixes.' be evaluated.'
EQUALITY caseIgnoreIA5Match integerMatch
SYNTAX 'IA5String{128}' 'INTEGER'
SINGLE-VALUE
)
5.3.
6.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}'
)
5.4.
6.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
)
( 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'
Aboba [Page 18]
INTERNET-DRAFT 19 November 1997
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.
7. Security issues
Integration of a RADIUS server with an LDAP-based directory service
can result in a variety of security threats, including:
Aboba [Page 20]
INTERNET-DRAFT 5 February 1998
Rogue LDAP-servers
Theft of passwords
Inappropriate use
These threats are discussed in turn.
6.1.
7.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.
Aboba [Page 19]
INTERNET-DRAFT 19 November 1997
6.2.
7.2. Theft of passwords
RADIUS servers supporting PAP authentication or attributes such as
Tunnel-Password SHOULD provide for confi-
dentiality confidentiality of packets sent to
and from the LDAP server. This can be achieved using SSL/TLS or IPSEC
ESP.
6.3.
7.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
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 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.
8. 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.
Aboba [Page 20]
INTERNET-DRAFT 19 November 1997
8.
9. 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, M.Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions. " 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. " 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
Aboba [Page 22]
INTERNET-DRAFT 5 February 1998
(work in progress), draft-ietf-asid-ldapv3-tls-01.txt, Stanford, Crit-
ical Angle, June 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-aboba-dynradius-01.txt, Microsoft,
November 1997.
[13] B. Aboba, "Lightweight Directory Access Protocol (v3): Extension
for PPP Authentication" Internet Draft (work in progress), draft-
aboba-ppp-01.txt, Microsoft, November 1997.
Aboba [Page 21]
INTERNET-DRAFT 19 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.
10. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
Aboba [Page 22] 23]
----