Network Working Group Paul Congdon INTERNET-DRAFT Hewlett Packard Company Category: Informational Bernard Aboba <draft-congdon-radius-8021x-18.txt> Microsoft 30 April 2002 Andrew Smith Allegro Networks Glen Zorn Cisco Systems John Roese Enterasys IEEE 802.1X RADIUS Usage Guidelines This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 (2002). All Rights Reserved. Abstract IEEE 802.1X enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although RADIUS support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as RADIUS clients. This document provides suggestions on RADIUS usage by IEEE 802.1X Authenticators. An earlier version of this specification is included in a non-normative Appendix of the IEEE 802.1X specification. It is currently being revised within IEEE 802.1aa and is being presented to the IETF for informational purposes. Congdon, et al. Informational [Page 1]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 Table of Contents 1. Introduction .......................................... 4 1.1 Terminology ..................................... 4 1.2 Requirements language ........................... 5 2. RADIUS accounting attributes .......................... 5 2.1 Acct-Terminate-Cause ............................ 5 2.2. Acct-Multi-Session-Id ........................... 6 2.3. Acct-Link-Count ................................. 7 3. RADIUS authentication ................................. 8 3.1 User-Name ....................................... 8 3.2 User-Password, CHAP-Password, CHAP-Challenge .... 9 3.3 NAS-IP-Address, NAS-IPv6-Address ................ 9 3.4 NAS-Port ........................................ 9 3.5 Service-Type .................................... 9 3.6 Framed-Protocol ................................. 9 3.7 Framed-IP-Address, Framed-IP-Netmask ............ 10 3.8 Framed-Routing .................................. 10 3.9 Filter-ID ....................................... 10 3.10 Framed-MTU ...................................... 10 3.11 Framed-Compression .............................. 11 3.12 Displayable messages ............................ 11 3.13 Callback-Number, Callback-ID .................... 11 3.14 Framed-Route, Framed-IPv6-Route ................. 11 3.15 State, Class, Proxy-State ....................... 11 3.16 Vendor-Specific ................................. 11 3.17 Session-Timeout ................................. 12 3.18 Idle-Timeout .................................... 12 3.19 Termination-Action .............................. 12 3.20 Called-Station-Id ............................... 12 3.21 Calling-Station-Id .............................. 13 3.22 NAS-Identifier .................................. 13 3.23 NAS-Port-Type ................................... 13 3.24 Port-Limit ...................................... 13 3.25 Password-Retry .................................. 13 3.26 Connect-Info .................................... 13 3.27 EAP-Message ..................................... 13 3.28 Message-Authenticator ........................... 14 3.29 NAS-Port-Id ..................................... 14 3.30 Framed-Pool, Framed-IPv6-Pool ................... 14 3.31 Tunnel attributes ............................... 14 Congdon, et al. Informational [Page 2]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 4. RC4 EAPOL-Key descriptor .............................. 16 5. Security considerations ............................... 18 5.1 Packet modification or forgery .................. 18 5.2 Dictionary attacks .............................. 18 5.3 Known plaintext attacks ......................... 19 5.4 Replay .......................................... 20 5.5 Outcome mismatches .............................. 20 5.6 802.11 integration .............................. 21 5.7 Key management issues ........................... 21 6. IANA considerations ................................... 23 7. Normative references .................................. 23 8. Informative references ................................ 24 9. Table of Attributes ................................... 26 ACKNOWLEDGMENTS .............................................. 28 AUTHORS' ADDRESSES ........................................... 28 Intellectual Property Statement .............................. 29 Full Copyright Statement ..................................... 30 Congdon, et al. Informational [Page 3]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 1. Introduction IEEE 802.1X [IEEE8021X] provides "network port authentication" for IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring and 802.11 [IEEE80211] wireless LANS. IEEE 802.1X does not require use of a backend authentication server, and thus can be deployed with stand-alone switches or access points, as well as in centrally managed scenarios. In situations where it is desirable to centrally manage authentication, authorization and accounting (AAA) for IEEE 802 networks, deployment of a backend authentication and accounting server is desirable. In such situations, it is expected that IEEE 802.1X Authenticators will function as AAA clients. This document provides suggestions on RADIUS usage by IEEE 802.1X Authenticators. Support for any AAA protocol is optional for IEEE 802.1X Authenticators, and therefore this specification has been incorporated into a non-normative Appendix within the IEEE 802.1X specification. This document is currently being revised as part of the IEEE 802.1aa effort, and is being presented to the IETF for informational purposes. 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 Congdon, et al. Informational [Page 4]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 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 [RFC2119]. 2. RADIUS accounting attributes With a few exceptions, the RADIUS accounting attributes defined in [RFC2866] and [RFC2869] have the same meaning within IEEE 802.1X sessions as they do in dialup sessions and therefore no additional commentary is needed. Attributes requiring more discussion include: Acct-Terminate-Cause Acct-Multi-Session-Id Acct-Link-Count 2.1. Acct-Terminate-Cause This attribute indicates how the session was terminated, as described in [RFC2866]. [IEEE8021X] defines the following termination cause values, which are shown with their RADIUS equivalents in the following table: IEEE 802.1X RADIUS dot1xAuthSessionTerminateCause Acct-Terminate-Cause Value Value ------------- -------------------- SupplicantLogoff(1) User Request (1) portFailure(2) Lost Carrier (2) SupplicantRestart(3) Supplicant Restart (19) reauthFailed(4) Reauthentication Failure (20) authControlForceUnauth(5) Admin Reset (6) portReInit(6) Port Reinitialized (21) portAdminDisabled(7) Port Administratively Disabled (22) notTerminatedYet(999) N/A When using this attribute, the User Request (1) termination cause corresponds to the situation in which the session terminated due to an EAPOL-Logoff received from the Supplicant. When a session is moved due to roaming, the EAPOL state machines will treat this as a Supplicant Logoff. Congdon, et al. Informational [Page 5]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 A Lost Carrier (2) termination cause indicates session termination due to loss of physical connectivity for reasons other than roaming. For example, if the Supplicant disconnects a point-to-point LAN connection, or moves out of range of an 802.11 Access Point, this termination cause is used. Lost Carrier (2) therefore equates to a Port Disabled condition in the EAPOL state machines. A Supplicant Restart (19) termination cause indicates re-initialization of the Supplicant state machines. A Reauthentication Failure (20) termination cause indicates that a previously authenticated Supplicant has failed to re-authenticate successfully following expiry of the reauthentication timer or explicit reauthentication request by management action. Within [IEEE80211], periodic re-authentication may be useful in preventing reuse of an initialization vector with a given key. Since successful re-authentication does not result in termination of the session, accounting packets are not sent as a result of re- authentication unless the status of the session changes. For example: a. The session is terminated due to re-authentication failure. In this case the Reauthentication Failure (20) termination cause is used. b. The authorizations are changed as a result of a successful re- authentication. In this case, the Service Unavailable (15) termination cause is used. For accounting purposes, the portion of the session after the authorization change is treated as a separate session. Where IEEE 802.1X authentication occurs prior to 802.11 association, accounting packets are not sent until an association occurs. An Admin Reset(6) termination cause indicates that the Port has been administratively forced into the unauthorized state. A Port Reinitialized (21) termination cause indicates that the Port's MAC has been reinitialized. A Port Administratively Disabled (22) termination cause indicates that the Port has been administratively disabled. 2.2. Acct-Multi-Session-Id The purpose of this attribute is to make it possible to link together multiple related sessions. While IEEE 802.1X does not act on aggregated ports, it is possible for a Supplicant roaming between IEEE 802.11 Access Points to cause multiple RADIUS accounting packets to be sent by Congdon, et al. Informational [Page 6]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 different Access Points. Where supported by the Access Points, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant. In such a situation, if the session context is transferred between access points, accounting packets MAY be sent without a corresponding authentication and authorization exchange, provided that an association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points as part of the Inter-Access Point Protocol. If Acct-Multi-Session-Id were not unique between Access Points, then it is possible that the chosen Acct-Multi-Session-Id might overlap with an existing value allocated on that Access Point and the Accounting Server would therefore be unable to distinguish a roaming session from a multi- link session. As a result, the Acct-Multi-Session-Id attribute is unique among all the Access Points, Supplicants and sessions. In order to provide this uniqueness, it is suggested that the Acct-Multi-Session-Id be of the form: Original Access-Point MAC Address | Supplicant MAC Address | NTP Timestamp Here the original Access-Point MAC Address is the MAC address of the Access Point at which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct-Multi-Session-Id between 802.11 roaming sessions, the multi-session-id may be moved between Access Points as part of an inter-access point protocol. The use of Acct-Multi-Session-Id of this form guarantees uniqueness among all Access Points, Supplicants and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point could choose an Acct-Multi-Session-Id that could be confused with that of a previous session. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string of Hex digits. Example: "00-10-A4-23-19-C0 00-12-B2-14-23-DE AF2383C076B844E8" 2.3. Acct-Link-Count Since IEEE 802.1X does not act on aggregated ports, there is no equivalent to PPP multi-link bundles, and this attribute is not useful for IEEE 802.1X Authenticators. Congdon, et al. Informational [Page 7]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 3. RADIUS authentication The following attributes defined in [RFC2865],[RFC2866],[RFC2867],[RFC2868],[RFC2869] and [RFC3162] appear most relevant for use in IEEE 802.1X authentication: User-Name NAS-IP-Address, NAS-IPv6-Address NAS-Port Service-Type Framed-Routing Filter-Id Framed-MTU Reply-Message Framed-Route, Framed-IPv6-Route State Class Vendor-Specific Session-Timeout Idle-Timeout Termination-Action Called-Station-ID Calling-Station-ID NAS-Identifier Proxy-State NAS-Port-Type Password-Retry Connect-Info EAP-Message Message-Authenticator NAS-Port-Id Framed-Pool, Framed-IPv6-Pool Tunnel-attributes 3.1. User-Name In IEEE 802.1X, the Supplicant typically provides its identity via an EAP-Response/Identity message. Where available, the Supplicant identity is included in the User-Name attribute, and included in the RADIUS Access-Request and Access-Reply messages as specified in [RFC2865] and [RFC2869]. Alternatively, where Service-Type=Call Check, the User-Name attribute contains the Calling-Station-ID value, which is set to the Supplicant MAC address. Congdon, et al. Informational [Page 8]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 3.2. User-Password, CHAP-Password, CHAP-Challenge Since IEEE 802.1X does not support PAP or CHAP authentication, the User- Password, CHAP-Password or CHAP-Challenge attributes are not used by IEEE 802.1X Authenticators acting as RADIUS clients. 3.3. NAS-IP-Address, NAS-IPv6-Address For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4 address of the bridge or Access Point acting as an Authenticator, and the NAS- IPv6-Address contains the IPv6 address. If the IEEE 802.1X Authenticator has more than one interface, it may be desirable to use a loopback address for this purpose so that the Authenticator will still be reachable even if one of the interfaces were to fail. 3.4. NAS-Port For use with IEEE 802.1X the NAS-Port will contain the port number of the bridge, if this is available. While an 802.11 Access Point does not have physical ports, it does assign a unique "association ID" to every mobile station upon a successful association exchange. As a result, for an 802.11 Access Point, the NAS-Port attribute will contain the association ID, which is a 16-bit unsigned integer. Where IEEE 802.1X authentication occurs prior to association, the association ID may not yet be known, and so may not be included. 3.5. Service-Type For use with IEEE 802.1X, only the Framed (2), Authenticate Only (8), and Call Check (10) values have meaning. A Service-Type of Framed indicates that appropriate 802 framing should be used for the connection. A Service-Type of Authenticate Only (8) indicates that no authorization information needs to be returned in the Access-Accept. As described in [RFC2865], a Service-Type of Call Check is included in an Access-Request packet to request that the RADIUS server accept or reject the connection attempt, typically based on the Called-Station-ID (set to the bridge or Access Point MAC address) or Calling-Station-ID attributes (set to the Supplicant MAC address). As noted in [RFC2865] it is recommended that in this case the User-Name attribute be given the value of Calling-Station-Id. 3.6. Framed-Protocol Since there is no value for 802 media, the Framed-Protocol attribute is not used by IEEE 802.1X Authenticators. Congdon, et al. Informational [Page 9]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 3.7. Framed-IP-Address, Framed-IP-Netmask Since IEEE 802.1X does not provide a mechanism for IP address assignment, the Framed-IP-Address and Framed-IP-Netmask attributes are not used by IEEE 802.1X Authenticators. 3.8. Framed-Routing The Framed-Routing attribute indicates the routing method for the Supplicant. It is therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and cannot be used by a bridge or Access Point. 3.9. Filter-ID This attribute indicates the name of the filter list for the Supplicant. For use with an IEEE 802.1X Authenticator, it may be used to indicate either layer 2 or layer 3 filters. 3.10. Framed-MTU This attribute indicates the maximum size of an IP packet that may be transmitted over the wire between the Supplicant and the Authenticator. IEEE 802.1X Authenticators set this to the value corresponding to the relevant 802 medium, and include it in the RADIUS Access-Request. For EAP over IEEE 802 media, the Framed-MTU values (which do not include LLC/SNAP overhead) and maximum frame length values (not including the preamble) are as follows: Maximum Frame Media Framed-MTU Length ========= =============== ============== Ethernet 1500 1522 802.3 1500 1522 802.4 8174 8193 802.5 (4 Mbps) 4528 4550 802.5 (16 Mbps) 18173 18200 802.5 (100 Mb/s) 18173 18200 802.6 9191 9240 802.9a 1500 1518 802.11 2304 2346 802.12 (Ethernet) 1500 1518 802.12 (Token Ring) 4502 4528 FDDI 4479 4500 Congdon, et al. Informational [Page 10]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 3.11. Framed-Compression IEEE 802.1X does not include compression support so that this attribute is not understood by 802.1X Authenticators. 3.12. Displayable messages The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which MAY be displayed to the user. This is similar in purpose to the EAP-Request/Notification, defined in [RFC2284]. When replying to an IEEE 802.1X Authenticator, the RADIUS server SHOULD encapsulate displayable messages within EAP-Message/EAP- Request/Notification attribute(s), and SHOULD NOT use Reply-Message attribute(s) for this purpose. An IEEE 802.1X Authenticator receiving Reply-Message attribute(s) MAY copy the Text field(s) into the Type-Data field of an EAP-Request/Notification packet, fill in the Identifier field, and send this to the Peer. As a result, a RADIUS server sending Reply-Message attribute(s) to an IEEE 802.1X Authenticator MUST be prepared to receive an ensuing Access-Request with an EAP-Message/EAP- Response/Notification attribute containing an Identifier value that does not match that of the previous EAP-Message/EAP-Request. 3.13. Callback-Number, Callback-ID These attributes are not understood by IEEE 802.1X Authenticators. 3.14. Framed-Route, Framed-IPv6-Route The Framed-Route and Framed-IPv6-Route attributes provide routes that are to be configured for the Supplicant. These attributes are therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and cannot be understood by a bridge or Access Point. 3.15. State, Class, Proxy-State These attributes are used for the same purposes as described in [RFC2865]. 3.16. Vendor-Specific Vendor-specific attributes are used for the same purposes as described in [RFC2865]. The MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes, described in section 2.4 of [RFC2548], MAY be used to encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X, Section 7.6]. Details of the EAPOL-Key descriptor are provided in Section 4. Congdon, et al. Informational [Page 11]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 3.17. Session-Timeout When sent along in an Access-Accept without a Termination-Action attribute or with a Termination-Action attribute set to Default, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to session termination. When sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re-authentication. In this case, the Session-Timeout attribute is used to load the reAuthPeriod constant within the Reauthentication Timer state machine of 802.1X. When sent with a Termination-Action value of RADIUS-Request, a Session-Timeout value of zero indicates the desire to perform another authentication (possibly of a different type) immediately after the first authentication has successfully completed. As described in [RFC2869], when sent in an Access-Challenge, this attribute represents the maximum number of seconds that an IEEE 802.1X Authenticator should wait for an EAP-Response before retransmitting. In this case, the Session-Timeout attribute is used to load the suppTimeout constant within the Backend state machine of IEEE 802.1X. 3.18. Idle-Timeout The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802 media other than 802.11 the media are always on. As a result the Idle-Timeout attribute is typically only used with IEEE 802.11. It is possible for an 802.11 device to wander out of range of all access points. In this case, the Idle-Timeout attribute indicates the maximum time that an 802.11 device may remain idle. 3.19. Termination-Action This attribute indicates what action should be taken when the service is completed. The value RADIUS-Request(1) indicates that re-authentication should occur on expiration of the Session-Time. The value Default (0) indicates that the session should terminate. 3.20. Called-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the bridge or Access Point MAC address in ASCII format, with octet values separated by a "-". Example: "00-10-A4-23-19-C0". For 802.11 Access Points, where the 802.11 SSID is known during IEEE 802.1X authentication, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1". Note that since the SSID is included in the Congdon, et al. Informational [Page 12]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 association-request, where IEEE 802.1X authentication occurs prior to association, the selected SSID may not be known. 3.21. Calling-Station-Id For IEEE 802.1X Authenticators, this attribute is used to store the Supplicant MAC address in ASCII format, with octet values separated by a "-". Example: "00-10-A4-23-19-C0". 3.22. NAS-Identifier This attribute contains a string identifying the IEEE 802.1X Authenticator originating the Access-Request. 3.23. NAS-Port-Type For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15) Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be used. 3.24. Port-Limit This attribute has no meaning when sent to an IEEE 802.1X Authenticator. 3.25. Password-Retry In IEEE 802.1X, the Authenticator always transitions to the HELD state after an authentication failure. Thus this attribute does not make sense for IEEE 802.1X. 3.26. Connect-Info This attribute is sent by a bridge or Access Point to indicate the nature of the Supplicant's connection. When sent in the Access-Request it is recommended that this attribute contain information on the speed of the Supplicant's connection. For 802.11, the following format is recommended: "CONNECT 11Mbps 802.11b". If sent in the Accounting STOP, this attribute may be used to summarize statistics relating to session quality. For example, in IEEE 802.11, the Connect-Info attribute may contain information on the number of link layer retransmissions. The exact format of this attribute is implementation specific. 3.27. EAP-Message Since IEEE 802.1X provides for encapsulation of EAP as described in [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in [RFC2869] is used to encapsulate EAP packets for transmission from the IEEE 802.1X Authenticator to the Authentication Server. Congdon, et al. Informational [Page 13]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 3.28. Message-Authenticator As noted in [RFC2869], the Message-Authenticator attribute MUST be used to protect all packets containing an EAP-Message attribute. 3.29. NAS-Port-Id This attribute is used to identify the IEEE 802.1X Authenticator port which authenticates the Supplicant. The NAS-Port-Id differs from the NAS-Port in that it is a string of variable length whereas the NAS-Port is a 4 octet value. 3.30. Framed-Pool, Framed-IPv6-Pool Since IEEE 802.1X does not support address assignment, these attributes have no meaning to IEEE 802.1X Authenticators. 3.31. Tunnel attributes Reference [RFC2868] defines RADIUS tunnel attributes used for authentication and authorization, and [RFC2867] defines tunnel attributes used for accounting. Where the IEEE 802.1X Authenticator supports tunneling, a compulsory tunnel may be set up for the Supplicant as a result of the authentication. In particular, it may be desirable to allow a port to be placed into a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the result of the authentication. This can be used, for example, to allow a wireless host to remain on the same VLAN as it moves within a campus network. The RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept. However, the IEEE 802.1X Authenticator may also provide a hint as to the VLAN to be assigned to the Supplicant by including Tunnel attributes within the Access-Request. For use in VLAN assignment, the following tunnel attributes are sent: Tunnel-Type=VLAN (13) Tunnel-Medium-Type=802 Tunnel-Private-Group-ID=VLANID Note that the VLANID is 12-bits, taking a value between 0 and 4095, inclusive. Since the Tunnel-Private-Group-ID is of type String as defined in [RFC2868], for use with IEEE 802.1X, the VLANID is encoded as a string, rather than an integer. Congdon, et al. Informational [Page 14]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 When Tunnel attributes are sent, it is necessary to fill in the Tag field. As noted in [RFC2868], section 3.1: The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00). For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel- Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or Tunnel- Server-Auth-ID attributes (but not Tunnel-Type, Tunnel-Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of greater than 0x1F is interpreted as the first octet of the following field. Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X Authenticators that may support tunneling but not VLANs), it is only necessary for tunnel attributes to specify a single tunnel. As a result where it is only desired to specify the VLANID, the tag field SHOULD be set to zero (0x00) in all Tunnel attributes. Where alternative tunnel types are to be provided, tag values between 0x01 and 0x1F SHOULD be chosen. Congdon, et al. Informational [Page 15]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 4. RC4 EAPOL-Key descriptor The RC4 EAPOL-Key descriptor is defined 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Packet Type | Packet Body Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Key Length |Replay Counter... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Counter... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Counter | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... |F| Key Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The Version field is one octet. For [IEEE8021X] it contains the value 0x01. Packet Type The Packet Type field is one octet, and determines the type of packet being transmitted. For an EAPOL-Key Descriptor, the Packet Type field contains 0x03. Packet Body Length The Packet Body Length is two octets, and contains the length of the EAPOL-Key descriptor in octets, not including the Version, Packet Congdon, et al. Informational [Page 16]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 Type and Packet Body Length fields. Type The Type field is a single octet. The Key descriptor is defined differently for each Type; this specification documents only the RC4 Key Descriptor (Type = 0x01). Key Length The Key Length field is two octets. If Packet Body Length = 44 + Key Length, then the Key Field contains the key in encrypted form, of length Key Length. This is 5 octets (40 bits) for WEP, and 13 octets (104 bits) for WEP-128. If Packet Body Length = 44, then the Key field is absent, and Key Length represents the number of least significant octets from the MS-MPPE-Send-Key attribute to be used as the keying material. Replay Counter The Replay Counter field is 8 octets. It does not repeat within the life of the keying material used to encrypt the Key field and compute the Key Signature field. A 64-bit NTP timestamp MAY be used as the Replay Counter. Key IV The Key IV field is 16 octets and includes a 128-bit cryptographically random number. F The Key flag (F) is a single bit, describing the type of key that is included in the Key field. Values are: 0 = for broadcast (default key) 1 = for unicast (key mapping key) Key Index The Key Index is 7 bits. Key Signature The Key Signature field is 16 octets. It contains an HMAC-MD5 message integrity check computed over the EAPOL-Key descriptor, starting from the Type field (e.g. skipping the Version, Packet Type and Packet Body Length fields) with the Key field filled in if present, but with Congdon, et al. Informational [Page 17]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 the Key Signature field set to zero. For the computation, the 32 octet (256 bit) MS-MPPE-Send-Key is used as the HMAC-MD5 key. Key If Packet Body Length = 44 + Key Length, then the Key Field contains the key in encrypted form, of length Key Length. If Packet Body Length = 44, then the Key field is absent, and the least significant Key Length octets from the MS-MPPE-Send-Key attribute is used as the keying material. Where the Key field is encrypted using RC4, the RC4 encryption key used to encrypt this field is formed by concatenating the 16 octet (128 bit) Key-IV field with the 32 octet MS-MPPE-Recv- Key attribute. This yields a 48 octet RC4 key (384 bits). 5. Security considerations Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802.1X-enabled networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC2865], and [RFC2869]. Vulnerabilities include: Packet modification or forgery Dictionary attacks Known plaintext attacks Replay Outcome mismatches 802.11 integration Key management issues 5.1. Packet modification or forgery RADIUS, defined in [RFC2865], does not require Access-Requests to be authenticated or integrity protected. However, IEEE 802.1X is based on EAP and does not support PAP or CHAP authentication. As a result, when used with IEEE 802.1X, all RADIUS packets are authenticated and integrity protected. As described in [RFC2869]: The Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute. 5.2. Dictionary attacks The RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response Authenticator or Message-Authenticator Congdon, et al. Informational [Page 18]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 attribute. As noted in [RFC2865]: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- chosen password. It is preferred that the secret be at least 16 octets. The risk of shared secret compromise can be mitigated in part by employing IPsec ESP with non-null transform in order to encrypt the RADIUS conversation, as described in [RFC3162]. 5.3. Known plaintext attacks Since IEEE 802.1X is based on EAP and does not support PAP or CHAP authentication, the RADIUS User-Password hiding mechanism is not utilized to hide user passwords. This mechanism uses MD5, defined in [RFC1321]; as noted in [MD5Attack], there are doubts about the security of this mechanism. Even though IEEE 802.1X Authenticators do not support User-Password hiding, a security vulnerability can still exist where the same RADIUS shared secret is used on an IEEE 802.1X Authenticator and a NAS supporting PAP. The threat can be mitigated by protecting RADIUS with IPsec ESP with non-null transform, as described in [RFC3162]. The RADIUS User-Password hiding mechanism uses MD5, defined in [RFC1321], in order to generate a key stream based on the RADIUS Shared secret and Request Authenticator. Where PAP is in use, it is possible to collect key streams corresponding to a given Request Authenticator value, by capturing RADIUS conversations corresponding to a PAP authentication attempt using a known password. If the Request Authenticator repeats, attributes hidden with the resulting key stream should be considered compromised, since the keystream may be known by an attacker. Hidden attributes such as the Tunnel-Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes [RFC2548, section 2.4], include a Salt field as part of the hiding algorithm. However, where the same RADIUS shared secret is used on IEEE 802.1X Authenticators and NASes supporting PAP, and where the Request Authenticator repeats, the Salt does not provide additional protection. This is because MD5 [RFC1321], rather than HMAC-MD5 [RFC2104], is used to generate the key stream, calculated from the 128-bit RADIUS shared secret (S), the 128-bit Request Authenticator (R), and the Salt field (A), via the formula b(1) = MD5(S + R + A). Since the Salt field is placed at the end, if the Request Authenticator were to repeat on a network where PAP is in use, then the salted keystream could be calculated from the User-Password keystream by continuing the MD5 Congdon, et al. Informational [Page 19]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 calculation based on the Salt field (A) which is sent in the clear. To protect against this, [RFC2865] recommends that: Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness. 5.4. Replay The RADIUS protocol provides only limited support for replay protection. Replay protection for both RADIUS authentication and accounting exchanges can be provided by using IPsec replay protection with RADIUS, as described in [RFC3162]. RADIUS Access-Requests include liveness via the 128-bit Request Authenticator. However, the Request Authenticator is not a replay counter. Since RADIUS servers may not maintain a cache of previous Request Authenticators, the Request Authenticator does not provide replay protection. Since the Accounting Response Authenticator depends in part on the Accounting Request Authenticator, it is not possible to replay an Accounting-Response unless the Request Authenticator repeats. While it is possible to utilize EAP methods such as EAP TLS [RFC2716] which include liveness checks on both sides, not all EAP messages will include liveness so that this provides incomplete protection. RADIUS accounting [RFC2866] does not support liveness or replay protection within the protocol. Due to the need to support failover between RADIUS accounting servers, protocol-based replay protection is not sufficient to prevent duplicate accounting records. However, once accepted by the accounting server, duplicate accounting records can be detected by use of the the Acct-Session-Id [RFC2866, section 5.5] and Event-Timestamp [RFC2869, section 5.3] attributes. Unlike RADIUS authentication, RADIUS accounting does not use the Request Authenticator as a nonce. Instead, the Acct-Session-Id [RFC2866, section 5.5] and Event-Timestamp [RFC2869, section 5.3] attributes provide liveness. As with the Request Authenticator, it is best if the Acct- Session-Id is globally and temporally unique, to protect against reuse of RADIUS shared secrets by multiple NASes. 5.5. Outcome mismatches [RFC2869] does not require that the EAP packet encapsulated in an EAP- Message attribute agree with the outcome of the authentication, or even that an EAP-Message attribute be included in an Access-Accept or Access- Reject. For example, an EAP-Success can be encapsulated in an Access- Reject, or an EAP-Failure can be encapsulated within an Access-Accept. Congdon, et al. Informational [Page 20]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 Neither message should be encapsulated in an Access-Challenge because as described in [RFC2284], EAP-Success and EAP-Failure messages are not ACK'd. Since an Access-Challenge indicates a continuing EAP conversation and no client response is expected to these messages, encapsulating these messages within an Access-Challenge would constitute a contradiction. To address the possible corner conditions and ensure that access decisions made by IEEE 802.1X Authenticators conform to the wishes of the RADIUS server, it is necessary for the Authenticator to make the decision solely based on the authentication result (Accept/Reject) and NOT based on the contents of the EAP packet encapsulated in one or more EAP-Message attributes, if one is present at all. 5.6. 802.11 integration [IEEE8021X] was developed for use on wired IEEE 802 networks such as Ethernet, and therefore does not describe how to securely adapt IEEE 802.1X for use with 802.11. This is left to the enhanced security specification under development within IEEE 802.11. For example, [IEEE8021X] does not specify whether authentication occurs prior to, or after, association, nor how the derived keys can be used to integrity protect management frames. It also does not specify ciphersuites addressing the vulnerabilities discovered in WEP, described in [Berkeley], [Arbaugh], and [Fluhrer]. [IEEE8021X] only defines an authentication framework, leaving the definition of the authentication methods to other documents. Since [IEEE8021X] does not address 802.11 security vulnerabilities, implementors are strongly advised to consult the IEEE 802.11 enhanced security specification for guidance on how to adapt IEEE 802.1X for use with 802.11. For example, it is likely that the IEEE 802.11 enhanced security specification will define an IEEE 802.11 key hierarchy as well as defining its own EAPOL-Key descriptors. 5.7. Key management issues The EAPOL-Key descriptor described in section 4 is likely to be deprecated in the future, when the 802.11 enhanced security group completes its work. It has inherent security issues when applied to 802.11 networks, and MUST NOT be used on 802.11 networks desiring enhanced security (e.g. networks implementing ciphers other than WEP). Problems include: [1] Support for key-mapping keys. IEEE 802.1X enables the derivation of per-station unicast keys, known in [IEEE80211] as "key mapping keys." Keys used to encrypt multicast/broadcast traffic are known Congdon, et al. Informational [Page 21]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 as "default keys". However, in some 802.11 implementations, the unicast keys derived as part of the EAP authentication process are used solely in order to encrypt, authenticate and integrity protect the EAPOL-Key descriptor, as described in Section 4. These implementations only support use of default keys (ordinarily only used with multicast/broadcast traffic) to secure all traffic, unicast or multicast/broadcast. Such implementations are inherently defective from a security point of view. Since there is no support for per-station key-mapping keys (e.g. unicast keys), any station possessing the default key can decrypt traffic from other stations or impersonate them. When used with a defective cipher (e.g. WEP), default key-only implementations provide more material for an attacker. Where the default key is not refreshed periodically, the implementation is susceptible to all the vulnerabilities inherent in the defective cipher. For an understanding of the issues with WEP, see [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl]. [2] Reuse of keying material. When utilized to provide keying material for the WEP ciphersuite, the same keying material (MS-MPPE-Recv- Key) is used both to encrypt the Key field within the EAPOL-Key descriptor, as well as to encrypt data passed between the station and access point using WEP. Multi-purpose keying material is frowned upon, since multiple uses can leak information helpful to an attacker. [3] WEP vulnerabilities. The algorithm used to encrypt the Key field within the EAPOL-Key descriptor is similar to the algorithm used in WEP, and therefore shares many of the same vulnerabilities. For example, the IV and key are concatenated rather than being combined within a mixing function, thereby making it much easier to obtain the key. Also, as with WEP, the IV is not a counter, and therefore there is no protection against reuse of the same IV value, thereby compromising the key stream. As a result of these vulnerabilities, implementors intending to use the EAPOL-Key descriptor described in this document are urged to consult the 802.11 enhanced security specification for a more secure alternative. It is also advisable to consult the evolving literature on WEP vulnerabilities, in order to better understand the risks, as well as to obtain guidance on setting an appropriate re-keying interval. Congdon, et al. Informational [Page 22]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 6. IANA Considerations This specification does not create any RADIUS attributes nor any new number spaces for IANA administration. However, it does require assignment of new values to existing RADIUS attributes. These include: Attribute Values Required ========= =============== NAS-Port-Type Token-Ring (20), FDDI (21) Tunnel-Type VLAN (13) Acct-Terminate-Cause Supplicant Restart (19) Reauthentication Failure (20) Port Reinitialized (21) Port Administratively Disabled (22) 7. Normative references [RFC1321] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [RFC2865] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2867] Zorn, G., Mitton, D., Aboba, B., "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G., Mitton, D.,"RADIUS and IPv6", RFC 3162, August 2001. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, Congdon, et al. Informational [Page 23]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 June 2001. 8. Informative references [RFC2104] Krawczyk, H., Bellare, M., Canetti, R.,"HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998. [IEEE8023] 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. [IEEE80211] 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-1999, 1999. [Berkeley] Borisov, N., Goldberg, I., Wagner, D., "Intercepting Mobile Communications: The Insecurity of 802.11", ACM SIGMOBILE, Seventh Annual International Conference on Mobile Computing and Networking, July 2001, Rome, Italy. Congdon, et al. Informational [Page 24]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 [Arbaugh] Arbaugh, W., Shankar, N., Wan, J.Y.C., "Your 802.11 Wireless Network has No Clothes", Department of Computer Science, University of Maryland, College Park, March 2001. [Fluhrer] Fluhrer, S., Mantin, I., Shamir, A., "Weaknesses in the Key Scheduling Algorithm of RC4", Eighth Annual Workshop on Selected Areas in Cryptography, Toronto, Canada, August 2001. [Stubbl] Stubblefield, A., Ioannidis, J., Rubin, A., "Using the Fluhrer, Mantin and Shamir Attack to Break WEP", 2002 NDSS Conference. Congdon, et al. Informational [Page 25]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 9. Table of Attributes The following table provides a guide to which attributes MAY be sent and received as part of IEEE 802.1X authentication. L3 denotes attributes that will be understood only by Authenticators implementing Layer 3 capabilities. For each attribute, the reference provides the definitive information on usage. 802.1X # Attribute X 1 User-Name [RFC2865] 2 User-Password [RFC2865] 3 CHAP-Password [RFC2865] X 4 NAS-IP-Address [RFC2865] X 5 NAS-Port [RFC2865] X 6 Service-Type [RFC2865] 7 Framed-Protocol [RFC2865] 8 Framed-IP-Address [RFC2865] 9 Framed-IP-Netmask [RFC2865] L3 10 Framed-Routing [RFC2865] X 11 Filter-Id [RFC2865] X 12 Framed-MTU [RFC2865] 13 Framed-Compression [RFC2865] L3 14 Login-IP-Host [RFC2865] L3 15 Login-Service [RFC2865] L3 16 Login-TCP-Port [RFC2865] ? 18 Reply-Message [RFC2865] 19 Callback-Number [RFC2865] 20 Callback-Id [RFC2865] L3 22 Framed-Route [RFC2865] L3 23 Framed-IPX-Network [RFC2865] X 24 State [RFC2865] X 25 Class [RFC2865] X 26 Vendor-Specific [RFC2865] X 27 Session-Timeout [RFC2865] X 28 Idle-Timeout [RFC2865] X 29 Termination-Action [RFC2865] X 30 Called-Station-Id [RFC2865] X 31 Calling-Station-Id [RFC2865] X 32 NAS-Identifier [RFC2865] X 33 Proxy-State [RFC2865] 34 Login-LAT-Service [RFC2865] 35 Login-LAT-Node [RFC2865] 36 Login-LAT-Group [RFC2865] 802.1X # Attribute Congdon, et al. Informational [Page 26]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 802.1X # Attribute L3 37 Framed-AppleTalk-Link [RFC2865] L3 38 Framed-AppleTalk-Network [RFC2865] L3 39 Framed-AppleTalk-Zone [RFC2865] X 40 Acct-Status-Type [RFC2866] X 41 Acct-Delay-Time [RFC2866] X 42 Acct-Input-Octets [RFC2866] X 43 Acct-Output-Octets [RFC2866] X 44 Acct-Session-Id [RFC2866] X 45 Acct-Authentic [RFC2866] X 46 Acct-Session-Time [RFC2866] X 47 Acct-Input-Packets [RFC2866] X 48 Acct-Output-Packets [RFC2866] X 49 Acct-Terminate-Cause [RFC2866] X 50 Acct-Multi-Session-Id [RFC2866] 51 Acct-Link-Count [RFC2866] X 52 Acct-Input-Gigawords [RFC2869] X 53 Acct-Output-Gigawords [RFC2869] X 55 Event-Timestamp [RFC2869] 60 CHAP-Challenge [RFC2865] X 61 NAS-Port-Type [RFC2865] 62 Port-Limit [RFC2865] 63 Login-LAT-Port [RFC2865] X 64 Tunnel-Type [RFC2868] X 65 Tunnel-Medium-Type [RFC2868] L3 66 Tunnel-Client-Endpoint [RFC2868] L3 67 Tunnel-Server-Endpoint [RFC2868] L3 68 Acct-Tunnel-Connection [RFC2867] L3 69 Tunnel-Password [RFC2868] 70 ARAP-Password [RFC2869] 71 ARAP-Features [RFC2869] 72 ARAP-Zone-Access [RFC2869] 73 ARAP-Security [RFC2869] 74 ARAP-Security-Data [RFC2869] 75 Password-Retry [RFC2869] 76 Prompt [RFC2869] X 77 Connect-Info [RFC2869] X 78 Configuration-Token [RFC2869] X 79 EAP-Message [RFC2869] X 80 Message-Authenticator [RFC2869] X 81 Tunnel-Private-Group-ID [RFC2868] L3 82 Tunnel-Assignment-ID [RFC2868] X 83 Tunnel-Preference [RFC2868] 84 ARAP-Challenge-Response [RFC2869] 802.1X # Attribute Congdon, et al. Informational [Page 27]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 802.1X # Attribute X 85 Acct-Interim-Interval [RFC2869] X 86 Acct-Tunnel-Packets-Lost [RFC2867] X 87 NAS-Port-Id [RFC2869] 88 Framed-Pool [RFC2869] L3 90 Tunnel-Client-Auth-ID [RFC2868] L3 91 Tunnel-Server-Auth-ID [RFC2868] X 95 NAS-IPv6-Address [RFC3162] 96 Framed-Interface-Id [RFC3162] L3 97 Framed-IPv6-Prefix [RFC3162] L3 98 Login-IPv6-Host [RFC3162] L3 99 Framed-IPv6-Route [RFC3162] L3 100 Framed-IPv6-Pool [RFC3162] 802.1X # Attribute Key === X = May be used with IEEE 802.1X authentication ? = Deprecated in favor of EAP-Message/EAP-Request/Notification L3 = Implemented only by Authenticators with Layer 3 capabilities Acknowledgments The authors would like to acknowledge Bob O'Hara of Informed Technology, David Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for contributions to this document. Authors' Addresses Paul Congdon Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 Phone: +1 916 785 5753 Fax: +1 916 785 8478 EMail: paul_congdon@hp.com Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Congdon, et al. Informational [Page 28]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 Phone: +1 425 706 6605 Fax: +1 425 706 7329 Andrew Smith Allegro Networks 6399 San Ignacio Ave. San Jose, CA 95119 Fax: +1 415 345 1827 EMail: andrew@allegronetworks.com John Roese Enterasys EMail: jjr@enterasys.com Phone: +1 603 337 1506 Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 Phone: +1 425 438 8218 Fax: +1 425 438 1848 EMail: gwz@cisco.com 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 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. Congdon, et al. Informational [Page 29]
INTERNET-DRAFT IEEE 802.1X RADIUS Usage Guidelines 30 April 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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-congdon-radius-8021x-18.txt>, and expires November 22, 2002. Congdon, et al. Informational [Page 30]