[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
     Network Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                               Microsoft
     <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-02.txt>, and  expires August 1, 1998.  Please  send  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,  this necessitates synchronization with the of the personnel
     database in order to maintain consistency.
     
     Should the enterprise then deploy NAS devices  or  layer  2  tunneling
     solutions,  there  may be a need to add a RADIUS server or if extended
     
     
     
     Aboba                                                         [Page 1]


     INTERNET-DRAFT                                         5 February 1998
     
     
     security is required, a backend security server.  Each  of  these  may
     require their own user information store.
     
     Operating  multiple stores of user information is not appealing, since
     this may require rekeying of  information  or  sychronization  between
     multiple  stores,  resulting  in increased administrative costs. Main-
     taining multiple stores also raises concerns about  inconsistency  and
     replication  delays. In order to avoid these problems, it is desirable
     to consolidate stores  of  user  information.  One  way  this  can  be
     achieved  is  to make it possible for RADIUS servers and security add-
     ons to store their user information in an LDAP-based directory.
     
     This document is one of three related  specifications  which  describe
     how  a  RADIUS  server  may be integrated with an LDAP-based directory
     service. Reference [12] describes a schema designed for tracking  ses-
     sions  in  progress.   Such information can be useful for a variety of
     purposes including security incident response; simultaneous usage con-
     trol;  or monitoring of connection quality, login time, packet size or
     bandwidth usage. Since this data change frequently, dynamic attributes
     must  be  employed  as  described in [9]. Reference [13] describes how
     user credentials submitted during PPP authentication may be  validated
     by the RADIUS server.
     
     This document defines an LDAP schema for the Remote Access Dialin User
     Service (RADIUS). The RADIUS protocol, described in [6]-[8],  supports
     authentication,  authorization  and  accounting  for dialup users.  To
     date, RADIUS servers have stored user  data  in  a  variety  of  ways,
     including databases and flat files. A goal of this schema is tomake it
     possible to add support for LDAP-based directory services to  existing
     RADIUS  server  implementations.  In order to permit this schema to be
     used with a wide range of directory service implementations, we  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. This provides  extensibility  and  allows  RADIUS  profile
     objects to be self describing. The eapDictionaryClass is used to store
     a list mapping EAP Types to names.
     
     The  attributes  in  radiusProfileClass  fall  into  two   categories:
     attributes  present  in  the Access-Reply, and attributes representing
     access constraints. An access constraint is a set of  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, as well as other attributes such as the time of
     day. For example, a matching rule involving  the  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.
     
     The  attributes  in  radiusPolicyClass represent conditions which must
     hold for the profile indicated in radiusProfilePointer to be  applied.
     As  with  access  constraints,  these  conditions may involve matching
     rules applied to attributes in the Access-Request, as well  as  condi-
     tions involving time of day, Nas-Port-Type, or group memberships.
     
     For  example, it may be desirable to give users different Session-Time
     or Port-Limit attributes depending on the time of 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 desirable to require that analog and ISDN callers do
     callback or call from a particular callingStationId,  while  this  may
     not  make  sense  for  users connecting over a VPN. This can be accom-
     plished by creating a policy expression that  returns  different  pro-
     files, depending on nasPortType.
     
     
     
     
     3.2.  Administrative model
     
     The  schema  defined in this document includes user object attributes,
     as well as profile and policy objects.
     
     User object attributes are used in situations where it may  be  desir-
     able  to  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. This is wasteful
     because  it  is likely that groups of users will tend to have the same
     parameter values. Thus a schema based solely on user-object results in
     unnecessary  replication,  and  also  makes  it  difficult  to  change
     attributes for all members of a group.
     
     To reduce the replication problem, enable more effective caching,  and
     ease  the  administrative  burden,  profiles were added to the schema.
     Profiles support definition of parameter sets which apply 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 profile overide is  nec-
     essary,  or assignment of per-user attributes is required. Overide can
     in principle be required for any attribute that may be included in the
     Access-Reply,  and  so these attributes are among those that are added
     to the user object. Examples of attributes that may be assigned  on  a
     per-user basis include radiusFramedIPAddress, radiusCallbackNumber and
     radiusFramedRoute.
     
     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 used to
     limit the number of 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
     if EAP is negotiated as an authentication type; npIPPoolName indicates
     the name of the IP address pool that should be used in  assigning  the
     user's  IP address. npConstraint is a string attribute used to express
     constraints based on time of day, or attributes present in the Access-
     Request, such as NAS-Port-Type or NAS-Identifier.
     
     Within  this  document, we allow profiles to include pointers to other
     profiles, so that profiles may form a linked list. This allows a hier-
     archy  of  profiles  to  be provided. More specific attributes overide
     more general ones.
     
     
     3.2.3.  Example
     
     All BIGCO employees are required to use token card authentication, and
     thus  in the company profile the radiusAuthenticationType attribute is
     set to only allow EAP, and the  radiusEAPType  attribute  is  set  for
     BIGCO's  token  card type. BIGCO also sets up a marketing profile pro-
     viding a radiusSessionTimeout value of 30 minutes,  a  radiusPortLimit
     of  one,  and  radiusFramedIpAddress  set  to indicate dynamic address
     allocation. However, Fred requires a static IP address, and  thus  his
     user object will contain a radiusFramedIpAddress attribute.
     
     Since BIGCO profiles are unconditionally applied, a policy object with
     a condition of (group == marketing) is used to  assign  a  profile  to
     marketing  personnel.  Another policy object of lower priority is used
     with no npConstraint attribute in order to assign a default profile.
     
     
     
     
     
     
     
     Aboba                                                         [Page 5]


     INTERNET-DRAFT                                         5 February 1998
     
     
     3.3.  Policy support
     
     The schema described in this document  provides  for  the  conditional
     application  of a profile to a user via policy objects. Policy objects
     make it possible to have profile A apply to a user in one set of  cir-
     cumstances, and profile B apply in another set of circumstances.  They
     also enable binding of profiles to groups.
     
     Each policy object corresponds to an IF/THEN statement; multiple  pol-
     icy  objects  may be required to express complex policies.  Attributes
     in the policy object include npConstraint, a  string  attribute  which
     expresses  the conditions under which a profile will be applied; npSe-
     quence, an integer attribute which describes the order  in  which  the
     policy  object  will be evaluated; and radiusProfilePointer, a Distin-
     guished Name pointing to the RADIUS profile that will  be  applied  if
     the  conditions  hold.  The matching rule stored in npConstraint is an
     expression which may reference other attribute values and include pat-
     tern  matching  and  other operations, such as equality tests.  Policy
     objects without an npConstraint attribute  can  be  used  to  indicate
     unconditional execution of a profile.
     
     Although a simple Policy Object is presented in this schema, more com-
     plex versions are possible. For example, a wider variety of  operators
     and pattern matches might be 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 group travelling overseas. In order to 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.  However, given the large number of employees  and  contrac-
     tors  that  need  to be managed, BIGCO desires a RADIUS solution inte-
     grated with their existing  LDAP-based  directory  service  and  group
     structure.   This  will  allow  the  network administrator to edit the
     user's RADIUS attributes with the same user-interface as they  use  to
     edit other user attributes, profiles, and policies, and will eliminate
     the need to maintain multiple stores of user information.
     
     As part of this service offering, BIGCO may wish to implement a number
     of policies. For example, in order to make sure that high speed dialin
     access is available to the sales force when they need  it,  BIGCO  may
     wish  to restrict use of the ISDN ports to sales personnel only during
     the hours of 9-5, and permit the use of multilink.  Since  contractors
     are  only  to  be  given access to selected subnets, BIGCO may wish to
     apply a filter to their traffic.  Since  individuals  in  the  finance
     group often access highly confidential information over the VPN, BIGCO
     may wish to require that these users authenticate via a smartcard, and
     use  only  128-bit  encryption so as to provide for extended security.
     For security reasons, BIGCO  may  wish  to  restrict  contractors  and
     finance users to a single login at a time.
     
     
     
     
     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 that the user is connecting to.  For  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 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. 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], as well as including support for the
     RADIUS Dictionary and vendor-specific attributes, as  well  as  condi-
     tional application of profiles.  Within this framework, vendor differ-
     entiation can be achieved via two methods: adding  attributes  to  the
     base  RADIUS profile and policy classes, or creating subclasses 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 con-
     flict with those described in this document or in [6]-[8].
     
     Where conflicts do not arise, new  attributes,  including  vendor-spe-
     cific  attributes, may be added to the RADIUS dictionary, which allows
     RADIUS Profile objects to be self-describing. The  goal  is  to  allow
     
     
     
     Aboba                                                         [Page 7]


     INTERNET-DRAFT                                         5 February 1998
     
     
     attributes  to  be  added  without  having to require an update to the
     RADIUS server code. Note however that a conventional RADIUS dictionary
     is  only  designed  to  describe attributes that are sent on the wire,
     while the RADIUS Dictionary object defined in this schema may also  be
     used to define additional non-wire attributes (such as radiusAuthenti-
     cationType). This  provides  an  additional  element  of  flexibility,
     allowing new attributes to be defined and used within
      existing policy objects, without code changes.
     
     Creating  a sub-class is desirable in cases where conflicts are possi-
     ble.  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  radiusVendorId  attribute
     should  included  and  set to the SMI Vendor Code, indicating that the
     profile is specific to a given vendor, and contains  potentially  con-
     flicting  elements. Since a RADIUS server searching for a profile with
     objectclass=radiusProfileClass will encounter both base class profiles
     and  subclasses,  the radiusVendorId attribute is critical in allowing
     an implementation to differentiate the profiles it can understand from
     those  that  it  cannot. Typically an implementation will only wish to
     work with profiles whose radiusVendorId is either  not  present,  zero
     (IETF RADIUS) or set to their own SMI Vendor Code. As with addition of
     attributes to the base class, when attributes are added to a subclass,
     the  RADIUS  Dictionary class should modified to allow the subclass to
     be self-describing.
     
     Since it is conceivable that 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  to  point  to  a container object
     rather than pointing to an object itself. The RADIUS server would then
     search  the container for a RADIUS profile or policy with an appropri-
     ate 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. Rather than
     redefining  existing  attributes,  vendor  should  create  their   own
     attributes using suffixes in order to avoid conflict.
     
     To  illustrate  how extensibility features may be used, the additional
     attributes  supported  by  a  hypothetical  BIGCO  Profile  Class  are
     included.
     
     
     4.  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
     
     
     5.1.  RADIUS Profile Class
     
        ( radiusProfileClass 1
            NAME 'radiusProfile'
            SUP profile
            PARENT (country $ organization $ organizationalUnit $
                   locality $ container)
            STRUCTURAL
            MUST (
                  cn
            )
            MAY ( radiusServiceType $ radiusFramedProtocol $ radiusFramedIPAddress $
                  radiusFramedIPNetmask $ radiusFramedRoute $ radiusFramedRouting $
                  radiusFilterId $ radiusFramedMTU $ radiusFramedCompression $
                  radiusLoginIPHost $ radiusLoginService $ radiusLoginTCPPort $
                  radiusCallbackNumber $ radiusCallbackId $ radiusFramedRoute $
                  radiusFramedIPXNetwork $ radiusClass $ radiusVSA $
                  radiusSessionTimeout $ radiusIdleTimeout $
                  radiusTerminationAction $ radiusCalledStationId $
                  radiusCallingStationId $ radiusLoginLATService $
     
     
     
     Aboba                                                         [Page 9]


     INTERNET-DRAFT                                         5 February 1998
     
     
                  radiusLoginLATNode $ radiusLoginLATGroup $
                  radiusFramedAppleTalkLink $ radiusFramedAppleTalkNetwork $
                  radiusFramedAppleTalkZone $ radiusPortLimit $ radiusLoginLATPort $
                  radiusTunnelType $ radiusTunnelMediumType $
                  radiusTunnelServerEndpoint $ radiusTunnelPrivateGroupId $
                  radiusTunnelAssignmentId $ radiusTunnelClientEndpoint $
                  radiusTunnelPreference $ radiusTunnelPassword $
                  radiusArapFeatures $ radiusArapZoneAccess $
                  radiusArapSecurity $ radiusPasswordRetry $ radiusPrompt $
                  npSessionsAllowed $ npAuthenticationType $ npEAPType $
                  npConstraint $ npIPPoolName $ radiusProfilePointer $
                  radiusVendorId $ radiusDictionaryPointer
           )
     )
     
     
     5.2.  RADIUS Policy Class
     
        ( radiusPolicyClass 1
            NAME 'radiusPolicy'
            SUP policy
            PARENT (country $ organization $ organizationalUnit $
                   locality $ container)
            STRUCTURAL
            MUST (
                  cn $ radiusProfilePointer
            )
            MAY ( npConstraint $ npSequence
            )
        )
     
     
     5.3.  RADIUS Dictionary Class
     
        ( radiusDictionaryClass 1
            NAME 'radiusDictionaryClass'
            SUP top
            PARENT (country $ organization $ organizationalUnit $
                 locality $ container)
            STRUCTURAL
            MUST (
                   cn $ radiusDictionaryEntry
            )
        )
     
     
     
     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 $ eapDictionaryEntry
            )
        )
     
     
     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 ( bigcoBapRequired $ bigcoBapLinednLimit $ bigcoBapLinednTime $
                  bigcoDynDirServer
            )
        )
     
     
     6.  Attribute definitions
     
     
     
     6.1.  New Attribute Types Used in the user object and  RADIUS  Profile
     Class
     
        ( radius radiusProfileClass 6
            NAME 'radiusServiceType'
            DESC 'The service to be provided to the user.
                  Values include: Login(1), Framed(2),
                  Callback Login(3), Callback Framed(4),
                  Outbound(5), Administrative(6), NAS Prompt(7),
                  Authenticate Only(8), Callback NAS Prompt(9)'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 7
            NAME 'radiusFramedProtocol'
            DESC 'For Framed service, the protocol to be
                  provided to the user. Values include
                  PPP(1), SLIP(2), ARAP(3), Gandalf(4),
                  Xylogics(5)'
     
     
     
     Aboba                                                        [Page 11]


     INTERNET-DRAFT                                         5 February 1998
     
     
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 8
            NAME 'radiusFramedIPAddress'
            DESC 'IP address to be assigned to the user
                 in dotted decimal notation'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 9
            NAME 'radiusFramedIPNetmask'
            DESC 'Netmask to apply to the user
                  in dotted decimal notation'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 10
            NAME 'radiusFramedRouting'
            DESC 'Routing method for the user.
                 Values include None(1), Send(2),
                 Listen(3), Send & Listen(4)'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 11
            NAME 'radiusFilterId'
            DESC 'String representing the filter list for the user'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
         )
     
        ( radius radiusProfileClass 12
            NAME 'radiusFramedMTU'
            DESC 'Maximum Transmission Unit for the user'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 13
            NAME 'radiusFramedCompression'
            DESC 'Compression protocol to be used on
                  the link. Values include: None(1),
                  VJ compression(2),
                  IPX header compression(3)'
     
     
     
     Aboba                                                        [Page 12]


     INTERNET-DRAFT                                         5 February 1998
     
     
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
         )
     
        ( radius radiusProfileClass 14
            NAME 'radiusLoginIPHost'
            DESC 'System with which to connect the user
                  in dotted decimal notation'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
         )
     
        ( radius radiusProfileClass 15
            NAME 'radiusLoginService'
            DESC 'Service to be used to connect the user to
                 the login host. Values include Telnet(1), Rlogin(2),
                 TCP Clear(3), PortMaster(4), and LAT(5)'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 16
            NAME 'radiusLoginTCPPort'
            DESC 'The TCP port with which the user is
                  to be connected'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 19
            NAME 'radiusCallbackNumber'
            DESC 'Number to be called'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 20
            NAME 'radiusCallbackId'
            DESC 'Name of place to be called'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 22
            NAME 'radiusFramedRoute'
            DESC 'Routes to be plumbed for the user'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
         )
     
     
     
     
     Aboba                                                        [Page 13]


     INTERNET-DRAFT                                         5 February 1998
     
     
        ( radius radiusProfileClass 23
            NAME 'radiusFramedIPXNetwork'
            DESC 'IPX Network number to be configured
                 for the user'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 24
            NAME 'radiusClass'
            DESC 'Class attribute for the user'
            SYNTAX 'OCTETSTRING'
         )
     
        ( radius radiusProfileClass 25
            NAME 'radiusVSA'
            DESC 'Vendor Specific Attribute
                 for the user'
            SYNTAX 'OCTETSTRING'
        )
     
        ( radius radiusProfileClass 27
            NAME 'radiusSessionTimeout'
            DESC 'Per-session time limit in seconds.
                 After this expires, the action specified
                 in Termination-Action is taken'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 28
            NAME 'radiusIdleTimeout'
            DESC 'The maximum number of consecutive
                 seconds of idle connection allowed
                  before session termination'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 29
            NAME 'radiusTerminationAction'
            DESC 'Action taken when specified service is
                  completed. Values include Default(1)
                  or RADIUS-Request(2)'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 34
            NAME 'radiusLoginLATService'
     
     
     
     Aboba                                                        [Page 14]


     INTERNET-DRAFT                                         5 February 1998
     
     
            DESC 'Identity of the LAT service to use'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 35
            NAME 'radiusLoginLATNode'
            DESC 'The node with which the user is to be
                 automatically connected by LAT'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 36
            NAME 'radiusLoginLATGroup'
            DESC 'The LAT group codes which this user
                 is authorized to use'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 37
            NAME 'radiusFramedAppleTalkLink'
            DESC 'The AppleTalk network number which
                 should be used for the user'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 38
            NAME 'radiusFramedAppleTalkNetwork'
            DESC 'The AppleTalk network number which
                 the NAS should probe to allocate an
                 AppleTalk node for the user'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'INTEGER'
         )
     
        ( radius radiusProfileClass 39
            NAME 'radiusFramedAppleTalkZone'
            DESC 'The name of the Default AppleTalk Zone'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 62
            NAME 'radiusPortLimit'
            DESC 'Maximum number of ports to be provided'
            EQUALITY integerMatch
     
     
     
     Aboba                                                        [Page 15]


     INTERNET-DRAFT                                         5 February 1998
     
     
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 39
            NAME 'radiusLoginLATPort'
            DESC 'The Port with which the user is to
                 connected by LAT'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 64
            NAME 'radiusTunnelType'
            DESC 'String representing the type of tunnel to
                 be set up, of the form Tag: Value. Values
                 include PPTP(1), L2F(2), L2TP(3), ATMP(4),
                 VTP(5), AH(6), IP-IP(7).'
            SYNTAX 'OCTETSTRING'
     )
     
        ( radius radiusProfileClass 65
            NAME 'radiusTunnelMediumType'
            DESC 'String representing the medium for the tunnel to
                  run over, of the form Tag: Value. Values
                 include IP(1), X.25(2), ATM(3), Frame Relay(4).'
            SYNTAX 'OCTETSTRING'
     )
     
        ( radius radiusProfileClass 67
            NAME 'radiusTunnelServerEndpoint'
            DESC 'String representing the address of the tunnel
                  server, of the form Tag: Value. The format
                  of the value field depends on the tunnelMediumType
                  attribute'
            SYNTAX 'OCTETSTRING'
     )
     
        ( radius radiusProfileClass ?
            NAME '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 16]


     INTERNET-DRAFT                                         5 February 1998
     
     
            NAME 'radiusTunnelAssignmentId'
            DESC 'String representing the Tunnel Assignment Id for the
                  tunnel, of the form Tag: Value.'
            SYNTAX '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 'radiusArapFeatures'
            DESC 'This is a compound string containing info that
                 the NAS should send to the user in the ARAP
                 feature flags packet'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 72
            NAME 'radiusArapZoneAccess'
            DESC 'This field controls access to ARAP zones.
                  Values include
                  Only allow access to default zone(1),
                  Use zone filter inclusively(2),
                  Use zone filter exclusively (4)'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 73
            NAME 'radiusArapSecurity'
            DESC 'This field contains an integer
                 specifying the  security module signature,
                 which is a Macintosh OSType'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 75
            NAME 'radiusPasswordRetry'
            DESC 'This is an integer specifying the number
                 of password retry attempts to permit the user'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
     
     
     
     Aboba                                                        [Page 17]


     INTERNET-DRAFT                                         5 February 1998
     
     
        ( radius radiusProfileClass 76
            NAME 'radiusPrompt'
            DESC 'This attribute is used only in RADIUS
                 Access-Challenge packets and indicates
                 if the NAS should echo the user's  response
                 as entered. Values include No Echo (0), or Echo(1).'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 257
            NAME 'npEAPType'
            DESC 'Allowable EAP types, in order of preference. If this
                  attribute has a value, EAP must be included in the
                  allowable authentication types.'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 258
            NAME 'npConstraint'
            DESC 'A string expressing conditions which must hold
                 in order for an Access-Accept to be sent. The
                 string is of the format MATCH ( <attribute> =
                 <pattern/value> OR <pattern/value>)  <AND/OR>
                 TIMEOFDAY. Brackets () can be used to group.
                 When multiple msNPConstraints are present, all
                 of them must be satisfied in order for a profile
                 to be executed.'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String'
         )
     
        ( radius radiusProfileClass 259
            NAME 'npIPPoolName'
            DESC 'The name of the IP Address Pool out of which
                  the user's IP address should be allocated.'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String'
         )
     
     ( radius radiusProfileClass 260
            NAME 'npSessionsAllowed'
            DESC 'This attribute indicates the number of
                 simultaneous sessions allowed for this user.'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 261
            NAME 'npAuthenticationType'
     
     
     
     Aboba                                                        [Page 18]


     INTERNET-DRAFT                                         5 February 1998
     
     
            DESC 'Allowable authentication types (EAP, CHAP, PAP,
                  MS-CHAP, etc.) in order of preference. If an attribute
                  isn't included, it isn't allowed.'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 262
            NAME 'radiusProfilePointer'
            DESC 'Distinguished Name of a RADIUS Profile Object.'
            EQUALITY distinguishedNameMatch
            SYNTAX 'DN'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 263
            NAME 'radiusVendorId'
            DESC 'SMI Vendor Id. A non-zero value denotes a
                 profile non-compliant with RFC 2138 and 2139.'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( radius radiusProfileClass 264
            NAME 'radiusDictionaryPointer'
            DESC 'A Distinguished Name pointing to
                 the RADIUS dictionary for this profile. If
                 not present the default dictionary is used.'
            EQUALITY distinguishedNameMatch
            SYNTAX 'DN'
            SINGLE-VALUE
         )
     
     
     
     6.2.  New Attribute Types Used in the RADIUS Policy Class
     
     
       ( radius radiusPolicyClass 2
           NAME 'npSequence'
           DESC 'An integer indicating the order in which policy objects
                 are to be evaluated.'
           EQUALITY integerMatch
           SYNTAX 'INTEGER'
           SINGLE-VALUE
       )
     
     
     6.3.  New Attribute Types Used in the RADIUS Dictionary Class
     
       ( radius radiusDictionaryClass 1
           NAME 'dictionaryEntry'
     
     
     
     Aboba                                                        [Page 19]


     INTERNET-DRAFT                                         5 February 1998
     
     
           DESC 'A dictionary entry in the RADIUS dictionary,
                 of the form Attribute-Number:[Vendor-Type:]ldapDisplayName:Type.
                 Vendor-Type may only be present with Attribute-Number=26
                 (Vendor Specific).'
           EQUALITY caseIgnoreIA5Match
           SYNTAX 'IA5String{128}'
       )
     
     
     6.4.  New Attribute Types Used in the BIGCO Profile Class
     
     
     ( bigco bigcoProfileClass 263
            NAME 'bigcoBapRequired'
            DESC 'This attribute indicates whether Bandwidth Allocation
                 Protocol (BAP) is required for this user. Values include
                 BAP Not Required (0) and BAP Required (1).'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
     ( bigco bigcoProfileClass 264
            NAME 'bigcoBapLinednLimit'
            DESC 'Percent of capacity utilized at which to bring a
                  line down for this user. '
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
     ( bigco bigcoProfileClass 265
            NAME 'bigcoBapLinednTime'
            DESC 'Time in seconds for the capacity utilization calculation.'
            EQUALITY integerMatch
            SYNTAX 'INTEGER'
            SINGLE-VALUE
         )
     
        ( bigco bigcoProfileClass 266
            NAME 'bigcoDynDirServer'
            DESC 'Fully qualified domain name or IP address of
                  the dynamic directory server for this user.'
            EQUALITY caseIgnoreIA5Match
            SYNTAX 'IA5String{128}'
            SINGLE-VALUE
         )
     
     
     7.  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.
     
     
     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.
     
     
     7.2.  Theft of passwords
     
     RADIUS servers supporting PAP authentication  or  attributes  such  as
     Tunnel-Password  SHOULD provide for confidentiality of packets sent to
     and from the LDAP server. This can be achieved using SSL/TLS or  IPSEC
     ESP.
     
     
     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.
     
     
     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.
     
     
     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,  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
     
     
     
     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.
     
     [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.
     
     
     
     10.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 425-936-6605
     EMail: bernarda@microsoft.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Aboba                                                        [Page 23]