idnits 2.17.1 draft-aboba-radius-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 235 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 387 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 415: '... MAY ( radiusServiceType $ ...' RFC 2119 keyword, line 455: '... MUST (...' RFC 2119 keyword, line 458: '... MAY ( radiusServiceType $ ...' RFC 2119 keyword, line 490: '... MUST (...' RFC 2119 keyword, line 493: '... MAY ( npConstraint $ npSeq...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 18 has weird spacing: '... and may ...' == Line 19 has weird spacing: '...afts as refer...' == Line 22 has weird spacing: '... To learn...' == (230 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 February 1998) is 9549 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1115, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1126, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1140, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1143, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1155, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (ref. '1') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Unexpected draft version: The latest known version of draft-ietf-asid-ldapv3-attributes is -07, but you're referring to -08. == Outdated reference: A later version (-08) exists of draft-ietf-asid-ldapv3-dynamic-06 ** Obsolete normative reference: RFC 2138 (ref. '6') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '7') (Obsoleted by RFC 2866) == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-01 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '8') -- No information found for draft-ietf-asid-dynatt - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' -- No information found for draft-ietf-asid-ldapv3-tls - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' -- No information found for draft-ietf-asid-proto-col - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Normative reference to a draft: ref. '14' Summary: 18 errors (**), 0 flaws (~~), 20 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 5 5 February 1998 7 Lightweight Directory Access Protocol (v3): 8 Schema for the Remote Access Dialin User Service (RADIUS) 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as , and expires August 1, 1998. Please send com- 29 ments to the authors. 31 2. Abstract 33 This document defines a schema for the Remote Access Dialin User Ser- 34 vice (RADIUS). This schema makes it possible to integrate a RADIUS 35 server with an LDAP-based directory service, making it possible for an 36 organization to maintain a single store of user information. This con- 37 solidation is desirable since it results in a reduction in the admin- 38 istrative workload, and eliminates the need to synchronize across mul- 39 tiple user information stores. 41 3. Introduction 43 Today enterprises are looking to simplify the process of user adminis- 44 tration. With the advent of HR and personnel management systems, 45 information on a user is typically entered at the time of hiring, and 46 is retained until termination. If an LDAP-based directory is also 47 deployed, this necessitates synchronization with the of the personnel 48 database in order to maintain consistency. 50 Should the enterprise then deploy NAS devices or layer 2 tunneling 51 solutions, there may be a need to add a RADIUS server or if extended 52 security is required, a backend security server. Each of these may 53 require their own user information store. 55 Operating multiple stores of user information is not appealing, since 56 this may require rekeying of information or sychronization between 57 multiple stores, resulting in increased administrative costs. Main- 58 taining multiple stores also raises concerns about inconsistency and 59 replication delays. In order to avoid these problems, it is desirable 60 to consolidate stores of user information. One way this can be 61 achieved is to make it possible for RADIUS servers and security add- 62 ons to store their user information in an LDAP-based directory. 64 This document is one of three related specifications which describe 65 how a RADIUS server may be integrated with an LDAP-based directory 66 service. Reference [12] describes a schema designed for tracking ses- 67 sions in progress. Such information can be useful for a variety of 68 purposes including security incident response; simultaneous usage con- 69 trol; or monitoring of connection quality, login time, packet size or 70 bandwidth usage. Since this data change frequently, dynamic attributes 71 must be employed as described in [9]. Reference [13] describes how 72 user credentials submitted during PPP authentication may be validated 73 by the RADIUS server. 75 This document defines an LDAP schema for the Remote Access Dialin User 76 Service (RADIUS). The RADIUS protocol, described in [6]-[8], supports 77 authentication, authorization and accounting for dialup users. To 78 date, RADIUS servers have stored user data in a variety of ways, 79 including databases and flat files. A goal of this schema is tomake it 80 possible to add support for LDAP-based directory services to existing 81 RADIUS server implementations. In order to permit this schema to be 82 used with a wide range of directory service implementations, we avoid 83 reliance on features that have not been widely implemented, such as 84 multiple inheritance. 86 3.1. Objects and attributes 88 The RADIUS schema defined in this document requires support for sev- 89 eral new classes: radiusProfileClass, radiusPolicyClass, radiusDic- 90 tionaryClass, and eapDictionaryClass. The radiusProfileClass is used 91 to store RADIUS attributes relevant to groups of users. The radiusPol- 92 icyClass is used to describe conditions under which a given profile 93 may be applied. The radiusDictionaryClass is used to store the RADIUS 94 Dictionary. This provides extensibility and allows RADIUS profile 95 objects to be self describing. The eapDictionaryClass is used to store 96 a list mapping EAP Types to names. 98 The attributes in radiusProfileClass fall into two categories: 99 attributes present in the Access-Reply, and attributes representing 100 access constraints. An access constraint is a set of conditions that 101 must be satisfied in order for access to be granted. These are 102 expressed in the form of matching rules involving attributes present 103 in the Access-Reply, as well as other attributes such as the time of 104 day. For example, a matching rule involving the calledStationId and 105 time of day can be created in order to limit access to those calling a 106 given phone number during specified hours. 108 Attributes present in the Access-Reply are stored in the directory so 109 that the RADIUS server can retrieve them and include them in the 110 Access-Reply. Access constraints are stored in the directory so that 111 the RADIUS server can test the incoming Access-Request to determine 112 whether to proceed with authentication, or immediately send an Access- 113 Reject. Note that only static attributes present in Access-Reply need 114 be stored in the directory; attributes which are computed on the fly 115 can be recreated as needed. 117 The attributes in radiusPolicyClass represent conditions which must 118 hold for the profile indicated in radiusProfilePointer to be applied. 119 As with access constraints, these conditions may involve matching 120 rules applied to attributes in the Access-Request, as well as condi- 121 tions involving time of day, Nas-Port-Type, or group memberships. 123 For example, it may be desirable to give users different Session-Time 124 or Port-Limit attributes depending on the time of day, or group mem- 125 berships. This can be accomplished by creating policy expressions and 126 profiles for each time of day/group membership combination. Simi- 127 larly, it may be desirable to require that analog and ISDN callers do 128 callback or call from a particular callingStationId, while this may 129 not make sense for users connecting over a VPN. This can be accom- 130 plished by creating a policy expression that returns different pro- 131 files, depending on nasPortType. 133 3.2. Administrative model 135 The schema defined in this document includes user object attributes, 136 as well as profile and policy objects. 138 User object attributes are used in situations where it may be desir- 139 able to override behavior supplied in a profile, or where it is 140 desired that individual users be given an unique value for an 141 attribute. For example, where static addresses are assigned, each user 142 will typically have a different IP address; similarly, where callback 143 is used, callbackNumber will typically differ between users. 145 In the early versions of this document, it was envisaged that all 146 attributes would be contained within the user object. This is wasteful 147 because it is likely that groups of users will tend to have the same 148 parameter values. Thus a schema based solely on user-object results in 149 unnecessary replication, and also makes it difficult to change 150 attributes for all members of a group. 152 To reduce the replication problem, enable more effective caching, and 153 ease the administrative burden, profiles were added to the schema. 154 Profiles support definition of parameter sets which apply to a group 155 of users in a particular situation. Since it is expected that profiles 156 will apply to large group of users, they can be effectively cached. 157 Reference [14] describes how object caching can be supported within 158 LDAP-based directory services. 160 In an earlier version of this document, profiles could be related to 161 users via the radiusProfilePointer attribute included in the user 162 object. While this method of mapping users to profiles is still sup- 163 ported in this revision, this approach does not scale well, since it 164 requires administrators to modify the directory entries for each user, 165 in order to add the required radiusProfilePointer. Network administra- 166 tors typically manage the authorization process via group assignments, 167 and therefore will typically desire to fit profiles within the exist- 168 ing administrative model. In particular, it is highly desirable to 169 allow an administrator to change the profile values applying to a 170 group without having to edit the user objects for each member of the 171 group. 173 Several methods for binding a profile to a group suggest themselves. 174 Within this schema, the mapping is achieved via a policy object which 175 may include group membership among the conditions evaluated in assign- 176 ment of a profile. It should be noted that policy objects are not the 177 only way to bind profiles to groups, nor are they necessarily the most 178 efficient. For example, it is also possible to handle profile/group 179 binding via a table, or even by encoding policy restrictions on a user 180 certificate. The later may prove popular in the long term, given that 181 today many firms already encode privileges relating to time of day and 182 organizational function on employee badges. 184 The profile/group binding method chosen in this document was selected 185 primarily since it proved to be a degenerate case of the general con- 186 ditional profile problem. In this schema, we support the conditional 187 application of profiles, with the policy object expressing the condi- 188 tions that must be satisfied for a profile to be executed. Thus, pro- 189 file/group binding can be expressed as a condition (group membership) 190 resulting in assignment of a profile (the profile for that group). 192 3.2.1. User object attributes 194 This schema proposes addition of attributes to the user object. As 195 noted earlier, to enhance scalability, it is recommended that user 196 object attributes only be used in cases where profile overide is nec- 197 essary, or assignment of per-user attributes is required. Overide can 198 in principle be required for any attribute that may be included in the 199 Access-Reply, and so these attributes are among those that are added 200 to the user object. Examples of attributes that may be assigned on a 201 per-user basis include radiusFramedIPAddress, radiusCallbackNumber and 202 radiusFramedRoute. 204 Since many RADIUS parameters are expected to be identical for a group 205 of users, typically the user object will contain a small set of Radius 206 attributes. No user object attributes may be present if profiles are 207 being applied conditionally and no per-user values are required. 209 If it desired that a profile be unconditionally executed, then this 210 can be achieved either by creating a policy object with a radiusPro- 211 filePointer attribute but no npConstraint attribute, or by adding 212 radiusPolicyPointer (a distinguished name pointing to a RADIUS Profile 213 Object) as a user object attribute. 215 3.2.2. Profiles 217 Profile attributes fall into two major categories. One category of 218 attributes are static attributes that may be returned in an Access- 219 Reply. These attributes use a prefix of 'radius' and are included 220 within the profile so that the RADIUS server may copy the values into 221 the Access-Reply. 223 Another category of attributes are those which represent conditions 224 that must be satisfied for an Access-Accept to be sent. These 225 attributes use a prefix of 'np', which stands for Network Policy. 226 These attributes include npIPPoolName, npSessionsAllowed, npEAPType, 227 npConstraint, and npAuthenticationType. npSessionsAllowed is used to 228 limit the number of simultaneous sessions; npAuthenticationType indi- 229 cates the acceptable authentication types (PAP, CHAP, MS-CHAP, EAP); 230 npEAPType indicates the EAP-Type to be used to authenticate the user 231 if EAP is negotiated as an authentication type; npIPPoolName indicates 232 the name of the IP address pool that should be used in assigning the 233 user's IP address. npConstraint is a string attribute used to express 234 constraints based on time of day, or attributes present in the Access- 235 Request, such as NAS-Port-Type or NAS-Identifier. 237 Within this document, we allow profiles to include pointers to other 238 profiles, so that profiles may form a linked list. This allows a hier- 239 archy of profiles to be provided. More specific attributes overide 240 more general ones. 242 3.2.3. Example 244 All BIGCO employees are required to use token card authentication, and 245 thus in the company profile the radiusAuthenticationType attribute is 246 set to only allow EAP, and the radiusEAPType attribute is set for 247 BIGCO's token card type. BIGCO also sets up a marketing profile pro- 248 viding a radiusSessionTimeout value of 30 minutes, a radiusPortLimit 249 of one, and radiusFramedIpAddress set to indicate dynamic address 250 allocation. However, Fred requires a static IP address, and thus his 251 user object will contain a radiusFramedIpAddress attribute. 253 Since BIGCO profiles are unconditionally applied, a policy object with 254 a condition of (group == marketing) is used to assign a profile to 255 marketing personnel. Another policy object of lower priority is used 256 with no npConstraint attribute in order to assign a default profile. 258 3.3. Policy support 260 The schema described in this document provides for the conditional 261 application of a profile to a user via policy objects. Policy objects 262 make it possible to have profile A apply to a user in one set of cir- 263 cumstances, and profile B apply in another set of circumstances. They 264 also enable binding of profiles to groups. 266 Each policy object corresponds to an IF/THEN statement; multiple pol- 267 icy objects may be required to express complex policies. Attributes 268 in the policy object include npConstraint, a string attribute which 269 expresses the conditions under which a profile will be applied; npSe- 270 quence, an integer attribute which describes the order in which the 271 policy object will be evaluated; and radiusProfilePointer, a Distin- 272 guished Name pointing to the RADIUS profile that will be applied if 273 the conditions hold. The matching rule stored in npConstraint is an 274 expression which may reference other attribute values and include pat- 275 tern matching and other operations, such as equality tests. Policy 276 objects without an npConstraint attribute can be used to indicate 277 unconditional execution of a profile. 279 Although a simple Policy Object is presented in this schema, more com- 280 plex versions are possible. For example, a wider variety of operators 281 and pattern matches might be supported within npConstraint. 283 3.3.1. Example 285 Let us assume that BIGCO wishes to offer dialin access to their domes- 286 tic sales force, as well as VPN access to contractors and to individu- 287 als from the finance group travelling overseas. In order to consis- 288 tently manage and account for the use of their NAS devices and Layer 2 289 tunnel servers (PPTP/L2F/L2TP), BIGCO has chosen to adopt the RADIUS 290 protocol. However, given the large number of employees and contrac- 291 tors that need to be managed, BIGCO desires a RADIUS solution inte- 292 grated with their existing LDAP-based directory service and group 293 structure. This will allow the network administrator to edit the 294 user's RADIUS attributes with the same user-interface as they use to 295 edit other user attributes, profiles, and policies, and will eliminate 296 the need to maintain multiple stores of user information. 298 As part of this service offering, BIGCO may wish to implement a number 299 of policies. For example, in order to make sure that high speed dialin 300 access is available to the sales force when they need it, BIGCO may 301 wish to restrict use of the ISDN ports to sales personnel only during 302 the hours of 9-5, and permit the use of multilink. Since contractors 303 are only to be given access to selected subnets, BIGCO may wish to 304 apply a filter to their traffic. Since individuals in the finance 305 group often access highly confidential information over the VPN, BIGCO 306 may wish to require that these users authenticate via a smartcard, and 307 use only 128-bit encryption so as to provide for extended security. 308 For security reasons, BIGCO may wish to restrict contractors and 309 finance users to a single login at a time. 311 In certain cases, BIGCO may also wish to implement policies that 312 depend on the type of port that the user is connecting to. For exam- 313 ple, if the user is connecting via dialup, then it may be appropriate 314 to include tunnel attributes within the Access-Accept, so as to set up 315 a tunnel for the user. However, if the user is already connected via 316 a tunnel, this would not be necessary. Similarly, if BIGCO only has a 317 limited number of ISDN ports available, it may be desirable to set a 318 shorter Session-Timeout or Idle-Timeout on these ports, or to set 319 Port-Limit to one so as to not allow multi-link. The schema defined in 320 this document permits enforcement of these and many other policies. 322 3.4. Caching 324 Reference [14] describes a simple caching scheme for LDAP-based direc- 325 tories. A new operational attribute, ttl, is defined which specifies 326 the maximum time an object may remain in the cache. Such a caching 327 scheme is particularly beneficial for the schema presented in this 328 document, since it is expected that profiles and policies will apply 329 to large numbers of users. The first time the RADIUS server encounters 330 a pointer to a given profile or policy, the profile or policy will be 331 retrieved from the directory and cached. Subsequently, the profile or 332 policy may be retrieved from the cache, speeding the retrieval pro- 333 cess. As a result, it is to be expected that caching should result in 334 a substantial performance gain. As noted in [14], the ttl attribute 335 denotes the number of seconds that an entry may remain in the cache 336 before becoming stale. A value of 0 implies that the object must 337 not be cached. 339 3.5. Extensibility 341 Today vendors distinguish their RADIUS servers by a variety of means, 342 including the range of supported attributes (standard and vendor-spe- 343 cific), and the breadth of policies that may be represented. As a 344 result, while it is desirable to provide a common base set of classes 345 and attributes which all RADIUS schemas will share, RADIUS server 346 capabilities differ substantially from implementation to implementa- 347 tion, and a successful RADIUS schema definition must support this dif- 348 ferentiation. 350 The schema described in this document provides support for most of the 351 attributes defined in [6]-[8], as well as including support for the 352 RADIUS Dictionary and vendor-specific attributes, as well as condi- 353 tional application of profiles. Within this framework, vendor differ- 354 entiation can be achieved via two methods: adding attributes to the 355 base RADIUS profile and policy classes, or creating subclasses inher- 356 iting from the base classes. Adding attributes to the base class is 357 recommended in cases where the new attributes to be added do not con- 358 flict with those described in this document or in [6]-[8]. 360 Where conflicts do not arise, new attributes, including vendor-spe- 361 cific attributes, may be added to the RADIUS dictionary, which allows 362 RADIUS Profile objects to be self-describing. The goal is to allow 363 attributes to be added without having to require an update to the 364 RADIUS server code. Note however that a conventional RADIUS dictionary 365 is only designed to describe attributes that are sent on the wire, 366 while the RADIUS Dictionary object defined in this schema may also be 367 used to define additional non-wire attributes (such as radiusAuthenti- 368 cationType). This provides an additional element of flexibility, 369 allowing new attributes to be defined and used within 370 existing policy objects, without code changes. 372 Creating a sub-class is desirable in cases where conflicts are possi- 373 ble. Such conflicts can arise for example, when vendors have defined 374 attributes which conflict with the standard RADIUS attribute space 375 described in [6]-[8]. In this case, the radiusVendorId attribute 376 should included and set to the SMI Vendor Code, indicating that the 377 profile is specific to a given vendor, and contains potentially con- 378 flicting elements. Since a RADIUS server searching for a profile with 379 objectclass=radiusProfileClass will encounter both base class profiles 380 and subclasses, the radiusVendorId attribute is critical in allowing 381 an implementation to differentiate the profiles it can understand from 382 those that it cannot. Typically an implementation will only wish to 383 work with profiles whose radiusVendorId is either not present, zero 384 (IETF RADIUS) or set to their own SMI Vendor Code. As with addition of 385 attributes to the base class, when attributes are added to a subclass, 386 the RADIUS Dictionary class should modified to allow the subclass to 387 be self-describing. 389 Since it is conceivable that RADIU servers from two vendors may be 390 deployed simultaneously, both desiring to store objects in the same 391 LDAP-based directory service, and each implementing their own profile 392 subclass, a method must be provided to allow a user to have more than 393 one set of RADIUS profile and policy objects. This can be achieved by 394 allowing the radiusProfilePointer to point to a container object 395 rather than pointing to an object itself. The RADIUS server would then 396 search the container for a RADIUS profile or policy with an appropri- 397 ate radiusVendorId. 399 In order to prevent name conflicts, it is recommended that vendors 400 adding their own attributes prepend a suffix to all attribute names. 401 The IETF Schema Working Group has announced its intention to manage 402 suffix allocation in order to avoid name conflicts. Rather than 403 redefining existing attributes, vendor should create their own 404 attributes using suffixes in order to avoid conflict. 406 To illustrate how extensibility features may be used, the additional 407 attributes supported by a hypothetical BIGCO Profile Class are 408 included. 410 4. User object additions 412 The RADIUS schema proposes addition of the following attributes to the 413 user object: 415 MAY ( radiusServiceType $ radiusFramedProtocol $ radiusFramedIPAddress $ 416 radiusFramedIPNetmask $ radiusFramedRoute $ radiusFramedRouting $ 417 radiusFilterId $ radiusFramedMTU $ radiusFramedCompression $ 418 radiusLoginIPHost $ radiusLoginService $ radiusLoginTCPPort $ 419 radiusCallbackNumber $ radiusCallbackId $ radiusFramedRoute $ 420 radiusFramedIPXNetwork $ radiusClass $ radiusVSA $ 421 radiusSessionTimeout $ radiusIdleTimeout $ 422 radiusTerminationAction $ radiusCalledStationId $ 423 radiusCallingStationId $ radiusLoginLATService $ 424 radiusLoginLATNode $ radiusLoginLATGroup $ 425 radiusFramedAppleTalkLink $ radiusFramedAppleTalkNetwork $ 426 radiusFramedAppleTalkZone $ radiusPortLimit $ radiusLoginLATPort $ 427 radiusTunnelType $ radiusTunnelMediumType $ 428 radiusTunnelServerEndpoint $ radiusTunnelPrivateGroupId $ 429 radiusTunnelAssignmentId $ radiusTunnelClientEndpoint $ 430 radiusTunnelPreference $ radiusTunnelPassword $ 431 radiusArapFeatures $ radiusArapZoneAccess $ 432 radiusArapSecurity $ radiusPasswordRetry $ radiusPrompt $ 433 npSessionsAllowed $ npAuthenticationType $ npEAPType $ 434 npConstraint $ npIPPoolName $ radiusProfilePointer $ 435 radiusVendorId 436 ) 438 5. Object definitions 440 The RADIUS schema includes definition of the following objects: 442 RADIUS Profile Class 443 RADIUS Policy Class 444 RADIUS Dictionary Class 445 EAP Dictionary Class 447 5.1. RADIUS Profile Class 449 ( radiusProfileClass 1 450 NAME 'radiusProfile' 451 SUP profile 452 PARENT (country $ organization $ organizationalUnit $ 453 locality $ container) 454 STRUCTURAL 455 MUST ( 456 cn 457 ) 458 MAY ( radiusServiceType $ radiusFramedProtocol $ radiusFramedIPAddress $ 459 radiusFramedIPNetmask $ radiusFramedRoute $ radiusFramedRouting $ 460 radiusFilterId $ radiusFramedMTU $ radiusFramedCompression $ 461 radiusLoginIPHost $ radiusLoginService $ radiusLoginTCPPort $ 462 radiusCallbackNumber $ radiusCallbackId $ radiusFramedRoute $ 463 radiusFramedIPXNetwork $ radiusClass $ radiusVSA $ 464 radiusSessionTimeout $ radiusIdleTimeout $ 465 radiusTerminationAction $ radiusCalledStationId $ 466 radiusCallingStationId $ radiusLoginLATService $ 467 radiusLoginLATNode $ radiusLoginLATGroup $ 468 radiusFramedAppleTalkLink $ radiusFramedAppleTalkNetwork $ 469 radiusFramedAppleTalkZone $ radiusPortLimit $ radiusLoginLATPort $ 470 radiusTunnelType $ radiusTunnelMediumType $ 471 radiusTunnelServerEndpoint $ radiusTunnelPrivateGroupId $ 472 radiusTunnelAssignmentId $ radiusTunnelClientEndpoint $ 473 radiusTunnelPreference $ radiusTunnelPassword $ 474 radiusArapFeatures $ radiusArapZoneAccess $ 475 radiusArapSecurity $ radiusPasswordRetry $ radiusPrompt $ 476 npSessionsAllowed $ npAuthenticationType $ npEAPType $ 477 npConstraint $ npIPPoolName $ radiusProfilePointer $ 478 radiusVendorId $ radiusDictionaryPointer 479 ) 480 ) 482 5.2. RADIUS Policy Class 484 ( radiusPolicyClass 1 485 NAME 'radiusPolicy' 486 SUP policy 487 PARENT (country $ organization $ organizationalUnit $ 488 locality $ container) 489 STRUCTURAL 490 MUST ( 491 cn $ radiusProfilePointer 492 ) 493 MAY ( npConstraint $ npSequence 494 ) 495 ) 497 5.3. RADIUS Dictionary Class 499 ( radiusDictionaryClass 1 500 NAME 'radiusDictionaryClass' 501 SUP top 502 PARENT (country $ organization $ organizationalUnit $ 503 locality $ container) 504 STRUCTURAL 505 MUST ( 506 cn $ radiusDictionaryEntry 507 ) 508 ) 510 5.4. EAP Dictionary Class 512 ( eapDictionaryClass 1 513 NAME 'eapDictionaryClass' 514 SUP top 515 PARENT (country $ organization $ organizationalUnit $ 516 locality $ container) 518 STRUCTURAL 519 MUST ( 520 cn $ eapDictionaryEntry 521 ) 522 ) 524 5.5. BIGCO Profile Class 526 As described earlier, the base classes may be extended by attribute 527 addition, subclassing, or both. An example of the subclassing approach 528 is illustrated below. Here the bigcoProfileClass is created as a sub- 529 class of the radiusProfileClass and adds several attributes, each of 530 which uses bigco as a suffix to avoid name collisions. 532 ( bigcoProfileClass 1 533 NAME 'bigcoProfile' 534 SUP radiusProfileClass 535 PARENT (country $ organization $ organizationalUnit $ 536 locality $ container) 537 STRUCTURAL 538 MUST ( 539 ) 540 MAY ( bigcoBapRequired $ bigcoBapLinednLimit $ bigcoBapLinednTime $ 541 bigcoDynDirServer 542 ) 543 ) 545 6. Attribute definitions 547 6.1. New Attribute Types Used in the user object and RADIUS Profile 548 Class 550 ( radius radiusProfileClass 6 551 NAME 'radiusServiceType' 552 DESC 'The service to be provided to the user. 553 Values include: Login(1), Framed(2), 554 Callback Login(3), Callback Framed(4), 555 Outbound(5), Administrative(6), NAS Prompt(7), 556 Authenticate Only(8), Callback NAS Prompt(9)' 557 EQUALITY integerMatch 558 SYNTAX 'INTEGER' 559 SINGLE-VALUE 560 ) 562 ( radius radiusProfileClass 7 563 NAME 'radiusFramedProtocol' 564 DESC 'For Framed service, the protocol to be 565 provided to the user. Values include 566 PPP(1), SLIP(2), ARAP(3), Gandalf(4), 567 Xylogics(5)' 569 EQUALITY integerMatch 570 SYNTAX 'INTEGER' 571 SINGLE-VALUE 572 ) 574 ( radius radiusProfileClass 8 575 NAME 'radiusFramedIPAddress' 576 DESC 'IP address to be assigned to the user 577 in dotted decimal notation' 578 EQUALITY integerMatch 579 SYNTAX 'INTEGER' 580 SINGLE-VALUE 581 ) 583 ( radius radiusProfileClass 9 584 NAME 'radiusFramedIPNetmask' 585 DESC 'Netmask to apply to the user 586 in dotted decimal notation' 587 EQUALITY integerMatch 588 SYNTAX 'INTEGER' 589 SINGLE-VALUE 590 ) 592 ( radius radiusProfileClass 10 593 NAME 'radiusFramedRouting' 594 DESC 'Routing method for the user. 595 Values include None(1), Send(2), 596 Listen(3), Send & Listen(4)' 597 EQUALITY integerMatch 598 SYNTAX 'INTEGER' 599 SINGLE-VALUE 600 ) 602 ( radius radiusProfileClass 11 603 NAME 'radiusFilterId' 604 DESC 'String representing the filter list for the user' 605 EQUALITY caseIgnoreIA5Match 606 SYNTAX 'IA5String{128}' 607 ) 609 ( radius radiusProfileClass 12 610 NAME 'radiusFramedMTU' 611 DESC 'Maximum Transmission Unit for the user' 612 EQUALITY integerMatch 613 SYNTAX 'INTEGER' 614 SINGLE-VALUE 615 ) 617 ( radius radiusProfileClass 13 618 NAME 'radiusFramedCompression' 619 DESC 'Compression protocol to be used on 620 the link. Values include: None(1), 621 VJ compression(2), 622 IPX header compression(3)' 624 EQUALITY integerMatch 625 SYNTAX 'INTEGER' 626 ) 628 ( radius radiusProfileClass 14 629 NAME 'radiusLoginIPHost' 630 DESC 'System with which to connect the user 631 in dotted decimal notation' 632 EQUALITY integerMatch 633 SYNTAX 'INTEGER' 634 ) 636 ( radius radiusProfileClass 15 637 NAME 'radiusLoginService' 638 DESC 'Service to be used to connect the user to 639 the login host. Values include Telnet(1), Rlogin(2), 640 TCP Clear(3), PortMaster(4), and LAT(5)' 641 EQUALITY integerMatch 642 SYNTAX 'INTEGER' 643 SINGLE-VALUE 644 ) 646 ( radius radiusProfileClass 16 647 NAME 'radiusLoginTCPPort' 648 DESC 'The TCP port with which the user is 649 to be connected' 650 EQUALITY integerMatch 651 SYNTAX 'INTEGER' 652 SINGLE-VALUE 653 ) 655 ( radius radiusProfileClass 19 656 NAME 'radiusCallbackNumber' 657 DESC 'Number to be called' 658 EQUALITY caseIgnoreIA5Match 659 SYNTAX 'IA5String{128}' 660 SINGLE-VALUE 661 ) 663 ( radius radiusProfileClass 20 664 NAME 'radiusCallbackId' 665 DESC 'Name of place to be called' 666 EQUALITY caseIgnoreIA5Match 667 SYNTAX 'IA5String{128}' 668 SINGLE-VALUE 669 ) 671 ( radius radiusProfileClass 22 672 NAME 'radiusFramedRoute' 673 DESC 'Routes to be plumbed for the user' 674 EQUALITY caseIgnoreIA5Match 675 SYNTAX 'IA5String{128}' 676 ) 678 ( radius radiusProfileClass 23 679 NAME 'radiusFramedIPXNetwork' 680 DESC 'IPX Network number to be configured 681 for the user' 682 EQUALITY integerMatch 683 SYNTAX 'INTEGER' 684 SINGLE-VALUE 685 ) 687 ( radius radiusProfileClass 24 688 NAME 'radiusClass' 689 DESC 'Class attribute for the user' 690 SYNTAX 'OCTETSTRING' 691 ) 693 ( radius radiusProfileClass 25 694 NAME 'radiusVSA' 695 DESC 'Vendor Specific Attribute 696 for the user' 697 SYNTAX 'OCTETSTRING' 698 ) 700 ( radius radiusProfileClass 27 701 NAME 'radiusSessionTimeout' 702 DESC 'Per-session time limit in seconds. 703 After this expires, the action specified 704 in Termination-Action is taken' 705 EQUALITY integerMatch 706 SYNTAX 'INTEGER' 707 SINGLE-VALUE 708 ) 710 ( radius radiusProfileClass 28 711 NAME 'radiusIdleTimeout' 712 DESC 'The maximum number of consecutive 713 seconds of idle connection allowed 714 before session termination' 715 EQUALITY integerMatch 716 SYNTAX 'INTEGER' 717 SINGLE-VALUE 718 ) 720 ( radius radiusProfileClass 29 721 NAME 'radiusTerminationAction' 722 DESC 'Action taken when specified service is 723 completed. Values include Default(1) 724 or RADIUS-Request(2)' 725 EQUALITY integerMatch 726 SYNTAX 'INTEGER' 727 SINGLE-VALUE 728 ) 730 ( radius radiusProfileClass 34 731 NAME 'radiusLoginLATService' 732 DESC 'Identity of the LAT service to use' 733 EQUALITY caseIgnoreIA5Match 734 SYNTAX 'IA5String{128}' 735 SINGLE-VALUE 736 ) 738 ( radius radiusProfileClass 35 739 NAME 'radiusLoginLATNode' 740 DESC 'The node with which the user is to be 741 automatically connected by LAT' 742 EQUALITY caseIgnoreIA5Match 743 SYNTAX 'IA5String{128}' 744 SINGLE-VALUE 745 ) 747 ( radius radiusProfileClass 36 748 NAME 'radiusLoginLATGroup' 749 DESC 'The LAT group codes which this user 750 is authorized to use' 751 EQUALITY caseIgnoreIA5Match 752 SYNTAX 'IA5String{128}' 753 SINGLE-VALUE 754 ) 756 ( radius radiusProfileClass 37 757 NAME 'radiusFramedAppleTalkLink' 758 DESC 'The AppleTalk network number which 759 should be used for the user' 760 EQUALITY caseIgnoreIA5Match 761 SYNTAX 'INTEGER' 762 SINGLE-VALUE 763 ) 765 ( radius radiusProfileClass 38 766 NAME 'radiusFramedAppleTalkNetwork' 767 DESC 'The AppleTalk network number which 768 the NAS should probe to allocate an 769 AppleTalk node for the user' 770 EQUALITY caseIgnoreIA5Match 771 SYNTAX 'INTEGER' 772 ) 774 ( radius radiusProfileClass 39 775 NAME 'radiusFramedAppleTalkZone' 776 DESC 'The name of the Default AppleTalk Zone' 777 EQUALITY caseIgnoreIA5Match 778 SYNTAX 'IA5String{128}' 779 SINGLE-VALUE 780 ) 782 ( radius radiusProfileClass 62 783 NAME 'radiusPortLimit' 784 DESC 'Maximum number of ports to be provided' 785 EQUALITY integerMatch 786 SYNTAX 'INTEGER' 787 SINGLE-VALUE 788 ) 790 ( radius radiusProfileClass 39 791 NAME 'radiusLoginLATPort' 792 DESC 'The Port with which the user is to 793 connected by LAT' 794 EQUALITY caseIgnoreIA5Match 795 SYNTAX 'IA5String{128}' 796 SINGLE-VALUE 797 ) 799 ( radius radiusProfileClass 64 800 NAME 'radiusTunnelType' 801 DESC 'String representing the type of tunnel to 802 be set up, of the form Tag: Value. Values 803 include PPTP(1), L2F(2), L2TP(3), ATMP(4), 804 VTP(5), AH(6), IP-IP(7).' 805 SYNTAX 'OCTETSTRING' 806 ) 808 ( radius radiusProfileClass 65 809 NAME 'radiusTunnelMediumType' 810 DESC 'String representing the medium for the tunnel to 811 run over, of the form Tag: Value. Values 812 include IP(1), X.25(2), ATM(3), Frame Relay(4).' 813 SYNTAX 'OCTETSTRING' 814 ) 816 ( radius radiusProfileClass 67 817 NAME 'radiusTunnelServerEndpoint' 818 DESC 'String representing the address of the tunnel 819 server, of the form Tag: Value. The format 820 of the value field depends on the tunnelMediumType 821 attribute' 822 SYNTAX 'OCTETSTRING' 823 ) 825 ( radius radiusProfileClass ? 826 NAME 'radiusTunnelPrivateGroupId' 827 DESC 'String representing the Private Group Id for the 828 tunnel, of the form Tag: Value.' 829 SYNTAX 'OCTETSTRING' 830 ) 832 ( radius radiusProfileClass ? 833 NAME 'radiusTunnelPreference' 834 DESC 'String representing the tunnel preference for the 835 tunnel, of the form Tag: Value.' 836 SYNTAX 'OCTETSTRING' 837 ) 839 ( radius radiusProfileClass ? 840 NAME 'radiusTunnelAssignmentId' 841 DESC 'String representing the Tunnel Assignment Id for the 842 tunnel, of the form Tag: Value.' 843 SYNTAX 'OCTETSTRING' 844 ) 846 ( radius radiusProfileClass ? 847 NAME 'radiusTunnelClientEndpoint' 848 DESC 'String representing the Tunnel Client Endpoint for the 849 tunnel, of the form Tag: Value.' 850 SYNTAX 'OCTETSTRING' 851 ) 853 ( radius radiusProfileClass 71 854 NAME 'radiusArapFeatures' 855 DESC 'This is a compound string containing info that 856 the NAS should send to the user in the ARAP 857 feature flags packet' 858 EQUALITY caseIgnoreIA5Match 859 SYNTAX 'IA5String{128}' 860 SINGLE-VALUE 861 ) 863 ( radius radiusProfileClass 72 864 NAME 'radiusArapZoneAccess' 865 DESC 'This field controls access to ARAP zones. 866 Values include 867 Only allow access to default zone(1), 868 Use zone filter inclusively(2), 869 Use zone filter exclusively (4)' 870 EQUALITY integerMatch 871 SYNTAX 'INTEGER' 872 SINGLE-VALUE 873 ) 875 ( radius radiusProfileClass 73 876 NAME 'radiusArapSecurity' 877 DESC 'This field contains an integer 878 specifying the security module signature, 879 which is a Macintosh OSType' 880 EQUALITY integerMatch 881 SYNTAX 'INTEGER' 882 SINGLE-VALUE 883 ) 885 ( radius radiusProfileClass 75 886 NAME 'radiusPasswordRetry' 887 DESC 'This is an integer specifying the number 888 of password retry attempts to permit the user' 889 EQUALITY integerMatch 890 SYNTAX 'INTEGER' 891 SINGLE-VALUE 892 ) 894 ( radius radiusProfileClass 76 895 NAME 'radiusPrompt' 896 DESC 'This attribute is used only in RADIUS 897 Access-Challenge packets and indicates 898 if the NAS should echo the user's response 899 as entered. Values include No Echo (0), or Echo(1).' 900 EQUALITY integerMatch 901 SYNTAX 'INTEGER' 902 SINGLE-VALUE 903 ) 905 ( radius radiusProfileClass 257 906 NAME 'npEAPType' 907 DESC 'Allowable EAP types, in order of preference. If this 908 attribute has a value, EAP must be included in the 909 allowable authentication types.' 910 EQUALITY caseIgnoreIA5Match 911 SYNTAX 'IA5String{128}' 912 SINGLE-VALUE 913 ) 915 ( radius radiusProfileClass 258 916 NAME 'npConstraint' 917 DESC 'A string expressing conditions which must hold 918 in order for an Access-Accept to be sent. The 919 string is of the format MATCH ( = 920 OR ) 921 TIMEOFDAY. Brackets () can be used to group. 922 When multiple msNPConstraints are present, all 923 of them must be satisfied in order for a profile 924 to be executed.' 925 EQUALITY caseIgnoreIA5Match 926 SYNTAX 'IA5String' 927 ) 929 ( radius radiusProfileClass 259 930 NAME 'npIPPoolName' 931 DESC 'The name of the IP Address Pool out of which 932 the user's IP address should be allocated.' 933 EQUALITY caseIgnoreIA5Match 934 SYNTAX 'IA5String' 935 ) 937 ( radius radiusProfileClass 260 938 NAME 'npSessionsAllowed' 939 DESC 'This attribute indicates the number of 940 simultaneous sessions allowed for this user.' 941 EQUALITY integerMatch 942 SYNTAX 'INTEGER' 943 SINGLE-VALUE 944 ) 946 ( radius radiusProfileClass 261 947 NAME 'npAuthenticationType' 948 DESC 'Allowable authentication types (EAP, CHAP, PAP, 949 MS-CHAP, etc.) in order of preference. If an attribute 950 isn't included, it isn't allowed.' 951 EQUALITY caseIgnoreIA5Match 952 SYNTAX 'IA5String{128}' 953 SINGLE-VALUE 954 ) 956 ( radius radiusProfileClass 262 957 NAME 'radiusProfilePointer' 958 DESC 'Distinguished Name of a RADIUS Profile Object.' 959 EQUALITY distinguishedNameMatch 960 SYNTAX 'DN' 961 SINGLE-VALUE 962 ) 964 ( radius radiusProfileClass 263 965 NAME 'radiusVendorId' 966 DESC 'SMI Vendor Id. A non-zero value denotes a 967 profile non-compliant with RFC 2138 and 2139.' 968 EQUALITY integerMatch 969 SYNTAX 'INTEGER' 970 SINGLE-VALUE 971 ) 973 ( radius radiusProfileClass 264 974 NAME 'radiusDictionaryPointer' 975 DESC 'A Distinguished Name pointing to 976 the RADIUS dictionary for this profile. If 977 not present the default dictionary is used.' 978 EQUALITY distinguishedNameMatch 979 SYNTAX 'DN' 980 SINGLE-VALUE 981 ) 983 6.2. New Attribute Types Used in the RADIUS Policy Class 985 ( radius radiusPolicyClass 2 986 NAME 'npSequence' 987 DESC 'An integer indicating the order in which policy objects 988 are to be evaluated.' 989 EQUALITY integerMatch 990 SYNTAX 'INTEGER' 991 SINGLE-VALUE 992 ) 994 6.3. New Attribute Types Used in the RADIUS Dictionary Class 996 ( radius radiusDictionaryClass 1 997 NAME 'dictionaryEntry' 998 DESC 'A dictionary entry in the RADIUS dictionary, 999 of the form Attribute-Number:[Vendor-Type:]ldapDisplayName:Type. 1000 Vendor-Type may only be present with Attribute-Number=26 1001 (Vendor Specific).' 1002 EQUALITY caseIgnoreIA5Match 1003 SYNTAX 'IA5String{128}' 1004 ) 1006 6.4. New Attribute Types Used in the BIGCO Profile Class 1008 ( bigco bigcoProfileClass 263 1009 NAME 'bigcoBapRequired' 1010 DESC 'This attribute indicates whether Bandwidth Allocation 1011 Protocol (BAP) is required for this user. Values include 1012 BAP Not Required (0) and BAP Required (1).' 1013 EQUALITY integerMatch 1014 SYNTAX 'INTEGER' 1015 SINGLE-VALUE 1016 ) 1018 ( bigco bigcoProfileClass 264 1019 NAME 'bigcoBapLinednLimit' 1020 DESC 'Percent of capacity utilized at which to bring a 1021 line down for this user. ' 1022 EQUALITY integerMatch 1023 SYNTAX 'INTEGER' 1024 SINGLE-VALUE 1025 ) 1027 ( bigco bigcoProfileClass 265 1028 NAME 'bigcoBapLinednTime' 1029 DESC 'Time in seconds for the capacity utilization calculation.' 1030 EQUALITY integerMatch 1031 SYNTAX 'INTEGER' 1032 SINGLE-VALUE 1033 ) 1035 ( bigco bigcoProfileClass 266 1036 NAME 'bigcoDynDirServer' 1037 DESC 'Fully qualified domain name or IP address of 1038 the dynamic directory server for this user.' 1039 EQUALITY caseIgnoreIA5Match 1040 SYNTAX 'IA5String{128}' 1041 SINGLE-VALUE 1042 ) 1044 7. Security issues 1046 Integration of a RADIUS server with an LDAP-based directory service 1047 can result in a variety of security threats, including: 1049 Rogue LDAP-servers 1050 Theft of passwords 1051 Inappropriate use 1053 These threats are discussed in turn. 1055 7.1. Rogue LDAP servers 1057 Were a rogue LDAP server to respond to queries from the RADIUS server 1058 and have its responses accepted, it is possible that users could gain 1059 inappropriate access to the network. In order to protect against this, 1060 the conversation between the RADIUS server and the LDAP-based direc- 1061 tory service SHOULD be mutually authenticated via SSL/TLS or IPSEC. 1063 7.2. Theft of passwords 1065 RADIUS servers supporting PAP authentication or attributes such as 1066 Tunnel-Password SHOULD provide for confidentiality of packets sent to 1067 and from the LDAP server. This can be achieved using SSL/TLS or IPSEC 1068 ESP. 1070 7.3. Inappropriate use 1072 This schema is intended for use by a RADIUS server integrating with an 1073 LDAP-enabled directory. This schema SHOULD NOT be used by devices 1074 looking to access the directory directly. 1076 LDAP-enabling of devices would introduce several security problems. As 1077 described in [13], LDAP-enabling a RADIUS server requires that the 1078 RADIUS server be given permissions to access a user's RADIUS objects 1079 and attributes. If the dynamic attributes described in [12] are sup- 1080 ported, then the RADIUS service must also be able to write those 1081 attributes to the DS. As a result, the administrator of the RADIUS 1082 server should exercise care to ensure that the RADIUS account password 1083 is not compromised. If at all possible, the RADIUS server should be 1084 physically secured. 1086 In contrast, LDAP-enabling of devices requires that devices be given 1087 these access-rights. This can be achieved by making the devices mem- 1088 bers of a group, and giving the group access rights to this portion of 1089 the schema. However, such an expansion of access rights is undesir- 1090 able, since while RADIUS servers can often be physically secured, 1091 widely deployed devices typically cannot be. 1093 Furthermore, direct use of LDAP across a WAN typically requires that 1094 LDAP pass through a firewall. This is problematic since LDAP-based 1095 directories can be used to store a wide variety of data, much of it 1096 sensitive. Thus without implementing an LDAP proxy to limit access 1097 only to appropriate portions of the schema, it is difficult to enforce 1098 security. Since humans are notoriously lax in administration of access 1099 rights, an attacker obtaining a device password would typically also 1100 obtain access not only to RADIUS attributes for every user, but to 1101 other information as well. 1103 Beyond the security issues, LDAP-enabling of devices increases the 1104 size of the device binaries, and may in some cases introduce dependen- 1105 cies in the device boot sequence that can be problematic. 1107 8. Acknowledgments 1109 Thanks to Steven Judd, Ashwin Palekar, David Eitelbach, Narendra Gid- 1110 wani and Donald Rule of Microsoft for useful discussions of this prob- 1111 lem space. 1113 9. References 1115 [1] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Pro- 1116 tocol." RFC 1777, March 1995. 1118 [2] "Information Processing Systems - Open Systems Interconnection - 1119 The Directory: Overview of Concepts, Models and Service." ISO/IEC JTC 1120 1/SC21, International Standard 9594-1, 1988. 1122 [3] "Information Processing Systems - Open Systems Interconnection - 1123 The Directory: Selected Object Classes." Recommendation X.521 ISO/IEC 1124 JTC 1/SC21, International Standard 9594-7, 1993. 1126 [4] M.Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory 1127 Access Protocol (v3): Attribute Syntax Definitions." Internet Draft 1128 (work in progress), draft-ietf-asid-ldapv3-attributes-08.txt, Critical 1129 Angle, Isode, Netscape, October 1997. 1131 [5] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access 1132 Protocol (v3): Extensions for Dynamic Directory Services." Internet 1133 Draft (work in progress), draft-ietf-asid-ldapv3-dynamic-06.txt, 1134 Microsoft, Critical Angle, September 1997. 1136 [6] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 1137 cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, 1138 Daydreamer, April 1997. 1140 [7] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 1141 1997. 1143 [8] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress, 1144 draft-ietf-radius-ext-01.txt, Livingston, June 1997. 1146 [9] Y. Yaacovi, M. Wahl, T. Genovese, "Lightweight Directory Access 1147 Protocol: Dynamic Attributes." Internet Draft (work in progress), 1148 draft-ietf-asid-dynatt-00.txt, Microsoft, Critical Angle, July 1997. 1150 [10] J. Hodges, R.L. Morgan, M. Wahl, "Lightweight Directory Access 1151 Protocol (v3): Extension for Transport Layer Security." Internet Draft 1152 (work in progress), draft-ietf-asid-ldapv3-tls-01.txt, Stanford, Crit- 1153 ical Angle, June 1997. 1155 [11] M. Wahl, T. Hoews, S. Kille, "Lightweight Directory Access Proto- 1156 col (v3)." Internet Draft (work in progress), draft-ietf-asid-proto- 1157 col-08.txt, Critical Angle, Netscape, Isode, October 1997. 1159 [12] B. Aboba, "Lightweight Directory Access Protocol (v3): Dynamic 1160 Attributes for the Remote Access Dialin User Service (RADIUS)." Inter- 1161 net Draft (work in progress), draft-aboba-dynradius-01.txt, Microsoft, 1162 November 1997. 1164 [13] B. Aboba, "Lightweight Directory Access Protocol (v3): Extension 1165 for PPP Authentication" Internet Draft (work in progress), draft- 1166 aboba-ppp-01.txt, Microsoft, November 1997. 1168 [14] T. Howes, L. Howard, "A Simple Caching Scheme for LDAP and X.500 1169 Directories." Internet Draft (work in progress), draft-ietf-asid- 1170 ldap-cache-01.txt, Netscape, October 1997. 1172 10. Authors' Addresses 1174 Bernard Aboba 1175 Microsoft Corporation 1176 One Microsoft Way 1177 Redmond, WA 98052 1179 Phone: 425-936-6605 1180 EMail: bernarda@microsoft.com