idnits 2.17.1 draft-aboba-802-context-02.txt: 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: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 329 has weird spacing: '...enables the c...' == Line 422 has weird spacing: '... is not neces...' == Line 686 has weird spacing: '...imed to perta...' == Line 730 has weird spacing: '...>, and expir...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (6 April 2002) is 8049 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Condgon' is mentioned on line 224, but not defined -- Looks like a reference, but probably isn't: '1' on line 404 -- Looks like a reference, but probably isn't: '2' on line 407 -- Looks like a reference, but probably isn't: '3' on line 410 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: A later version (-29) exists of draft-congdon-radius-8021x-17 Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bernard Aboba 3 INTERNET-DRAFT Tim Moore 4 Category: Informational Microsoft 5 6 6 April 2002 8 A Model for Context Transfer in IEEE 802 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working 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 material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2002). All Rights Reserved. 32 Abstract 34 The IEEE 802 Inter-Access Point Protocol (IAPP), under development 35 within the IEEE 802.11 TgF working group, supports the transfer of 36 context between access points implementing IEEE 802 technology. This 37 document describes how IAPP can be used to support transfer of 38 authentication, authorization and accounting (AAA) context between 39 devices supporting IEEE 802.1X network port authentication. This 40 specification is currently being developed within the IEEE 802.11 TgF 41 working group and is being presented to the IETF for informational 42 purposes. 44 1. Introduction 46 [IEEE8021X] enables authenticated access to [IEEE802] media, including 47 Ethernet [IEEE8023], Token Ring, and 802.11 wireless LANs [IEEE80211]. 48 Although Authentication, Authorization and Accounting (AAA) support is 49 optional within IEEE 802.1X, it is expected that many IEEE 802.1X 50 Authenticators will function as AAA clients. Behavior of IEEE 802.1X 51 Authenticators acting as RADIUS clients is described in [Congdon]. 53 The IEEE 802 Inter-Access Point Protocol (IAPP), under development 54 within the IEEE 802.11 TgF working group, supports the transfer of 55 context between access points implementing IEEE 802 technology. This 56 document describes how IAPP can be used to support transfer of 57 authentication, authorization and accounting (AAA) context between 58 devices supporting IEEE 802.1X network port authentication [IEEE8021X]. 60 In terms of organization, this document first develops a general model 61 for AAA context transfer. Central to the model is the notion of a 62 "correct" context transfer -- a transfer resulting in the same context 63 on the new access point as would have resulted had a AAA conversation 64 been completed. 66 The circumstances in which "correct" context transfer can be achieved 67 are analyzed -- demonstrating that this can only be achieved in a 68 limited set of circumstances. As a result, it is suggested that context 69 transfer protocols restrict the domain of applicability to scenarios 70 involving a high degree of homogeneity. 72 For example, layer 2 context transfer solutions are most likely to be 73 successful transferring context within media families, such as IEEE 802. 74 While the IAPP protocol is expected to be used primarily for transfer of 75 context between IEEE 802.11 access points, it is also possible for it to 76 be used to transfer context between access points supporting other IEEE 77 802 media, such as IEEE 802.15 or 802.16. Where context transfer between 78 dissimilar media is required, then higher layer homogeneity is needed. 79 This can be achieved, for example, by restricting applicability to 80 access points supporting Mobile IP. 82 1.1. Terminology 84 This document uses the following terms: 86 Authenticator 87 An Authenticator is an entity that require authentication from 88 the Supplicant. The Authenticator may be connected to the 89 Supplicant at the other end of a point-to-point LAN segment or 90 802.11 wireless link. 92 Authentication Server 93 An Authentication Server is an entity that provides an 94 Authentication Service to an Authenticator. This service 95 verifies from the credentials provided by the Supplicant, the 96 claim of identity made by the Supplicant. 98 Port Access Entity (PAE) 99 The protocol entity associated with a physical or virtual 100 (802.11) Port. A given PAE may support the protocol 101 functionality associated with the Authenticator, Supplicant or 102 both. 104 Supplicant 105 A Supplicant is an entity that is being authenticated by an 106 Authenticator. The Supplicant may be connected to the 107 Authenticator at one end of a point-to-point LAN segment or 108 802.11 wireless link. 110 1.2. Requirements language 112 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 113 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 114 described in [RFC2119]. 116 2. Context transfer model 118 In attempting to transfer context between devices, the first task is to 119 understand how "context" is defined, and what the goal of the context 120 transfer is. For the purpose of this document "context" will refer to 121 the set of state defining the service to be provided to the user. 123 To date, a number of protocols have been proposed for defining and 124 managing services provided on a per-user basis. RADIUS, defined in 125 [RFC2865], [RFC2866], [RFC2867], [RFC2868],[RFC2869], and [RFC3162] is a 126 first-generation protocol for Authentication, Authorization and 127 Accounting (AAA). Diameter and COPS have also been proposed for use in 128 AAA. 130 In each of these protocols, exchanges are used to establish, and 131 possibly to remove, state from devices. In thinking about transfer of 132 context initially established through such protocols, we propose the 133 "Equivalency Principle": 135 For context established via protocol exchanges, transfer of context 136 to a new device can be accomplished by transferring the protocol 137 exchanges that created the context on the original device, and 138 processing them on the new device. For such a context transfer to be 139 successful, the the state created on the new device by processing 140 such an exchange MUST be equivalent to the state that would have been 141 created by having the new device engage in a fresh protocol 142 conversation. 144 For the equivalency principle to be satisfied, it is necessary for the 145 new device to be able to process the protocol exchanges from the old 146 device, and for those exchanges to result in the same state on the new 147 device. This requires that the protocol messages completely describe the 148 context to be created on the device, and that the effect of processing 149 these messages not depend on state that exists uniquely on the old 150 device, but may not exist on the new device. 152 For example, a protocol message that describes the state to be attained 153 in terms of deltas from a previous state would not be suitable for use 154 in context transfer, since the effect of the protocol message would 155 differ depending on the previous device state. Similarly, if a protocol 156 message were conditionally executed based on dynamic data, such as the 157 number of users on the device, then the message might have a different 158 effect on the new device than on the old device. 160 To a large extent, AAA protocols meet the criteria, since the desired 161 device state is completely described by the authorizations. Conditional 162 execution, if it occurs, is usually confined to the AAA server. 164 The messages that establish service context differ, depending on the AAA 165 protocol that is being considered. Within RADIUS, service context is 166 only established via an Access-Accept. Access-Reject messages do not 167 establish context since their purpose is to deny access. Similarly, 168 Access-Challenge messages do not establish context since they represent 169 an intermediate stage within the authentication conversation. Since 170 only one RADIUS message (Access-Accept) establishes service context, to 171 re-establish context on a new device, to first order it is only 172 necessary to transfer Access-Accept messages to the new device, and 173 process them as if they were sent by the RADIUS server. 175 Note that since only one RADIUS message type can establish context, the 176 message type need not be included explicitly, since it is implicit. As a 177 result, devices supporting transfer of RADIUS context need only transfer 178 attributes, not the entire RADIUS message. 180 2.1. "Correct" context transfer 182 Given this model for context establishment, it is worthwhile to examine 183 when the transfer of context between devices produces a "correct" 184 result. 186 One way to define correctness in a context transfer is that the transfer 187 establishes on the new device the same context as would have been 188 created had the new device completed a AAA conversation with the 189 authentication server. Ideally, a context transfer should only succeed 190 if it is "correct" in this way. If a successful context transfer would 191 establish "incorrect" state, it would be preferable for such a transfer 192 to fail. 194 Not all AAA and access device configurations are capable of meeting this 195 definition of "correctness". Implicit within our context transfer model 196 is trust between devices transferring context. Since the new device 197 acts on the context transfer as though it had been instructed by a 198 trusted AAA server, it is necessary for the new device to trust the old 199 device. 201 In transfer of context across administrative domains, such a level of 202 trust may not be possible or appropriate. As a result, a context 203 transfer may fail even in situations where the devices are homogeneous, 204 due to lack of trust between administrative domains. 206 If the deployment is heterogeneous, it also may be difficult to meet 207 this definition of correctness. In these situations, AAA servers often 208 perform conditional evaluation, in which the authorizations returned in 209 an Access-Accept message are contingent on characteristics of the AAA 210 client or the user. For example, in a heterogeneous deployment, the AAA 211 server might return different authorizations depending on the type of 212 device making the request, in order to make sure that the requested 213 service is consistent with device capabilities. 215 If differences between the new and old device would result in the AAA 216 server sending a different set of messages to the new device than were 217 sent to the old device, then a context transfer between the devices 218 cannot be carried out correctly. 220 For example, if some access points within a deployment support dynamic 221 VLANs while others do not, then attributes present in the Access-Request 222 (such as the NAS-IP-Address, NAS-Identifier, Vendor-Identifier, etc.) 223 could be examined to determine when VLAN attributes will be returned, as 224 described in [Condgon]. VLAN support is defined in [IEEE8021Q]. 226 In practice, this limits the situations in which context transfer can be 227 expected to be successful. Where the deployed devices implement the same 228 set of services, it may be possible to transfer context successfully. 229 However, where the supported services differ between devices, the 230 context transfer may not succeed. For example, [RFC2865], section 1.1 231 states: 233 "A NAS that does not implement a given service MUST NOT implement the 234 RADIUS attributes for that service. For example, a NAS that is 235 unable to offer ARAP service MUST NOT implement the RADIUS attributes 236 for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an 237 unavailable service as an access-reject instead." 239 Note that this behavior is only applies to attributes that are known, 240 but not implemented. For attributes that are unknown, section of 5 of 241 [RFC2865] states: 243 "A RADIUS server MAY ignore Attributes with an unknown Type. A 244 RADIUS client MAY ignore Attributes with an unknown Type." 246 Obeying the Equivalency Principle, if a new device is provided with 247 RADIUS context for a known but unavailable service, then it MUST process 248 this context the same way it would handle a RADIUS Access-Accept 249 requesting an unavailable service. This MUST cause the context transfer 250 to fail. However, if a new device is provided with RADIUS context that 251 indicates an unknown attribute, then this attribute MAY be ignored. 253 Although it may seem somewhat counter-intuitive, failure is indeed the 254 "correct" result where a known but unsupported service is requested. 255 Presumably a correctly configured AAA server would not request that a 256 device carry out a service that it does not implement. This implies that 257 if the new device were to complete a AAA conversation that it would be 258 likely to receive different service instructions than those present in 259 the context transfer. In such a case, failure of the context transfer is 260 the desired result. This will cause the new device to go back to the AAA 261 server in order to receive the appropriate service definition. 263 Thus in practice, context transfer is most likely to be successful 264 within a homogeneous device deployment within a single administrative 265 domain. For example, where all the devices support IEEE 802.1X, success 266 is possible, as long as the same set of security services are supported. 267 For example, it would not be advisable to attempt to transfer context 268 between an 802.11 access point implementing WEP to an 802.15 access 269 point without security support. The correct result of such a transfer 270 would be a failure, since if the transfer were blindly carried out, then 271 the user would be moved from a secure to an insecure channel without 272 permission from the AAA server. Thus the definition of a "known but 273 unsupported service" MUST encompass requests for unavailable security 274 services. This includes vendor-specific attributes related to security, 275 such as those described in [RFC2548]. 277 In general, context transfers between media with different service 278 models should not be expected to be successful. For example, attempts to 279 transfer context between cellular devices and 802.11 access points 280 cannot be "correct" within this model, unless the cellular access points 281 implement the same set of services as the 802.11 access points. Where 282 the implemented services differ, the correct behavior would be for such 283 context transfers to fail, and for the 802.11 AP to pick up the correct 284 service definition by going back to the AAA server. Thus while attempted 285 context transfers between heterogeneous technologies may fail, context 286 transfers between homogeneous devices have a higher probability of 287 success. 289 2.2. Context handling 291 AAA is not mandatory to implement for IEEE 802.1X Authenticators. The 292 IEEE 802.1X [IEEE8021X] specification provides guidelines for usage of 293 RADIUS [RFC2865], a revised version of which can be found in [Congdon]. 294 However, support for other protocols is feasible. Since a IEEE 802.1X 295 Authenticator may support zero or more AAA protocols and implementation 296 of AAA is non-mandatory, an IEEE 802.1X Authenticator cannot be assumed 297 to implement any particular AAA protocol. 299 Therefore it is important that the context transfer protocol be agnostic 300 with respect to AAA protocols. If two devices share support for a given 301 AAA protocol, then the context transfer mechanism should enable the 302 devices to interoperate. One way to accomplish this is to enable the 303 context transfer mechanism to support multiple AAA protocols within the 304 same message. This allows a device that speaks multiple protocols to 305 interoperate with a device that only supports one of them. 307 Through addition of a AAA Information Element, and unique sub-elements 308 for each AAA protocol, it is possible to support transfer of context for 309 multiple AAA protocols within the same message. Assigning only one 310 Information Element for AAA ensures against exhaustion of the IAPP 311 element space. Since the number of AAA attributes may be substantial, 312 assignment of Information Elements to individual attributes is to be 313 avoided. 315 Packaging each AAA protocol message within its own individual sub- 316 element enables compatibility with the definition of correctness 317 described earlier. Within IAPP, a device that receives Information 318 Elements or sub-elements that it does not support will ignore those 319 elements, and process those that it does support. 321 However, as described earlier, our model of context transfer requires 322 that if a device supports a AAA protocol, that transferred AAA messages 323 MUST be processed according to the rules of the protocol. For RADIUS, 324 this implies that the context transfer MUST fail if known but 325 unavailable services are requested, but that unknown attributes MAY be 326 ignored. As a result, individual RADIUS attributes MUST NOT be encoded 327 as Information Elements or sub-elements within IAPP. Rather, RADIUS 328 attribues are encoded as a unit within the RADIUS sub-element. This 329 enables the correct processing to occur. While a device may ignore an 330 entire Information Element or sub-element, once the Information Element 331 or sub-element is recognized it must be processed in its entirety. 333 Among other things, this approach enables the context transfer operation 334 to be independent of the supported AAA protocol. For example, a device 335 supporting both Diameter and RADIUS could include sub-elements for both 336 protocols. This would enable transfer of context to a new device 337 supporting either protocol. 339 2.3. Information Element format 341 Within IAPP, Information Elements have the following structure: 343 0 1 2 3 344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Element Identifier | Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Information... 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Element Identifier 353 The Element Identifier field is two octets. It identifies the 354 enclosed Information Element. 356 TBD - Element Identifier for AAA 358 Length 360 The Length field is two octets. It encodes the length of the 361 Information Element, including the Element Identifier, Length and 362 Information fields. 364 Information 366 The Information field is variable length. It encodes the Information 367 Element. 369 AAA sub-elements are encoded within the Information field as follows: 371 0 1 2 3 372 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Organization Unique Identifier | Type | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Data... 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Organization Unique Identifier (OUI) 380 The OUI is a three octet field, encoding the Organization Unique 381 Identifier. An OUI of zero is used for standardized sub-elements. 382 Non-zero OUIs can be used to support vendor-specific sub-elements. 384 Type 386 The type field is one octet, and represents the AAA protocol type: 388 1 = RADIUS 389 2 = Diameter 391 Data 393 The Data field is of variable length, and contains the context to be 394 transferred. For RADIUS this consists of a list of attributes. 396 2.4. Usage guidelines for the RADIUS sub-element 398 RADIUS context is established solely by Access-Accept messages, and 399 therefore the bulk of RADIUS attributes within the RADIUS sub-element 400 are those that may be included within an Access-Accept. 402 There are three classes of exception: 404 [1] Authentication attributes not relevant to IEEE 802 or to IEEE 405 802.1X context transfer. 407 [2] Accounting attributes such as the Acct-Authentic and Acct-Multi- 408 SessionId accounting attributes. 410 [3] Attributes included within an Access Request that provide 411 additional information relating to the previous session on the old 412 AP. This includes NAS-IP-Address, NAS-IPv6-Address, NAS-Port,NAS- 413 Identifier, Called-Station-Id, Calling-Station-Id, and NAS-Port-Id. 415 The attributes allowable for use with transfers of IEEE 802.1X context 416 are described in Appendix A. 418 As noted in [Congdon], some attributes are not relevant to IEEE 802, 419 while others that are relevant are not useful for context transfer. For 420 example, where an IAPP protocol provides support for integrity 421 protection, transfer of an additional integrity check (Message- 422 Authenticator attribute) is not necessary. Similarly, since the IEEE 423 802.1X backend state machine is driven purely by the authentication 424 outcome, not by the contents of the EAP-Message attribute, transferring 425 this attribute is not necessary. 427 Acct-Authentic encodes the authentication technique utilized on the old 428 access point: RADIUS, Local or Remote. A value of RADIUS denotes 429 authentication against a backend RADIUS server; Local means that the 430 user authenticated against the local database on the old device; Remote 431 means that a AAA protocol other than RADIUS was used. 433 Typically, it does not make sense to transfer context of sessions 434 established by local authentication. This violates the Equivalency 435 Principle because context established via local authentication will not 436 in general be the same as the context that would be established by 437 carrying out a conversation with the AAA server. In order to guard 438 against inappropriate context transfers, the new device MUST examine the 439 authentication status prior to deciding to accept the context transfer. 441 Acct-Multi-SessionId enables linkage of accounting records from related 442 sessions. As described in [Congdon], it is possible to maintain the same 443 Acct-Multi-SessionId as a user moves between devices. To enable this, 444 it is necessary to include the Acct-Multi-SessionId in the context 445 transfer. 447 3. Security considerations 449 3.1. Trust issues 451 Implicit within our context transfer model is trust between devices 452 engaging in a context transfer. Since the new device will act on the 453 context transfer as though it had been given the service instructions by 454 a trusted AAA server, it is necessary for the new device to trust the 455 old device, at least sufficiently to allow transfer of AAA context. 457 In transfer of context across administrative domains, such a level of 458 trust may not be possible or appropriate. Therefore it is possible for 459 context transfer to fail even in situations where the devices are 460 homogeneous, due to lack of trust between administrative domains. 462 Note however, that even where the required trust exists, it SHOULD NOT 463 extend to enabling the new Access Point to obtain the keys used for 464 encrypting traffic on the old Access Point. This would enable a rogue 465 new Access Point to decrypt traffic previously captured on the old 466 Access Point. A variety of mechanisms can be used to prevent this and a 467 specific mechanism is not mandated in this specification. For example, 468 it is possible for the old Access Point to transfer to the new Access 469 Point a "transfer key" derived via a one-way function from the old key, 470 so that the old key cannot be easily obtained from the "transfer key". 471 Alternatively, where perfect forward secrecy (PFS) is desired, a new key 472 can be derived that does not depend on the old key. 474 Another implication of the "Equivalency Principle" is that the context 475 transfer protocol SHOULD provide the same level of security as the AAA 476 protocol whose context is being transferred. For example, AAA protocol 477 messages may include attributes requiring confidentiality. This 478 includes user passwords, encryption keys, or tunnel passwords. In order 479 to transfer these attributes securely, confidentiality is required. 480 Similarly, where the AAA protocol is using IPsec [RFC2401] to provide 481 confidentiality, it does not make sense for the context transfer 482 protocol to use a less secure mechanism, such as the shared secret-based 483 hiding described in [RFC2865]. 485 4. IANA Considerations 487 This specification does not create any RADIUS attributes nor any new 488 number spaces for IANA administration. 490 5. References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", RFC 2119, March, 1997. 495 [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the 496 Internet Protocol", RFC 2401, November 1998. 498 [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS attributes", RFC 499 2548, March 1999. 501 [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 502 Authentication Dial In User Service (RADIUS)", RFC 2865, June 503 2000. 505 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 507 [RFC2867] Zorn, G., Mitton, D., Aboba, B., "RADIUS Accounting 508 Modifications for Tunnel Protocol Support", RFC 2867, June 509 2000. 511 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., 512 Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", 513 RFC 2868, June 2000. 515 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 516 2869, June 2000. 518 [RFC3162] Aboba, B., Zorn, G., Mitton, D.,"RADIUS and IPv6", RFC 3162, 519 August 2001. 521 [Congdon] Congdon, P., Et al. "IEEE 802.1X Usage Guidelines", Internet 522 draft (work in progress), draft-congdon-radius-8021x-17.txt, 523 November 2001. 525 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 526 Overview and Architecture, ANSI/IEEE Std 802, 1990. 528 [IEEE8021Q] 529 IEEE Standards for Local and Metropolitan Area Networks: Draft 530 Standard for Virtual Bridged Local Area Networks, P802.1Q/D8, 531 January 1998. 533 [IEEE8021X] 534 IEEE Standards for Local and Metropolitan Area Networks: Port 535 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 537 [IEEE8023] 538 ISO/IEC 8802-3 Information technology - Telecommunications and 539 information exchange between systems - Local and metropolitan 540 area networks - Common specifications - Part 3: Carrier Sense 541 Multiple Access with Collision Detection (CSMA/CD) Access 542 Method and Physical Layer Specifications, (also ANSI/IEEE Std 543 802.3- 1996), 1996. 545 [IEEE80211] 546 Information technology - Telecommunications and information 547 exchange between systems - Local and metropolitan area 548 networks - Specific Requirements Part 11: Wireless LAN Medium 549 Access Control (MAC) and Physical Layer (PHY) Specifications, 550 IEEE Std. 802.11-1997, 1997. 552 Appendix A - Table of Attributes 554 The following table provides a guide to which attributes are sent and 555 received as part of IEEE 802.1X authentication, and which attributes are 556 considered part of the "context" to be transferred during roaming. L3 557 denotes attributes that will be understood only by switches or access 558 points implementing Layer 3 capabilities. 560 802.1X Context # Attribute 561 X X 1 User-Name [RFC2865] 562 2 User-Password [RFC2865] 563 3 CHAP-Password [RFC2865] 564 X R 4 NAS-IP-Address [RFC2865] 565 X R 5 NAS-Port [RFC2865] 566 X X 6 Service-Type [RFC2865] 567 7 Framed-Protocol [RFC2865] 568 8 Framed-IP-Address [RFC2865] 569 9 Framed-IP-Netmask [RFC2865] 570 L3 X 10 Framed-Routing [RFC2865] 571 X X 11 Filter-Id [RFC2865] 572 X X 12 Framed-MTU [RFC2865] 573 13 Framed-Compression [RFC2865] 574 L3 X 14 Login-IP-Host [RFC2865] 575 L3 X 15 Login-Service [RFC2865] 576 L3 X 16 Login-TCP-Port [RFC2865] 577 X X 18 Reply-Message [RFC2865] 578 19 Callback-Number [RFC2865] 579 20 Callback-Id [RFC2865] 580 L3 X 22 Framed-Route [RFC2865] 581 L3 X 23 Framed-IPX-Network [RFC2865] 582 X X 24 State [RFC2865] 583 X X 25 Class [RFC2865] 584 X X 26 Vendor-Specific [RFC2865] 585 X X 27 Session-Timeout [RFC2865] 586 X X 28 Idle-Timeout [RFC2865] 587 X X 29 Termination-Action [RFC2865] 588 X R 30 Called-Station-Id [RFC2865] 589 X R 31 Calling-Station-Id [RFC2865] 590 X R 32 NAS-Identifier [RFC2865] 591 X 33 Proxy-State [RFC2865] 592 34 Login-LAT-Service [RFC2865] 593 35 Login-LAT-Node [RFC2865] 594 36 Login-LAT-Group [RFC2865] 595 802.1X # Attribute 596 802.1X # Attribute 597 L3 X 37 Framed-AppleTalk-Link [RFC2865] 598 L3 X 38 Framed-AppleTalk-Network [RFC2865] 599 L3 X 39 Framed-AppleTalk-Zone [RFC2865] 600 X 40 Acct-Status-Type [RFC2866] 601 X 41 Acct-Delay-Time [RFC2866] 602 X 42 Acct-Input-Octets [RFC2866] 603 X 43 Acct-Output-Octets [RFC2866] 604 X 44 Acct-Session-Id [RFC2866] 605 X X 45 Acct-Authentic [RFC2866] 606 X 46 Acct-Session-Time [RFC2866] 607 X 47 Acct-Input-Packets [RFC2866] 608 X 48 Acct-Output-Packets [RFC2866] 609 X 49 Acct-Terminate-Cause [RFC2866] 610 X X 50 Acct-Multi-Session-Id [RFC2866] 611 51 Acct-Link-Count [RFC2866] 612 X 52 Acct-Input-Gigawords [RFC2869] 613 X 53 Acct-Output-Gigawords [RFC2869] 614 X 55 Event-Timestamp [RFC2869] 615 60 CHAP-Challenge [RFC2865] 616 X X 61 NAS-Port-Type [RFC2865] 617 62 Port-Limit [RFC2865] 618 63 Login-LAT-Port [RFC2865] 619 X X 64 Tunnel-Type [RFC2868] 620 X X 65 Tunnel-Medium-Type [RFC2868] 621 L3 X 66 Tunnel-Client-Endpoint [RFC2868] 622 L3 X 67 Tunnel-Server-Endpoint [RFC2868] 623 L3 X 68 Acct-Tunnel-Connection [RFC2867] 624 L3 X 69 Tunnel-Password [RFC2868] 625 70 ARAP-Password [RFC2869] 626 71 ARAP-Features [RFC2869] 627 72 ARAP-Zone-Access [RFC2869] 628 73 ARAP-Security [RFC2869] 629 74 ARAP-Security-Data [RFC2869] 630 75 Password-Retry [RFC2869] 631 76 Prompt [RFC2869] 632 X 77 Connect-Info [RFC2869] 633 X 78 Configuration-Token [RFC2869] 634 X 79 EAP-Message [RFC2869] 635 X 80 Message-Authenticator [RFC2869] 636 X X 81 Tunnel-Private-Group-ID [RFC2868] 637 L3 X 82 Tunnel-Assignment-ID [RFC2868] 638 X X 83 Tunnel-Preference [RFC2868] 639 84 ARAP-Challenge-Response [RFC2869] 640 802.1X # Attribute 641 802.1X # Attribute 642 X 85 Acct-Interim-Interval [RFC2869] 643 X 86 Acct-Tunnel-Packets-Lost [RFC2867] 644 X R 87 NAS-Port-Id [RFC2869] 645 88 Framed-Pool [RFC2869] 646 L3 X 90 Tunnel-Client-Auth-ID [RFC2868] 647 L3 X 91 Tunnel-Server-Auth-ID [RFC2868] 648 X R 95 NAS-IPv6-Address [RFC3162] 649 96 Framed-Interface-Id [RFC3162] 650 L3 X 97 Framed-IPv6-Prefix [RFC3162] 651 L3 X 98 Login-IPv6-Host [RFC3162] 652 L3 X 99 Framed-IPv6-Route [RFC3162] 653 L3 X 100 Framed-IPv6-Pool [RFC3162] 654 802.1X Context # Attribute 656 Key 657 === 659 802.1X = Allowed for use with IEEE 802.1X 660 Context = Transferred during roaming if available 661 L3 = implemented only on switches/access points with Layer 3 662 capabilities 663 R = Attributes acceptable for context transfer that are 664 included only within an Access-Request 666 Acknowledgments 668 The authors would like to acknowledge Bob O'Hara of Informed Technology 669 and Dave Bagby of 3Com for contributions to this document. 671 Authors' Addresses 673 Bernard Aboba 674 Tim Moore 675 Microsoft Corporation 676 One Microsoft Way 677 Redmond, WA 98052 679 EMail: {bernarda, timmoore}@microsoft.com 680 Phone: +1 425 882 8080 681 Fax: +1 425 936 7329 683 Intellectual Property Statement 685 The IETF takes no position regarding the validity or scope of any 686 intellectual property or other rights that might be claimed to pertain 687 to the implementation or use of the technology described in this 688 document or the extent to which any license under such rights might or 689 might not be available; neither does it represent that it has made any 690 effort to identify any such rights. Information on the IETF's 691 procedures with respect to rights in standards-track and standards- 692 related documentation can be found in BCP-11. Copies of claims of 693 rights made available for publication and any assurances of licenses to 694 be made available, or the result of an attempt made to obtain a general 695 license or permission for the use of such proprietary rights by 696 implementors or users of this specification can be obtained from the 697 IETF Secretariat. 699 The IETF invites any interested party to bring to its attention any 700 copyrights, patents or patent applications, or other proprietary rights 701 which may cover technology that may be required to practice this 702 standard. Please address the information to the IETF Executive 703 Director. 705 Full Copyright Statement 707 Copyright (C) The Internet Society (2002). All Rights Reserved. 708 This document and translations of it may be copied and furnished to 709 others, and derivative works that comment on or otherwise explain it or 710 assist in its implementation may be prepared, copied, published and 711 distributed, in whole or in part, without restriction of any kind, 712 provided that the above copyright notice and this paragraph are included 713 on all such copies and derivative works. However, this document itself 714 may not be modified in any way, such as by removing the copyright notice 715 or references to the Internet Society or other Internet organizations, 716 except as needed for the purpose of developing Internet standards in 717 which case the procedures for copyrights defined in the Internet 718 Standards process must be followed, or as required to translate it into 719 languages other than English. The limited permissions granted above are 720 perpetual and will not be revoked by the Internet Society or its 721 successors or assigns. This document and the information contained 722 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 723 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 724 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 725 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 726 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 728 Expiration Date 730 This memo is filed as , and expires 731 November 22, 2002.