idnits 2.17.00 (12 Aug 2021) /tmp/idnits44508/draft-aboba-radius-05.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 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 456: '... MAY ( radiusServiceType $ radiusFrame...' RFC 2119 keyword, line 499: '... MUST (...' RFC 2119 keyword, line 502: '... MAY ( radiusServiceType $ radiu...' RFC 2119 keyword, line 543: '... MUST (...' RFC 2119 keyword, line 546: '... MAY ( npConstraint $ npSequence...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 911 has weird spacing: '...ing the secur...' == Line 1236 has weird spacing: '...>, and expir...' -- 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 (26 August 1999) is 8297 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '7' on line 1189 looks like a reference -- Missing reference section? '5' on line 1182 looks like a reference -- Missing reference section? '10' on line 1197 looks like a reference -- Missing reference section? '8' on line 1192 looks like a reference -- Missing reference section? '9' on line 1194 looks like a reference -- Missing reference section? '1' on line 1168 looks like a reference -- Missing reference section? '2' on line 1172 looks like a reference -- Missing reference section? '3' on line 1174 looks like a reference -- Missing reference section? '4' on line 1179 looks like a reference -- Missing reference section? '6' on line 1185 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Experimental 4 5 26 August 1999 6 Expires: March 1, 2000 8 Lightweight Directory Access Protocol (v3): 9 Schema for the Remote Access Dialin User Service (RADIUS) 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 2. Copyright Notice 35 Copyright (C) The Internet Society (1999). All Rights Reserved. 37 3. Abstract 39 This document defines a schema for the Remote Access Dialin User Service 40 (RADIUS). This schema makes it possible to integrate a RADIUS server 41 with an LDAP-based directory service, making it possible for an 42 organization to maintain a single store of user information. This 43 consolidation is desirable since it results in a reduction in the 44 administrative workload, and eliminates the need to synchronize across 45 multiple user information stores. 47 4. Introduction 49 Today enterprises are looking to simplify the process of user 50 administration by replacing application-specific directories with a 51 unified directory service based on LDAP v3, described in [5]-[6]. 52 Maintaining multiple stores of user information is unappealing, since 53 this may require rekeying of information or sychronization between 54 multiple stores, resulting in increased administrative costs. 55 Maintaining multiple stores also raises concerns about inconsistency and 56 replication delays. 58 With the advent of enterprise resource planning (ERP) and personnel 59 management systems, information on a user is typically entered at the 60 time of hiring, and is retained until termination. If an LDAP-based 61 directory is also deployed, this necessitates synchronization with the 62 of the personnel database in order to maintain consistency. Should the 63 enterprise then deploy NAS devices or layer 2 tunneling solutions, there 64 may be a need to add a RADIUS server or if extended security is 65 required, a backend security server. Each of these may require their own 66 user information store. In order to avoid these problems, it is 67 desirable to consolidate stores of user information. One way this can be 68 achieved is to make it possible for RADIUS servers and security add-ons 69 to store their user information in an LDAP-based directory. 71 This document defines an LDAP schema for the Remote Access Dialin User 72 Service (RADIUS). The RADIUS protocol, described in [1]-[4], supports 73 authentication, authorization and accounting for dialup users. To date, 74 RADIUS servers have stored user data in a variety of ways, including 75 databases and flat files. A goal of this schema is to make it possible 76 to add support for LDAP-based directory services to existing RADIUS 77 server implementations. In order to permit this schema to be used with a 78 wide range of directory service implementations, it is necessary to 79 avoid reliance on features that have not been widely implemented, such 80 as multiple inheritance. 82 4.1. Administrative model 84 The schema defined in this document includes user object attributes, as 85 well as profile and policy objects. 87 User object attributes are used in situations where it may be desirable 88 to override behavior supplied in a profile, or where it is desired that 89 individual users be given an unique value for an attribute. For example, 90 where static addresses are assigned, each user will typically have a 91 different IP address. Similarly, where callback is used, callbackNumber 92 will typically differ between users. 94 However, it is not desirable to depend exclusively on user object 95 attributes. Since it is likely that groups of users will tend to have 96 the same parameter values, an implementation based solely on user-object 97 attributes results in unnecessary replication, and also makes it 98 difficult to change attributes for all members of a group. 100 To reduce the replication problem, enable more effective caching, and 101 ease the administrative burden, profile objects are required. Profiles 102 support definition of parameter sets which apply to a group of users in 103 a particular situation. Since it is expected that profiles will apply to 104 large group of users, they can be effectively cached. 106 Network administrators typically manage the authorization process via 107 group assignments, and therefore will typically desire to fit profiles 108 within the existing administrative model. In particular, it is highly 109 desirable to allow an administrator to change the profile values 110 applying to a group without having to edit the user objects for each 111 member of the group. 113 Within this schema, the mapping from profiles to groups is achieved via 114 policy objects which contain the conditions that must be satisfied for a 115 profile to be assigned, as well as a pointer to that profile. Group 116 membership may be included among the conditions evaluated in assignment 117 of a profile. Thus, profile/group binding can be expressed as a 118 condition (group membership) resulting in assignment of a profile (the 119 profile for that group). 121 It should be noted that policy objects are not the only way to bind 122 profiles to groups, nor are they necessarily the most efficient. For 123 example, it is also possible to handle profile/group binding via a 124 table, or even by encoding policy restrictions on a user certificate. 125 The later may prove popular in the long term, given that today many 126 firms already encode privileges relating to time of day and 127 organizational function on employee badges. 129 4.2. Objects and attributes 131 The RADIUS schema defined in this document requires support for several 132 new classes: radiusProfileClass, radiusPolicyClass, 133 radiusDictionaryClass, and eapDictionaryClass. The radiusProfileClass is 134 used to store RADIUS attributes relevant to groups of users. The 135 radiusPolicyClass is used to describe conditions under which a given 136 profile may be applied. The radiusDictionaryClass is used to store the 137 RADIUS Dictionary. This provides extensibility and allows RADIUS profile 138 objects to be self describing. The eapDictionaryClass is used to store a 139 mapping EAP types to user friendly names. EAP is described in [7]. 141 The attributes in radiusProfileClass fall into two categories: 142 attributes present in the Access-Reply, and attributes representing 143 access constraints. An access constraint is a set of conditions that 144 must be satisfied in order for access to be granted. These are expressed 145 in the form of matching rules involving attributes present in the 146 Access-Reply, as well as other attributes such as the time of day. For 147 example, a matching rule involving the calledStationId and time of day 148 can be created in order to limit access to those calling a given phone 149 number during specified hours. 151 Attributes present in the Access-Reply are stored in the directory so 152 that the RADIUS server can retrieve them and include them in the Access- 153 Reply. Access constraints are stored in the directory so that the 154 RADIUS server can test the incoming Access-Request to determine whether 155 to proceed with authentication, or immediately send an Access-Reject. 156 Note that only static attributes present in Access-Reply need be stored 157 in the directory; attributes which are computed on the fly can be 158 recreated as needed. 160 The attributes in radiusPolicyClass represent conditions which must hold 161 for the profile indicated in radiusProfilePointer to be applied. As 162 with access constraints, these conditions may involve matching rules 163 applied to attributes in the Access-Request, as well as conditions 164 involving time of day, Nas-Port-Type, or group memberships. 166 For example, it may be desirable to give users different Session-Time or 167 Port-Limit attributes depending on the time of day, or group 168 memberships. This can be accomplished by creating policy expressions and 169 profiles for each time of day/group membership combination. Similarly, 170 it may be desirable to require that analog and ISDN callers do callback 171 or call from a particular callingStationId, while this may not make 172 sense for users connecting over a virtual private network (VPN). This 173 can be accomplished by creating a policy expression that returns 174 different profiles, depending on nasPortType. 176 4.2.1. User object attributes 178 This schema proposes addition of attributes to the user object. As noted 179 earlier, to enhance scalability, it is recommended that user object 180 attributes only be used in cases where profile overide is necessary, or 181 assignment of per-user attributes is required. Overide can in principle 182 be required for any attribute that may be included in the Access-Reply, 183 and so these attributes are among those that are added to the user 184 object. Examples of attributes that may be assigned on a per-user basis 185 include radiusFramedIPAddress, radiusCallbackNumber and 186 radiusFramedRoute. 188 Since many RADIUS parameters are expected to be identical for a group of 189 users, typically the user object will contain a small set of Radius 190 attributes. No user object attributes may be present if profiles are 191 being applied conditionally and no per-user values are required. 193 If it desired that a profile be unconditionally executed, then this can 194 be achieved either by creating a policy object with a 195 radiusProfilePointer attribute but no npConstraint attribute, or by 196 adding radiusPolicyPointer (a distinguished name pointing to a RADIUS 197 Profile Object) as a user object attribute. 199 4.2.2. Profiles 201 Profile attributes fall into two major categories. One category of 202 attributes are static attributes that may be returned in an Access- 203 Reply. These attributes use a prefix of 'radius' and are included 204 within the profile so that the RADIUS server may copy the values into 205 the Access-Reply. 207 Another category of attributes are those which represent conditions that 208 must be satisfied for an Access-Accept to be sent. These attributes use 209 a prefix of 'np', which stands for Network Policy. These attributes 210 include npIPPoolName, npSessionsAllowed, npEAPType, npConstraint, and 211 npAuthenticationType. npSessionsAllowed is used to limit the number of 212 simultaneous sessions; npAuthenticationType indicates the acceptable 213 authentication types (PAP, CHAP, MS-CHAP, EAP); npEAPType indicates the 214 EAP-Type to be used to authenticate the user if EAP is negotiated as an 215 authentication type; npIPPoolName indicates the name of the IP address 216 pool that should be used in assigning the user's IP address. 217 npConstraint is a string attribute used to express constraints based on 218 time of day, or attributes present in the Access-Request, such as NAS- 219 Port-Type or NAS-Identifier. 221 Within this document, we allow profiles to include pointers to other 222 profiles, so that profiles may form a linked list. This allows a 223 hierarchy of profiles to be provided. More specific attributes overide 224 more general ones. 226 4.2.3. Example 228 All BIGCO employees are required to use token card authentication, and 229 thus in the company profile the radiusAuthenticationType attribute is 230 set to only allow EAP, and the radiusEAPType attribute is set for 231 BIGCO's token card type. BIGCO also sets up a marketing profile 232 providing a radiusSessionTimeout value of 30 minutes, a radiusPortLimit 233 of one, and radiusFramedIpAddress set to indicate dynamic address 234 allocation. However, Fred requires a static IP address, and thus his 235 user object will contain a radiusFramedIpAddress attribute. 237 Since BIGCO profiles are unconditionally applied, a policy object with a 238 condition of (group == marketing) is used to assign a profile to 239 marketing personnel. Another policy object of lower priority is used 240 with no npConstraint attribute in order to assign a default profile. 242 4.3. Policy support 244 The schema described in this document provides for the conditional 245 application of a profile to a user via policy objects. Policy objects 246 make it possible to have profile A apply to a user in one set of 247 circumstances, and profile B apply in another set of circumstances. 248 They also enable binding of profiles to groups. 250 Each policy object corresponds to an IF/THEN statement; multiple policy 251 objects may be required to express complex policies. Attributes in the 252 policy object include npConstraint, a string attribute which expresses 253 the conditions under which a profile will be applied; npSequence, an 254 integer attribute which describes the order in which the policy object 255 will be evaluated; and radiusProfilePointer, a Distinguished Name 256 pointing to the RADIUS profile that will be applied if the conditions 257 hold. The matching rule stored in npConstraint is an expression which 258 may reference other attribute values and include pattern matching and 259 other operations, such as equality tests. Policy objects without an 260 npConstraint attribute can be used to indicate unconditional execution 261 of a profile. 263 Although a simple Policy Object is presented in this schema, more 264 complex versions are possible. For example, a wider variety of operators 265 and pattern matches might be supported within npConstraint. 267 4.3.1. Example 269 Let us assume that BIGCO wishes to offer dialin access to their domestic 270 sales force, as well as VPN access to contractors and to individuals 271 from the finance group travelling overseas. In order to consistently 272 manage and account for the use of their NAS devices and Layer 2 tunnel 273 servers (PPTP/L2F/L2TP), BIGCO has chosen to adopt the RADIUS protocol. 274 However, given the large number of employees and contractors that need 275 to be managed, BIGCO desires a RADIUS solution integrated with their 276 existing LDAP-based directory service and group structure. This will 277 allow the network administrator to edit the user's RADIUS attributes 278 with the same user-interface as they use to edit other user attributes, 279 profiles, and policies, and will eliminate the need to maintain multiple 280 stores of user information. 282 As part of this service offering, BIGCO may wish to implement a number 283 of policies. For example, in order to make sure that high speed dialin 284 access is available to the sales force when they need it, BIGCO may wish 285 to restrict use of the ISDN ports to sales personnel only during the 286 hours of 9 AM - 5 PM, and permit the use of multilink. Since contractors 287 are only to be given access to selected subnets, BIGCO may wish to apply 288 a filter to their traffic. Since individuals in the finance group often 289 access highly confidential information over the VPN, BIGCO may wish to 290 require that these users authenticate via a smartcard, and use only 291 128-bit encryption so as to provide for extended security. For security 292 reasons, BIGCO may wish to restrict contractors and finance users to a 293 single login at a time. 295 Note that applying a rigid rule to prevent access to ISDN by non-sales 296 personnel during business hours may not be the most economically 297 efficient way of solving the problem. Non-sales personnel may have 298 legitimate business reasons for wanting ISDN access, as well as the 299 resources to pay for it. Creating rules limiting their access will 300 therefore only serve to deny legitimate needs, while resulting in 301 additional support calls by users confused as to why they cannot access 302 the network. In cases such as this, establishment of an accounting 303 system and chargeback mechanism is more likely to allow the organization 304 to find the right balance between networking expenditures and service 305 levels. 307 In certain cases, BIGCO may also wish to implement policies that depend 308 on the type of port that the user is connecting to. For example, if the 309 user is connecting via dialup, then it may be appropriate to include 310 tunnel attributes within the Access-Accept, so as to set up a tunnel for 311 the user. However, if the user is already connected via a tunnel, this 312 would not be necessary. Similarly, if BIGCO only has a limited number of 313 ISDN ports available, it may be desirable to set a shorter Session- 314 Timeout or Idle-Timeout on these ports, or to set Port-Limit to one so 315 as to not allow multi-link. The schema defined in this document permits 316 enforcement of these and many other policies. 318 4.4. Caching 320 The schema presented in this document will benefit from caching, since 321 it is expected that profiles and policies will apply to large numbers of 322 users. The first time the RADIUS server encounters a pointer to a given 323 profile or policy, the profile or policy will be retrieved from the 324 directory and cached. Subsequently, the profile or policy may be 325 retrieved from the cache, speeding the retrieval process. As a result, 326 it is to be expected that caching should result in a substantial 327 performance gain. 329 5. Consistency and transaction issues 331 While LDAP v3, described in [5], permits a list of modifications to a 332 single object to be made as a single atomic operation, it does not 333 support transacted modifications to multiple objects. In SNMP this 334 functionality is supported through a "conceptual two-phase commit" 335 applied to SET operations, as well as constructs such as the TextAndIncr 336 textual convention, defined in [10]. In addition, within a globally 337 replicated directory system, it is likely that directory replicas will 338 be partially out of synchronization at any given time. This means that 339 in any given replica it is possible for related objects to be in an 340 inconsistent state. As a result, in order to ensure correctness, it is 341 necessary to implement mechanisms for detecting and handling directory 342 inconsistencies. 344 This schema includes related objects which need to be consistently 345 maintained. For example, policy objects contain an 'IF' (conditions) as 346 well as a 'THEN' (a pointer to a profile object). In addition, it is 347 possible for this schema to store data which relates to two ends of a 348 link. For example, the Framed-Route and Framed-Routing attributes may be 349 used to set up a routed dialup or VPN connection. 351 In either of these two examples, if mechanisms are not provided to 352 guarantee consistency of related objects, then inconsistent policies can 353 be propagated. This is particularly dangerous with respect to link 354 policies, since propagation of inconsistent policies could result in the 355 links going down. This in turn could stop directory replication from 356 proceeding, preventing resolution of the inconsistency. The network 357 would thus remain in a deadlocked state requiring manual intervention. 359 Directory-induced network lockup can be prevented through careful 360 implementation. For example, policy objects and profiles may be 361 maintained within the same containment hierarchy, edited within a 362 temporary work area, and then propagated to the final location with a 363 "transacted move." 365 Consistency between related objects may be maintained through use of a 366 version attribute. When retrieving a set of related objects, the version 367 number can be checked to make sure that it is consistent within the set. 368 If an entire set of objects cannot be obtained with the latest version 369 number, then it may be necessary to revert to use of a previous 370 consistent set of objects at an earlier version. Note that support for 371 reversion implies that storage of related objects is archival; that is, 372 addition of a new set of objects does not overwrite the previous 373 version. 375 Since support for object versioning is a generally useful capability, it 376 makes the most sense to support this in a general way rather than doing 377 it in a schema-specific manner. As a result, we have chosen not to add a 378 version number attribute to the objects described in this document. A 379 general mechanism for supporting versioning will be the subject of a 380 future document. 382 5.1. Extensibility 384 Today vendors distinguish their RADIUS servers by a variety of means, 385 including the range of supported attributes (standard and vendor- 386 specific), and the breadth of policies that may be represented. As a 387 result, while it is desirable to provide a common base set of classes 388 and attributes which all RADIUS schemas will share, RADIUS server 389 capabilities differ substantially from implementation to implementation, 390 and a successful RADIUS schema definition must support this 391 differentiation. 393 The schema described in this document provides support for most of the 394 attributes defined in [1]-[4], as well as including support for the 395 RADIUS Dictionary and vendor-specific attributes, as well as conditional 396 application of profiles. Within this framework, vendor differentiation 397 can be achieved via two methods: adding attributes to the base RADIUS 398 profile and policy classes, or creating subclasses inheriting from the 399 base classes. Adding attributes to the base class is recommended in 400 cases where the new attributes to be added do not conflict with those 401 described in this document or in [1]-[4]. 403 Where conflicts do not arise, new attributes, including vendor-specific 404 attributes, may be added to the RADIUS dictionary, which allows RADIUS 405 Profile objects to be self-describing. The goal is to allow attributes 406 to be added without having to require an update to the RADIUS server 407 code. Note however that a conventional RADIUS dictionary is only 408 designed to describe attributes that are sent on the wire, while the 409 RADIUS Dictionary object defined in this schema may also be used to 410 define additional non-wire attributes (such as 411 radiusAuthenticationType). This provides an additional element of 412 flexibility, allowing new attributes to be defined and used within 413 existing policy objects, without code changes. 415 Creating a sub-class is desirable in cases where conflicts are possible. 416 Such conflicts can arise for example, when vendors have defined 417 attributes which conflict with the standard RADIUS attribute space 418 described in [1]-[4]. In this case, the radiusVendorId attribute should 419 included and set to the SMI Vendor Code, indicating that the profile is 420 specific to a given vendor, and contains potentially conflicting 421 elements. Since a RADIUS server searching for a profile with 422 objectclass=radiusProfileClass will encounter both base class profiles 423 and subclasses, the radiusVendorId attribute is critical in allowing an 424 implementation to differentiate the profiles it can understand from 425 those that it cannot. Typically an implementation will only wish to work 426 with profiles whose radiusVendorId is either not present, zero (IETF 427 RADIUS) or set to their own SMI Vendor Code. As with addition of 428 attributes to the base class, when attributes are added to a subclass, 429 the RADIUS Dictionary class should modified to allow the subclass to be 430 self-describing. 432 Since it is conceivable that RADIUS servers from two vendors may be 433 deployed simultaneously, both desiring to store objects in the same 434 LDAP-based directory service, and each implementing their own profile 435 subclass, a method must be provided to allow a user to have more than 436 one set of RADIUS profile and policy objects. This can be achieved by 437 allowing the radiusProfilePointer to point to a container object rather 438 than pointing to an object itself. The RADIUS server would then search 439 the container for a RADIUS profile or policy with an appropriate 440 radiusVendorId. 442 In order to prevent name conflicts, it is recommended that vendors 443 adding their own attributes prepend a suffix to all attribute names, so 444 as to avoid name conflicts. Rather than redefining existing attributes, 445 vendor should create their own attributes using suffixes in order to 446 avoid conflict. 448 To illustrate how extensibility features may be used, the additional 449 attributes supported by a hypothetical BIGCO Profile Class are included. 451 6. User object additions 453 The RADIUS schema proposes addition of the following attributes to the 454 user object: 456 MAY ( radiusServiceType $ radiusFramedProtocol $ 457 radiusFramedIPAddress $ radiusFramedIPNetmask $ 458 radiusFramedRoute $ radiusFramedRouting $ 459 radiusFilterId $ radiusFramedMTU $ 460 radiusFramedCompression $ radiusLoginIPHost $ 461 radiusLoginService $ radiusLoginTCPPort $ 462 radiusCallbackNumber $ radiusCallbackId $ 463 radiusFramedRoute $ radiusFramedIPXNetwork $ 464 radiusClass $ radiusVSA $ radiusSessionTimeout $ 465 radiusIdleTimeout $ radiusTerminationAction $ 466 radiusCalledStationId $ radiusCallingStationId $ 467 radiusLoginLATService $ radiusLoginLATNode $ 468 radiusLoginLATGroup $ radiusFramedAppleTalkLink $ 469 radiusFramedAppleTalkNetwork $ 470 radiusFramedAppleTalkZone $ radiusPortLimit $ 471 radiusLoginLATPort $ radiusTunnelType $ 472 radiusTunnelMediumType $ radiusTunnelServerEndpoint $ 473 radiusTunnelPrivateGroupId $ radiusTunnelAssignmentId $ 474 radiusTunnelClientEndpoint $ radiusTunnelPreference $ 475 radiusTunnelPassword $ radiusArapFeatures $ 476 radiusArapZoneAccess $ radiusArapSecurity $ 477 radiusPasswordRetry $ radiusPrompt $ npSessionsAllowed $ 478 npAuthenticationType $ npEAPType $ npConstraint $ 479 npIPPoolName $ radiusProfilePointer $ radiusVendorId 480 ) 482 7. Object definitions 484 The RADIUS schema includes definition of the following objects: 486 RADIUS Profile Class 487 RADIUS Policy Class 488 RADIUS Dictionary Class 489 EAP Dictionary Class 491 7.1. RADIUS Profile Class 493 ( radiusProfileClass 1 494 NAME 'radiusProfile' 495 SUP profile 496 PARENT (country $ organization $ organizationalUnit $ 497 locality $ container) 498 STRUCTURAL 499 MUST ( 500 cn 501 ) 502 MAY ( radiusServiceType $ radiusFramedProtocol $ 503 radiusFramedIPAddress $ radiusFramedIPNetmask $ 504 radiusFramedRoute $ radiusFramedRouting $ 505 radiusFilterId $ radiusFramedMTU $ 506 radiusFramedCompression $ radiusLoginIPHost $ 507 radiusLoginService $ radiusLoginTCPPort $ 508 radiusCallbackNumber $ radiusCallbackId $ 509 radiusFramedRoute $ radiusFramedIPXNetwork $ 510 radiusClass $ radiusVSA $ radiusSessionTimeout $ 511 radiusIdleTimeout $ radiusTerminationAction $ 512 radiusCalledStationId $ radiusCallingStationId $ 513 radiusLoginLATService $ radiusLoginLATNode $ 514 radiusLoginLATGroup $ radiusFramedAppleTalkLink $ 515 radiusFramedAppleTalkNetwork $ 516 radiusFramedAppleTalkZone $ radiusPortLimit $ 517 radiusLoginLATPort $ radiusTunnelType $ 518 radiusTunnelMediumType $ 519 radiusTunnelServerEndpoint $ 520 radiusTunnelPrivateGroupId $ 521 radiusTunnelAssignmentId $ 522 radiusTunnelClientEndpoint $ 523 radiusTunnelPreference $ 524 radiusTunnelPassword $ radiusArapFeatures $ 525 radiusArapZoneAccess $ radiusArapSecurity $ 526 radiusPasswordRetry $ radiusPrompt $ 527 npSessionsAllowed $ npAuthenticationType $ 528 npEAPType $ npConstraint $ npIPPoolName $ 529 radiusProfilePointer $ radiusVendorId $ 530 radiusDictionaryPointer 531 ) 532 ) 534 7.2. RADIUS Policy Class 536 ( radiusPolicyClass 1 537 NAME 'radiusPolicy' 538 SUP policy 539 PARENT (country $ organization $ 540 organizationalUnit $ 541 locality $ container) 542 STRUCTURAL 543 MUST ( 544 cn $ radiusProfilePointer 545 ) 546 MAY ( npConstraint $ npSequence 547 ) 548 ) 550 7.3. RADIUS Dictionary Class 552 ( radiusDictionaryClass 1 553 NAME 'radiusDictionaryClass' 554 SUP top 555 PARENT (country $ organization $ 556 organizationalUnit $ 557 locality $ container) 558 STRUCTURAL 559 MUST ( 560 cn $ radiusDictionaryEntry 561 ) 562 ) 564 7.4. EAP Dictionary Class 566 ( eapDictionaryClass 1 567 NAME 'eapDictionaryClass' 568 SUP top 569 PARENT (country $ organization $ 570 organizationalUnit $ 571 locality $ container) 572 STRUCTURAL 573 MUST ( 574 cn $ eapDictionaryEntry 575 ) 576 ) 578 7.5. BIGCO Profile Class 580 As described earlier, the base classes may be extended by attribute 581 addition, subclassing, or both. An example of the subclassing approach 582 is illustrated below. Here the bigcoProfileClass is created as a 583 subclass of the radiusProfileClass and adds several attributes, each of 584 which uses bigco as a suffix to avoid name collisions. 586 ( bigcoProfileClass 1 587 NAME 'bigcoProfile' 588 SUP radiusProfileClass 589 PARENT (country $ organization $ organizationalUnit $ 590 locality $ container) 591 STRUCTURAL 592 MUST ( 593 ) 594 MAY ( bigcoBapRequired $ bigcoBapLinednLimit $ 595 bigcoBapLinednTime $ bigcoDynDirServer 596 ) 597 ) 599 8. Attribute definitions 601 8.1. New Attribute Types Used in the user object and RADIUS Profile 602 Class 604 ( radius radiusProfileClass 6 605 NAME 'radiusServiceType' 606 DESC 'The service to be provided to the user. 607 Values include: Login(1), Framed(2), 608 Callback Login(3), Callback Framed(4), 609 Outbound(5), Administrative(6), NAS Prompt(7), 610 Authenticate Only(8), Callback NAS Prompt(9)' 611 EQUALITY integerMatch 612 SYNTAX 'INTEGER' 613 SINGLE-VALUE 614 ) 616 ( radius radiusProfileClass 7 617 NAME 'radiusFramedProtocol' 618 DESC 'For Framed service, the protocol to be 619 provided to the user. Values include 620 PPP(1), SLIP(2), ARAP(3), Gandalf(4), 621 Xylogics(5)' 622 EQUALITY integerMatch 623 SYNTAX 'INTEGER' 624 SINGLE-VALUE 625 ) 627 ( radius radiusProfileClass 8 628 NAME 'radiusFramedIPAddress' 629 DESC 'IP address to be assigned to the user 630 in dotted decimal notation' 631 EQUALITY integerMatch 632 SYNTAX 'INTEGER' 633 SINGLE-VALUE 634 ) 636 ( radius radiusProfileClass 9 637 NAME 'radiusFramedIPNetmask' 638 DESC 'Netmask to apply to the user 639 in dotted decimal notation' 640 EQUALITY integerMatch 641 SYNTAX 'INTEGER' 642 SINGLE-VALUE 643 ) 645 ( radius radiusProfileClass 10 646 NAME 'radiusFramedRouting' 647 DESC 'Routing method for the user. 648 Values include None(1), Send(2), 649 Listen(3), Send & Listen(4)' 650 EQUALITY integerMatch 651 SYNTAX 'INTEGER' 652 SINGLE-VALUE 653 ) 655 ( radius radiusProfileClass 11 656 NAME 'radiusFilterId' 657 DESC 'String representing the filter list 658 for the user' 659 EQUALITY caseIgnoreIA5Match 660 SYNTAX 'IA5String{128}' 661 ) 663 ( radius radiusProfileClass 12 664 NAME 'radiusFramedMTU' 665 DESC 'Maximum Transmission Unit for the user' 666 EQUALITY integerMatch 667 SYNTAX 'INTEGER' 668 SINGLE-VALUE 669 ) 671 ( radius radiusProfileClass 13 672 NAME 'radiusFramedCompression' 673 DESC 'Compression protocol to be used on 674 the link. Values include: None(1), 675 VJ compression(2), 676 IPX header compression(3)' 677 EQUALITY integerMatch 678 SYNTAX 'INTEGER' 679 ) 681 ( radius radiusProfileClass 14 682 NAME 'radiusLoginIPHost' 683 DESC 'System with which to connect the user 684 in dotted decimal notation' 685 EQUALITY integerMatch 686 SYNTAX 'INTEGER' 687 ) 689 ( radius radiusProfileClass 15 690 NAME 'radiusLoginService' 691 DESC 'Service to be used to connect the user to 692 the login host. Values include Telnet(1), Rlogin(2), 693 TCP Clear(3), PortMaster(4), and LAT(5)' 694 EQUALITY integerMatch 695 SYNTAX 'INTEGER' 696 SINGLE-VALUE 697 ) 699 ( radius radiusProfileClass 16 700 NAME 'radiusLoginTCPPort' 701 DESC 'The TCP port with which the useris 702 to be connected' 703 EQUALITY integerMatch 704 SYNTAX 'INTEGER' 705 SINGLE-VALUE 706 ) 708 ( radius radiusProfileClass 19 709 NAME 'radiusCallbackNumber' 710 DESC 'Number to be called' 711 EQUALITY caseIgnoreIA5Match 712 SYNTAX 'IA5String{128}' 713 SINGLE-VALUE 714 ) 716 ( radius radiusProfileClass 20 717 NAME 'radiusCallbackId' 718 DESC 'Name of place to be called' 719 EQUALITY caseIgnoreIA5Match 720 SYNTAX 'IA5String{128}' 721 SINGLE-VALUE 722 ) 724 ( radius radiusProfileClass 22 725 NAME 'radiusFramedRoute' 726 DESC 'Routes to be plumbed for the user' 727 EQUALITY caseIgnoreIA5Match 728 SYNTAX 'IA5String{128}' 729 ) 731 ( radius radiusProfileClass 23 732 NAME 'radiusFramedIPXNetwork' 733 DESC 'IPX Network number to be configured 734 for the user' 735 EQUALITY integerMatch 736 SYNTAX 'INTEGER' 737 SINGLE-VALUE 738 ) 740 ( radius radiusProfileClass 24 741 NAME 'radiusClass' 742 DESC 'Class attribute for the user' 743 SYNTAX 'OCTETSTRING' 744 ) 746 ( radius radiusProfileClass 25 747 NAME 'radiusVSA' 748 DESC 'Vendor Specific Attribute 749 for the user' 750 SYNTAX 'OCTETSTRING' 751 ) 753 ( radius radiusProfileClass 27 754 NAME 'radiusSessionTimeout' 755 DESC 'Per-session time limit in seconds. 756 After this expires, the action specified 757 in Termination-Action is taken' 758 EQUALITY integerMatch 759 SYNTAX 'INTEGER' 760 SINGLE-VALUE 761 ) 763 ( radius radiusProfileClass 28 764 NAME 'radiusIdleTimeout' 765 DESC 'The maximum number of consecutive 766 seconds of idle connection allowed 767 before session termination' 768 EQUALITY integerMatch 769 SYNTAX 'INTEGER' 770 SINGLE-VALUE 771 ) 773 ( radius radiusProfileClass 29 774 NAME 'radiusTerminationAction' 775 DESC 'Action taken when specified service is 776 completed. Values include Default(1) 777 or RADIUS-Request(2)' 778 EQUALITY integerMatch 779 SYNTAX 'INTEGER' 780 SINGLE-VALUE 781 ) 783 ( radius radiusProfileClass 34 784 NAME 'radiusLoginLATService' 785 DESC 'Identity of the LAT service to use' 786 EQUALITY caseIgnoreIA5Match 787 SYNTAX 'IA5String{128}' 788 SINGLE-VALUE 789 ) 791 ( radius radiusProfileClass 35 792 NAME 'radiusLoginLATNode' 793 DESC 'The node with which the user is to be 794 automatically connected by LAT' 795 EQUALITY caseIgnoreIA5Match 796 SYNTAX 'IA5String{128}' 797 SINGLE-VALUE 798 ) 800 ( radius radiusProfileClass 36 801 NAME 'radiusLoginLATGroup' 802 DESC 'The LAT group codes which this user 803 is authorized to use' 804 EQUALITY caseIgnoreIA5Match 805 SYNTAX 'IA5String{128}' 806 SINGLE-VALUE 807 ) 809 ( radius radiusProfileClass 37 810 NAME 'radiusFramedAppleTalkLink' 811 DESC 'The AppleTalk network number which 812 should be used for the user' 813 EQUALITY caseIgnoreIA5Match 814 SYNTAX 'INTEGER' 815 SINGLE-VALUE 816 ) 818 ( radius radiusProfileClass 38 819 NAME 'radiusFramedAppleTalkNetwork' 820 DESC 'The AppleTalk network number which 821 the NAS should probe to allocate an 822 AppleTalk node for the user' 823 EQUALITY caseIgnoreIA5Match 824 SYNTAX 'INTEGER' 825 ) 827 ( radius radiusProfileClass 39 828 NAME 'radiusFramedAppleTalkZone' 829 DESC 'The name of the Default AppleTalk Zone' 830 EQUALITY caseIgnoreIA5Match 831 SYNTAX 'IA5String{128}' 832 SINGLE-VALUE 833 ) 835 ( radius radiusProfileClass 62 836 NAME 'radiusPortLimit' 837 DESC 'Maximum number of ports to be provided' 838 EQUALITY integerMatch 839 SYNTAX 'INTEGER' 840 SINGLE-VALUE 841 ) 843 ( radius radiusProfileClass 39 844 NAME 'radiusLoginLATPort' 845 DESC 'The Port with which the user is to 846 connected by LAT' 847 EQUALITY caseIgnoreIA5Match 848 SYNTAX 'IA5String{128}' 849 SINGLE-VALUE 850 ) 852 ( radius radiusProfileClass 64 853 NAME 'radiusTunnelType' 854 DESC 'String representing the type of tunnel to 855 be set up, of the form Tag: Value. Values 856 include PPTP(1), L2F(2), L2TP(3), ATMP(4), 857 VTP(5), AH(6), IP-IP(7).' 858 SYNTAX 'OCTETSTRING' 859 ) 861 ( radius radiusProfileClass 65 862 NAME 'radiusTunnelMediumType' 863 DESC 'String representing the medium for the tunnel to 864 run over, of the form Tag: Value. Values 865 include IP(1), X.25(2), ATM(3), Frame Relay(4).' 866 SYNTAX 'OCTETSTRING' 867 ) 869 ( radius radiusProfileClass 66 870 NAME 'radiusTunnelClientEndpoint' 871 DESC 'String representing the Tunnel Client Endpoint 872 for the tunnel, of the form Tag: Value.' 873 SYNTAX 'OCTETSTRING' 874 ) 876 ( radius radiusProfileClass 67 877 NAME 'radiusTunnelServerEndpoint' 878 DESC 'String representing the address of the tunnel 879 server, of the form Tag: Value. The format 880 of the value field depends on the 881 tunnelMediumType attribute' 882 SYNTAX 'OCTETSTRING' 883 ) 885 ( radius radiusProfileClass 71 886 NAME 'radiusArapFeatures' 887 DESC 'This is a compound string containing info that 888 the NAS should send to the user in the ARAP 889 feature flags packet' 890 EQUALITY caseIgnoreIA5Match 891 SYNTAX 'IA5String{128}' 892 SINGLE-VALUE 893 ) 895 ( radius radiusProfileClass 72 896 NAME 'radiusArapZoneAccess' 897 DESC 'This field controls access to ARAP zones. 898 Values include 899 Only allow access to default zone(1), 900 Use zone filter inclusively(2), 901 Use zone filter exclusively (4)' 902 EQUALITY integerMatch 903 SYNTAX 'INTEGER' 904 SINGLE-VALUE 906 ) 908 ( radius radiusProfileClass 73 909 NAME 'radiusArapSecurity' 910 DESC 'This field contains an integer 911 specifying the security module signature, 912 which is a Macintosh OSType' 913 EQUALITY integerMatch 914 SYNTAX 'INTEGER' 915 SINGLE-VALUE 916 ) 918 ( radius radiusProfileClass 75 919 NAME 'radiusPasswordRetry' 920 DESC 'This is an integer specifying the number 921 of password retry attempts to permit the user' 922 EQUALITY integerMatch 923 SYNTAX 'INTEGER 924 SINGLE-VALUE 925 ) 927 ( radius radiusProfileClass 76 928 NAME 'radiusPrompt' 929 DESC 'This attribute is used only in RADIUS 930 Access-Challenge packets and indicates 931 if the NAS should echo the user's response 932 as entered. Values include No Echo (0), or Echo(1).' 933 EQUALITY integerMatch 934 SYNTAX 'INTEGER' 935 SINGLE-VALUE 936 ) 938 ( radius radiusProfileClass 81 939 NAME 'radiusTunnelPrivateGroupId' 940 DESC 'String representing the Private Group Id for the 941 tunnel, of the form Tag: Value.' 942 SYNTAX 'OCTETSTRING' 943 ) 945 ( radius radiusProfileClass 82 946 NAME 'radiusTunnelAssignmentId' 947 DESC 'String representing the Tunnel Assignment Id 948 for the tunnel, of the form Tag: Value.' 949 SYNTAX 'OCTETSTRING' 950 ) 952 ( radius radiusProfileClass 83 953 NAME 'radiusTunnelPreference' 954 DESC 'String representing the tunnel preference for the 955 tunnel, of the form Tag: Value.' 956 SYNTAX 'OCTETSTRING' 957 ) 959 ( radius radiusProfileClass 257 960 NAME 'npEAPType' 961 DESC 'Allowable EAP types, in order of preference. 962 If this attribute has a value, EAP must be 963 included in the allowable authentication types.' 964 EQUALITY caseIgnoreIA5Match 965 SYNTAX 'IA5String{128}' 966 SINGLE-VALUE 967 ) 969 ( radius radiusProfileClass 258 970 NAME 'npConstraint' 971 DESC 'A string expressing conditions which must hold 972 in order for an Access-Accept to be sent. The 973 string is of the format MATCH ( = 974 OR ) 975 TIMEOFDAY. Brackets () can be used to group. 976 When multiple msNPConstraints are present, all 977 of them must be satisfied in order for a profile 978 to be executed.' 979 EQUALITY caseIgnoreIA5Match 980 SYNTAX 'IA5String' 981 ) 983 ( radius radiusProfileClass 259 984 NAME 'npIPPoolName' 985 DESC 'The name of the IP Address Pool out of which 986 the user's IP address should be allocated.' 987 EQUALITY caseIgnoreIA5Match 988 SYNTAX 'IA5String' 989 ) 991 ( radius radiusProfileClass 260 992 NAME 'npSessionsAllowed' 993 DESC 'This attribute indicates the number of 994 simultaneous sessions allowed for this user.' 995 EQUALITY integerMatch 996 SYNTAX 'INTEGER' 997 SINGLE-VALUE 998 ) 1000 ( radius radiusProfileClass 261 1001 NAME 'npAuthenticationType' 1002 DESC 'Allowable authentication types (EAP, CHAP, PAP, 1003 MS-CHAP, etc.) in order of preference. 1004 If an attribute isn't included, it isn't allowed.' 1005 EQUALITY caseIgnoreIA5Match 1006 SYNTAX 'IA5String{128}' 1007 SINGLE-VALUE 1008 ) 1010 ( radius radiusProfileClass 262 1011 NAME 'radiusProfilePointer' 1012 DESC 'Distinguished Name of a RADIUS Profile Object.' 1013 EQUALITY distinguishedNameMatch 1014 SYNTAX 'DN' 1015 SINGLE-VALUE 1016 ) 1018 ( radius radiusProfileClass 263 1019 NAME 'radiusVendorId' 1020 DESC 'SMI Vendor Id. A non-zero value denotes a 1021 profile non-compliant with RFC 2138 and 2139.' 1022 EQUALITY integerMatch 1023 SYNTAX 'INTEGER' 1024 SINGLE-VALUE 1025 ) 1027 ( radius radiusProfileClass 264 1028 NAME 'radiusDictionaryPointer' 1029 DESC 'A Distinguished Name pointing to 1030 the RADIUS dictionary for this profile. If 1031 not present the default dictionary is used.' 1032 EQUALITY distinguishedNameMatch 1033 SYNTAX 'DN' 1034 SINGLE-VALUE 1035 ) 1037 8.2. New Attribute Types Used in the RADIUS Policy Class 1039 ( radius radiusPolicyClass 2 1040 NAME 'npSequence' 1041 DESC 'An integer indicating the order in which 1042 policy objects are to be evaluated.' 1043 EQUALITY integerMatch 1044 SYNTAX 'INTEGER' 1045 SINGLE-VALUE 1046 ) 1048 8.3. New Attribute Types Used in the RADIUS Dictionary Class 1050 ( radius radiusDictionaryClass 1 1051 NAME 'dictionaryEntry' 1052 DESC 'A dictionary entry in the RADIUS dictionary, 1053 of the form 1054 Attribute-Number:[Vendor-Type:]ldapDisplayName:Type. 1055 Vendor-Type may only be present with 1056 Attribute-Number=26 (Vendor Specific).' 1057 EQUALITY caseIgnoreIA5Match 1058 SYNTAX 'IA5String{128}' 1059 ) 1061 8.4. New Attribute Types Used in the BIGCO Profile Class 1063 ( bigco bigcoProfileClass 263 1064 NAME 'bigcoBapRequired' 1065 DESC 'This attribute indicates whether Bandwidth 1066 Allocation Protocol (BAP) is required for 1067 this user. Values include 1068 BAP Not Required (0) and BAP Required (1).' 1069 EQUALITY integerMatch 1070 SYNTAX 'INTEGER' 1071 SINGLE-VALUE 1073 ( bigco bigcoProfileClass 264 1074 NAME 'bigcoBapLinednLimit' 1075 DESC 'Percent of capacity utilized at which to 1076 bring a line down for this user. ' 1077 EQUALITY integerMatch 1078 SYNTAX 'INTEGER' 1079 SINGLE-VALUE 1080 ) 1082 ( bigco bigcoProfileClass 265 1083 NAME 'bigcoBapLinednTime' 1084 DESC 'Time in seconds for the capacity 1085 utilization calculation.' 1086 EQUALITY integerMatch 1087 SYNTAX 'INTEGER' 1088 SINGLE-VALUE 1089 ) 1091 ( bigco bigcoProfileClass 266 1092 NAME 'bigcoDynDirServer' 1093 DESC 'Fully qualified domain name or IP address of 1094 the dynamic directory server for this user.' 1096 EQUALITY caseIgnoreIA5Match 1097 SYNTAX 'IA5String{128}' 1098 SINGLE-VALUE 1099 ) 1101 9. Security issues 1103 Integration of a RADIUS server with an LDAP-based directory service can 1104 result in several security issues, including: 1106 Rogue LDAP-servers 1107 Inappropriate use 1109 These threats are discussed in turn. 1111 9.1. Rogue LDAP servers 1113 Were a rogue LDAP server to respond to queries from the RADIUS server 1114 and have its responses accepted, it is possible that users could gain 1115 inappropriate access to the network. In order to protect against this, 1116 the conversation between the RADIUS server and the LDAP-based directory 1117 service SHOULD be mutually authenticated via TLS [8] or IPSEC [9]. 1119 9.2. Inappropriate use 1121 This schema is intended for use by a RADIUS server integrating with an 1122 LDAP-enabled directory. This schema was not designed for use by devices 1123 looking to directly access the directory. 1125 LDAP-enabling a RADIUS server requires that the RADIUS server be given 1126 permissions to access a user's RADIUS objects and attributes. As a 1127 result, the administrator of the RADIUS server should exercise care to 1128 ensure that the RADIUS account password is not compromised. If at all 1129 possible, the RADIUS server should be physically secured. 1131 In contrast, LDAP-enabling of devices requires that devices be given 1132 these access-rights. This can be achieved by making the devices members 1133 of a group, and giving the group access rights to this portion of the 1134 schema. However, while RADIUS servers can often be physically secured, 1135 widely deployed devices typically cannot be. 1137 It should also be noted that direct use of LDAP across a WAN typically 1138 requires that LDAP pass through a firewall. This is problematic since 1139 LDAP-based directories can be used to store a wide variety of data, much 1140 of it sensitive. Thus without implementing an LDAP proxy to limit access 1141 only to appropriate portions of the schema, it is difficult to enforce 1142 security. Since humans are notoriously lax in administration of access 1143 rights, an attacker obtaining a device password would typically also 1144 obtain access not only to RADIUS attributes for every user, but to other 1145 information as well. 1147 LDAP-enabling of devices has other potential downsides as well. It 1148 increases the size of the device binaries, and may in some cases 1149 introduce dependencies in the device boot sequence that can be 1150 problematic. In addition, permitting direct access to the directory 1151 makes it very difficult to upgrade the schema since downlevel clients 1152 will still need to be able to access the old schema after the upgrade. 1153 Thus both the old and new schema will need to be maintained in parallel 1154 during the transition period. In contrast, in the case of an LDAP- 1155 enabled RADIUS server, only the RADIUS server will be affected by the 1156 schema upgrade. The wire protocol spoken between the device and RADIUS 1157 server will be unaffected. Thus a schema upgrade may be accomplished 1158 without the need for a transition period. 1160 10. Acknowledgments 1162 Thanks to Steven Judd, Ashwin Palekar, David Eitelbach, Narendra Gidwani 1163 and Donald Rule of Microsoft for useful discussions of this problem 1164 space. 1166 11. References 1168 [1] Rigney, C., Rubens, A., Simpson W., and S. Willens, "Remote 1169 Authentication Dial In User Service (RADIUS)", RFC 2138, April 1170 1997. 1172 [2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1174 [3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 1175 Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", 1176 Internet draft (work in progress), draft-ietf-radius-tunnel- 1177 auth-09.txt, August 1999. 1179 [4] Rigney, C., Willats, W., "RADIUS Extensions", Internet draft (work 1180 in progress), draft-ietf-radius-ext-04.txt, May 1999. 1182 [5] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access 1183 Protocol (v3)", RFC 2251, December 1997. 1185 [6] Wahl, M., Coulbeck, A., Howes, T., Kille S., "Lightweight Directory 1186 Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, 1187 December 1997. 1189 [7] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 1190 (EAP)", RFC 2284, March 1998. 1192 [8] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, 1193 November 1998. 1194 .IP [9] Atkinson, R., Kent, S., "Security Architecture for the 1195 Internet Protocol", RFC 2401, November 1998. 1197 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1198 Conventions for Version 2 of the Simple Network Management Protocol 1199 (SNMPv2)", RFC 1903, January 1996. 1201 12. Authors' Addresses 1203 Bernard Aboba 1204 Microsoft Corporation 1205 One Microsoft Way 1206 Redmond, WA 98052 1208 Phone: 425-936-6605 1209 EMail: bernarda@microsoft.com 1211 13. Full Copyright Statement 1213 Copyright (C) The Internet Society (1999). All Rights Reserved. 1214 This document and translations of it may be copied and furnished to 1215 others, and derivative works that comment on or otherwise explain it or 1216 assist in its implmentation may be prepared, copied, published and 1217 distributed, in whole or in part, without restriction of any kind, 1218 provided that the above copyright notice and this paragraph are included 1219 on all such copies and derivative works. However, this document itself 1220 may not be modified in any way, such as by removing the copyright notice 1221 or references to the Internet Society or other Internet organizations, 1222 except s needed for the purpose of developing Internet standards in 1223 which case the procedures for copyrights defined in the Internet 1224 Standards process must be followed, or as required to translate it into 1225 languages other than English. The limited permissions granted above are 1226 perpetual and will not be revoked by the Internet Society or its 1227 successors or assigns. This document and the information contained 1228 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1229 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1230 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1231 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1232 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1234 14. Expiration Date 1236 This memo is filed as , and expires March 1237 1, 2000.