Network Working Group Bernard Aboba INTERNET-DRAFT Tim Moore Category: Informational Microsoft <draft-aboba-802-context-00.txt> 11 July 2001 A Model for Context Transfer in IEEE 802 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract IEEE 802.1X [13] enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although Authentication, Authorization and Accounting (AAA) support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as AAA clients. Behavior of IEEE 802.1X Authenticators acting as RADIUS clients is described in [24]. The IEEE 802 Inter-Access Point Protocol (IAPP), under development within the IEEE 802.11 TgF working group, supports the transfer of context between access points implementing IEEE 802 technology. Rather than attempting to define both the context transfer protocol and the information elements in a single specification, the IAPP protocol provides a framework for specification and allocation of information elements. The separation of mechanism and data has enabled work to Aboba & Moore Informational [Page 1]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 proceed on parallel tracks, with protocol definition occurring separately from the definition of the information elements. This document describes how IAPP can be used to support transfer of authentication, authorization and accounting (AAA) context between devices supporting IEEE 802.1X network port authentication [13]. It also defines a framework for allocation of the required information elements within IAPP. This specification is currently being developed within the IEEE 802.11 TgF working group and is being presented to the IETF for informational purposes. 1. Introduction IEEE 802.1X [13] enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although Authentication, Authorization and Accounting (AAA) support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as AAA clients. Behavior of IEEE 802.1X Authenticators acting as RADIUS clients is described in [24]. The IEEE 802 Inter-Access Point Protocol (IAPP), under development within the IEEE 802.11 TgF working group, supports the transfer of context between access points implementing IEEE 802 technology. This document describes how IAPP can be used to support transfer of authentication, authorization and accounting (AAA) context between devices supporting IEEE 802.1X network port authentication [13]. In terms of organization, this document first develops a general model for AAA context transfer. Central to the model is the notion of a "correct" context transfer -- a transfer resulting in the same context on the new access point as would have resulted had a AAA conversation been completed. The circumstances in which "correct" context transfer can be achieved are analyzed -- demonstrating that this can only be achieved in a limited set of circumstances. As a result, it is suggested that context transfer protocols restrict the domain of applicability to scenarios involving a high degree of homogeneity. For example, layer 2 context transfer solutions are most likely to be successful transferring context within media families, such as IEEE 802. While the IAPP protocol is expected to be used primarily for transfer of context between IEEE 802.11 access points, it is also possible for it to be used to transfer context between access points supporting other IEEE 802 media, such as IEEE 802.15 or 802.16. Where context transfer between dissimilar media is required, then higher layer homogeneity is needed. This can be achieved, for example, by restricting applicability to access points supporting Mobile IP. Aboba & Moore Informational [Page 2]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 1.1. Terminology This document uses the following terms: Authenticator An Authenticator is an entity that require authentication from the Supplicant. The Authenticator may be connected to the Supplicant at the other end of a point-to-point LAN segment or 802.11 wireless link. Authentication Server An Authentication Server is an entity that provides an Authentication Service to an Authenticator. This service verifies from the credentials provided by the Supplicant, the claim of identity made by the Supplicant. Port Access Entity (PAE) The protocol entity associated with a physical or virtual (802.11) Port. A given PAE may support the protocol functionality associated with the Authenticator, Supplicant or both. Supplicant A Supplicant is an entity that is being authenticated by an Authenticator. The Supplicant may be connected to the Authenticator at one end of a point-to-point LAN segment or 802.11 wireless link. 1.2. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. 2. Context transfer model In attempting to transfer context between devices, the first task is to understand how "context" is defined, and what the goal of the context transfer is. For the purpose of this document "context" will refer to the set of state defining the service to be provided to the user. To date, a number of protocols have been proposed for defining and managing services provided on a per-user basis. RADIUS, defined in [4]-[6], is a first-generation protocol for Authentication, Authorization and Accounting (AAA). Diameter is a next generation AAA protocol currently under development. COPS is a protocol used to manage the establishment of Quality of Service (QoS) state. Aboba & Moore Informational [Page 3]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 In each of these protocols, exchanges are used to establish, and possibly to remove, state from devices. In thinking about transfer of context initially established through such protocols, we would like to propose the "Equivalency Principle": For context established via protocol exchanges, transfer of context to a new device can be accomplished by transferring the protocol exchanges that created the context on the original device, and processing them on the new device. For such a context transfer to be successful, the the state created on the new device by processing such an exchange MUST be equivalent to the state that would have been created by having the new device engage in a fresh protocol conversation. For the equivalency principle to be satisifed, it is necessary for the new device to be able to process the protocol exchanges from the old device, and for those exchanges to result in the same state on the new device. This requires that the protocol messages completely describe the context to be created on the device, and that the effect of processing these messages not depend on state that exists uniquely on the old device, but may not exist on the new device. For example, a protocol message that describes the state to be attained in terms of deltas from a previous state would not be suitable for use in context transfer, since the effect of the protocol message would differ depending on the previous device state. Similarly, if a protocol message were conditionally executed based on dynamic data, such as the number of users on the device, then the message might have a different effect when processed on the new device than its effect on the old device. To a large extent, AAA protocols meet the criteria, since the desired device state is completely described by the authorizations. Conditional execution, if it occurs, is relatively rare and usually confined to the AAA server. The set of messages that establish service context differ, depending on the AAA protocol that is being considered. Within RADIUS [4]-[6], service context is only established via an Access-Accept. Access-Reject messages do not establish context since their purpose is to deny access. Similarly, Access-Challenge messages do not establish context since they represent an intermediate stage within the authentication conversation. Since only one RADIUS message (Access-Accept) establishes service context, to re-establish context on a new device, to first order it is only necessary to transfer Access-Accept messages to the new device, and process them as if they were sent by the RADIUS server. Aboba & Moore Informational [Page 4]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 Note that since only one RADIUS message type can establish context, the message type need not be included explicitly, since it is implicit. As a result, devices supporting transfer of RADIUS context need only transfer AVPs, not the entire RADIUS message. 2.1. "Correct" context transfer Given this model for context establishment, it is worthwhile to examine when the transfer of context between devices produces a "correct" result. One way to define correctness in a context transfer is that the transfer establishes on the new device the same context as would have been created had the new device completed a AAA conversation with the authentication server. Ideally, a context transfer should only succeed if it is "correct" in this way. If a context transfer were to establish "incorrect" state, then it would be preferred for such a transfer to fail. Not all AAA and access device configurations are capable of meeting this definition of "correctness". Implicit within our context transfer model is trust between devices engaging in a context transfer. Since the new device will act on the context transfer as though it had been given the service instructions by a trusted AAA server, it is necessary for the new device to trust the old device. In transfer of context across administrative domains, such a level of trust may not be possible or appropriate. Therefore it is possible for context transfer to fail even in situations where the devices are homogeneous, due to lack of trust between administrative domains. If the deployment is heterogeneous, then it may also be difficult to meet this definition of correctness. In these situations, AAA servers often perform conditional evaluation, in which the authorizations returned in an Access-Accept message are contingent on characteristics of the AAA client or the user. For example, in a heterogeneous deployment, the AAA server might return different authorizations depending on the type of device making the request, in order to make sure that the requested service is consistent with device capabilities. If differences between the new and old device would cause the AAA server to send a different set of messages to the new device than were sent to the old device, then a context transfer between the devices cannot be carried out correctly. For example, if some access points within a deployment support dynamic VLANs while others do not, then attributes present in the Access-Request (such as the NAS-IP-Address, NAS-Identifier, Vendor-Identifier, etc.) Aboba & Moore Informational [Page 5]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 could be examined to determine when VLAN attributes will be returned, as described in [24]. In practice, this limits the situations in which context transfer can be expected to be successful. Where the deployed devices implement the same set of services, it may be possible to transfer context successfullly. However, where the supported services differ between devices, or where some devices require vendor specific attributes, the context transfer may not succeed. For example, RFC 2865, section 1.1 states: "A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead." Thus, if a device is to process a context transfer in the same way that it would handle a protocol exchange with a RADIUS server, then if the new device is provided with context for an unavailable service, this MUST cause the context transfer to fail. Such a failure is a "correct" result within our definition. Presumably a correctly configured AAA server would not request that a device carry out a service that it does not implement. This implies that if the new device were to complete a AAA conversation that it would be likely to receive different service instructions than those present in the context transfer. In such a case, failure of the context transfer is the desired result. This will cause the new device to go back to the AAA server in order to receive the appropriate service definition. Thus in practice, context transfer is most likely to be successful within a homogeneous device deployment within a single administrative domain. For example, where all the devices support IEEE 802.1X, success is possible, as long as the same set of security services are supported. For example, it would not be advisable to attempt to transfer context between an 802.11 access point implementing WEP to an 802.15 access point without security support. The correct result of such a transfer would be a failure, since if the transfer were blindly carried out, then the user would find themselves moved from a secure to an insecure channel. Thus the definition of an "unsupported service" MUST be encompass requests for unavailable security services. In general, context transfers between media with different service models should not be expected to be successful. For example, attempts to transfer context between cellular devices and 802.11 access points cannot be "correct" within this model, since the cellular devices do not implement the same set of services as 802.11. Therefore, the correct behavior would be for such context transfers to fail, and for the 802.11 Aboba & Moore Informational [Page 6]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 AP to pick up the correct service definition by going back to the AAA server. Thus while transfers between dissimilar technologies will require service interruption, subsequent context transfers between IEEE 802 devices are likely to have a higher probability of success. 2.2. Context handling AAA is not mandatory to implement for IEEE 802.1X Authenticators. The IEEE 802.1X specification provides guidelines for usage of RADIUS [13], a revised version of which can be found in [24]. However, support for other protocols is feasible. Since a IEEE 802.1X Authenticator may support zero or more AAA protocols and implementation of AAA is non- mandatory, an IEEE 802.1X Authenticator cannot be assumed to implement any particular AAA protocol. Therefore it is important to define a context transfer mechanism that is protocol agnostic. If two devices share support for a given AAA protocol, then the context transfer mechanism should enable the devices to interoperate. One way to accomplish this is to enable the context transfer mechanism to support multiple AAA protocols within the same message. This allows a device that speaks multiple protocols to interoperate with a device that only supports one of them. Through use of Information Elements, it is possible to support transfer of context for multiple AAA protocols within the same message. It is proposed than a unique Information Element be allocated to each protocol, and that sub-elements be defined within those Information Elements, if required. Assigning only one Information Element per protocol ensures against exhaustion of the IAPP element space, since the number of AAA attributes may be substantial, so that assignment of Information Elements to individual attributes is to be avoided. The packaging of AAA messages within a single Information Element also enables compatibility with the definition of correctness described earlier. Within IAPP, a device that receives Information Elements that it does not support will ignore those elements, and process those that it does support. However, as described earlier, our model of context transfer requires that if a device supports a AAA protocol, that transferred AAA messages MUST be processed according to the rules of the protocol. For RADIUS, this implies that the context transfer MUST fail if unavailable services are requested. As a result, individual RADIUS attributes MUST NOT be encoded as Information Elements within IAPP. Rather, they are encoded as sub-elements. This enables the correct processing to occur. While a device may ignore an entire Information Element, once the Information Element is recognized it must be processed in its entirety. Thus, sub- elements are processed via different rules than Information Elements, Aboba & Moore Informational [Page 7]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 and the distinction is critical to the correct operation of IAPP. Among other things, this approach enables the context transfer operation to be independent of the supported AAA protocol. For example, a device supporting both Diameter and RADIUS could include Information Elements for both protocols. This would enable transfer of context to a new device supporting either protocol. 2.3. Information Element format Within IAPP, Information Elements have the following structure: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Element Identifier The Element Identifier field is two octets. It identifies the enclosed Information Element. Length The Length field is two octets. It encodes the length of the Information Element, including the Element Identifier, Length and Information fields. Information The Information field is variable length. It encodes the Information Element. AAA sub-elements are encoded within the Information field as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Organization Unique Identifier | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Organization Unique Identifier (OUI) Aboba & Moore Informational [Page 8]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 The OUI is a three octet field, encoding the Organization Unique Identifier. An OUI of zero is used for standardized sub-elements. Non-zero OUIs can be used to support vendor-specific attributes. Type The type field is one octet, and represents the AAA protocol type. To date only RADIUS is assigned a Type field (TBD). Data The Data field is of variable length, and contains the information to be transferred. For RADIUS this consists of AVPs. 2.4. Usage guidelines for the RADIUS sub-element As noted earlier, since RADIUS context is established solely by Access- Accept messages, to first order the RADIUS AVPs that may be included within the RADIUS sub-element are those that are allowable for inclusion within an Access-Accept. The two exceptions are accounting attributes: Acct-Authentic and Acct-Multi-SessionId. The attributes allowable for use with transfers of IEEE 802.1X context are described in Appendix A. Acct-Authentic provides information on the authentication technique that was utilized on the old access point. Acceptable values are RADIUS, Local and Remote. Typically, it does not make sense to transfer context of sessions established by local authentication, so that the new device will wish to understand the authentication status prior to making a decision on accepting the context transfer. Acct-Multi-SessionId enables linkage of accounting records from related sessions. As described in [24], it is possible to maintain the same Acct-Multi-SessionId as a user moves between devices. To enable this, it is necessary to transfer the Acct-Multi-SessionId between devices. 3. Open issues There are open issues relating to transfer of the Message-Authenticator and EAP-Message attributes. Assuming that the IAPP protocol provides support for confidentiality, then transfer of an additional integrity check (Message-Authenticator) is not strictly necessary. However, in order to provide strict conformance to the equivalency principle, it may be desirable to provide this attribute as well, to enable the RADIUS client processing logic to be envoked without modification. Similarly, since the IEEE 802.1X backend state machine is driven purely by the authentication outcome, not by the contents of the EAP-Message attribute, transferring this attribute is not strictly necessary. Aboba & Moore Informational [Page 9]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 4. Security considerations 4.1. Trust issues Implicit within our context transfer model is trust between devices engaging in a context transfer. Since the new device will act on the context transfer as though it had been given the service instructions by a trusted AAA server, it is necessary for the new device to trust the old device. In transfer of context across administrative domains, such a level of trust may not be possible or appropriate. Therefore it is possible for context transfer to fail even in situations where the devices are homogeneous, due to lack of trust between administrative domains. Another implication of the "equivalency principle" is that the context transfer protocol SHOULD provide the same level of security as the AAA protocol whose context is being transferred. For example, where the AAA protocol is using IPSEC to provide confidentiality, it does not make sense for the context transfer protocol to use shared secret-based hiding. 4.2. Confidentiality AAA protocol messages may include attributes whose contents are confidential. This includes user passwords, encryption keys, or tunnel passwords. In order to transfer these attributes securely, it is necessary to ensure confidentiality. Within our context transfer model, attributes are processed as though they came from the AAA server. As a result, existing AAA security mechanisms are used in order to ensure confidentiality. This can be accomplished in two ways. As described in [4], RADIUS attributes can be encrypted using the shared secret shared by the new device and the AAA server. Alternatively, if IPSEC is supported, ESP with a non-null transform can be used to provide confidentiality, as described in [23]. In this case, if a shared secret does not exist, then a null shared secret is assumed. 5. References [1] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [2] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. Aboba & Moore Informational [Page 10]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [4] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [6] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 2869, June 2000. [7] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [8] ISO/IEC 10038 Information technology - Telecommunications and information exchange between systems - Local area networks - Media Access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D- 1993), 1993. [9] ISO/IEC Final CD 15802-3 Information technology - Tele- communications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3:Media Access Control (MAC) bridges, (current draft available as IEEE P802.1D/D15). [10] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q/D8, January 1998. [11] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996. [12] IEEE Standards for Local and Metropolitan Area Networks: Demand Priority Access Method, Physical Layer and Repeater Specification For 100 Mb/s Operation, IEEE Std 802.12-1995. [13] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Draft 802.1X/D11, March 2001. [14] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [15] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. Aboba & Moore Informational [Page 11]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 [16] Aboba, B., Beadles, M., "The Network Access Identifier", RFC 2486, January 1999. [17] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [18] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. [19] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. [20] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [21] Zorn, G., Mitton, D., Aboba, B., "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [22] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1997, 1997. [23] Aboba, B., Zorn, G., Mitton, D.,"RADIUS and IPv6", Internet draft (work in progress), draft-aboba-radius-ipv6-10.txt, June 2001. [24] Congdon, P., Et al. "IEEE 802.1X Usage Guidelines", Internet draft (work in progress), draft-congdon-radius-8021x-15.txt, July 2001. 6. IANA Considerations This specification does not create any RADIUS attributes nor any new number spaces for IANA administration. Aboba & Moore Informational [Page 12]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 Appendix A - Table of Attributes The following table provides a guide to which attributes are sent and received as part of IEEE 802.1X authentication, and which attributes are considered part of the "context" to be transferred during roaming. L3 denotes attributes that will be understood only by switches or access points implementing Layer 3 capabilities. 802.1X Context # Attribute X X 1 User-Name [4] 2 User-Password [4] 3 CHAP-Password [4] X 4 NAS-IP-Address [4] X 5 NAS-Port [4] X X 6 Service-Type [4] 7 Framed-Protocol [4] 8 Framed-IP-Address [4] 9 Framed-IP-Netmask [4] L3 X 10 Framed-Routing [4] X X 11 Filter-Id [4] X X 12 Framed-MTU [4] 13 Framed-Compression [4] 14 Login-IP-Host [4] 15 Login-Service [4] 16 Login-TCP-Port [4] X X 18 Reply-Message [4] 19 Callback-Number [4] 20 Callback-Id [4] L3 X 22 Framed-Route [4] L3 X 23 Framed-IPX-Network [4] X X 24 State [4] X X 25 Class [4] X X 26 Vendor-Specific [4] X X 27 Session-Timeout [4] X X 28 Idle-Timeout [4] X X 29 Termination-Action [4] X 30 Called-Station-Id [4] X 31 Calling-Station-Id [4] X 32 NAS-Identifier [4] X 33 Proxy-State [4] 34 Login-LAT-Service [4] 35 Login-LAT-Node [4] 36 Login-LAT-Group [4] 802.1X # Attribute Aboba & Moore Informational [Page 13]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 802.1X # Attribute L3 X 37 Framed-AppleTalk-Link [4] L3 X 38 Framed-AppleTalk-Network [4] L3 X 39 Framed-AppleTalk-Zone [4] X 40 Acct-Status-Type [5] X 41 Acct-Delay-Time [5] X 42 Acct-Input-Octets [5] X 43 Acct-Output-Octets [5] X 44 Acct-Session-Id [5] X X 45 Acct-Authentic [5] X 46 Acct-Session-Time [5] X 47 Acct-Input-Packets [5] X 48 Acct-Output-Packets [5] X 49 Acct-Terminate-Cause [5] X X 50 Acct-Multi-Session-Id [5] 51 Acct-Link-Count [5] X 52 Acct-Input-Gigawords [6] X 53 Acct-Output-Gigawords [6] X 55 Event-Timestamp [6] 60 CHAP-Challenge [4] X X 61 NAS-Port-Type [4] 62 Port-Limit [4] 63 Login-LAT-Port [4] X X 64 Tunnel-Type [20] X X 65 Tunnel-Medium-Type [20] L3 X 66 Tunnel-Client-Endpoint [20] L3 X 67 Tunnel-Server-Endpoint [20] L3 X 68 Acct-Tunnel-Connection [21] L3 X 69 Tunnel-Password [20] 70 ARAP-Password [6] 71 ARAP-Features [6] 72 ARAP-Zone-Access [6] 73 ARAP-Security [6] 74 ARAP-Security-Data [6] 75 Password-Retry [6] 76 Prompt [6] X 77 Connect-Info [6] X 78 Configuration-Token [6] X 79 EAP-Message [6] X 80 Message-Authenticator [6] X X 81 Tunnel-Private-Group-ID [20] L3 X 82 Tunnel-Assignment-ID [20] X X 83 Tunnel-Preference [20] 84 ARAP-Challenge-Response [6] 802.1X # Attribute Aboba & Moore Informational [Page 14]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 802.1X # Attribute X 85 Acct-Interim-Interval [6] X 86 Acct-Tunnel-Packets-Lost [21] X 87 NAS-Port-Id [6] 88 Framed-Pool [6] L3 X 90 Tunnel-Client-Auth-ID [20] L3 X 91 Tunnel-Server-Auth-ID [20] X TBD NAS-IPv6-Address [23] TBD Framed-Interface-Id [23] L3 X TBD Framed-IPv6-Prefix [23] TBD Login-IPv6-Host [23] L3 X TBD Framed-IPv6-Route [23] L3 X TBD Framed-IPv6-Pool [23] 802.1X Context # Attribute Key === 802.1X = Allowed for use with IEEE 802.1X Context = Transferred during roaming if available L3 = implemented only on switches/access points with Layer 3 capabilities Acknowledgments The authors would like to acknowledge Bob O'Hara of Informed Technology and Dave Bagby of 3Com for contributions to this document. Authors' Addresses Bernard Aboba Tim Moore Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: {bernarda, timmoore}@microsoft.com Phone: +1 425 882 8080 Fax: +1 425 936 7329 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any Aboba & Moore Informational [Page 15]
INTERNET-DRAFT A Model for IEEE 802.1X Context Transfer 11 July 2001 effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date This memo is filed as <draft-aboba-802-context-00.txt>, and expires January 16, 2002. Aboba & Moore Informational [Page 16]