diff options
Diffstat (limited to 'rfc/rfc3580.txt')
| -rw-r--r-- | rfc/rfc3580.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/rfc/rfc3580.txt b/rfc/rfc3580.txt new file mode 100644 index 00000000..b87235cf --- /dev/null +++ b/rfc/rfc3580.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group P. Congdon +Request for Comments: 3580 Hewlett Packard Company +Category: Informational B. Aboba + Microsoft + A. Smith + Trapeze Networks + G. Zorn + Cisco Systems + J. Roese + Enterasys + September 2003 + + + IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) + Usage Guidelines + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document provides suggestions on Remote Authentication Dial In + User Service (RADIUS) usage by IEEE 802.1X Authenticators. The + material in this document is also included within a non-normative + Appendix within the IEEE 802.1X specification, and is being presented + as an IETF RFC for informational purposes. + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 1] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements Language. . . . . . . . . . . . . . . . . . 4 + 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. . . . . . . . . . . . . . . . . . . . . 7 + 3.1. User-Name. . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. User-Password, CHAP-Password, CHAP-Challenge . . . . . . 8 + 3.3. NAS-IP-Address, NAS-IPv6-Address . . . . . . . . . . . . 8 + 3.4. NAS-Port . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5. Service-Type . . . . . . . . . . . . . . . . . . . . . . 8 + 3.6. Framed-Protocol. . . . . . . . . . . . . . . . . . . . . 9 + 3.7. Framed-IP-Address, Framed-IP-Netmask . . . . . . . . . . 9 + 3.8. Framed-Routing . . . . . . . . . . . . . . . . . . . . . 9 + 3.9. Filter-ID. . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.10. Framed-MTU . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.11. Framed-Compression . . . . . . . . . . . . . . . . . . . 10 + 3.12. Displayable Messages . . . . . . . . . . . . . . . . . . 10 + 3.13. Callback-Number, Callback-ID . . . . . . . . . . . . . . 10 + 3.14. Framed-Route, Framed-IPv6-Route. . . . . . . . . . . . . 11 + 3.15. State, Class, Proxy-State. . . . . . . . . . . . . . . . 11 + 3.16. Vendor-Specific. . . . . . . . . . . . . . . . . . . . . 11 + 3.17. Session-Timeout. . . . . . . . . . . . . . . . . . . . . 11 + 3.18. Idle-Timeout . . . . . . . . . . . . . . . . . . . . . . 12 + 3.19. Termination-Action . . . . . . . . . . . . . . . . . . . 12 + 3.20. Called-Station-Id. . . . . . . . . . . . . . . . . . . . 12 + 3.21. Calling-Station-Id . . . . . . . . . . . . . . . . . . . 12 + 3.22. NAS-Identifier . . . . . . . . . . . . . . . . . . . . . 12 + 3.23. NAS-Port-Type. . . . . . . . . . . . . . . . . . . . . . 12 + 3.24. Port-Limit . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.25. Password-Retry . . . . . . . . . . . . . . . . . . . . . 13 + 3.26. Connect-Info . . . . . . . . . . . . . . . . . . . . . . 13 + 3.27. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 13 + 3.28. Message-Authenticator. . . . . . . . . . . . . . . . . . 13 + 3.29. NAS-Port-Id. . . . . . . . . . . . . . . . . . . . . . . 13 + 3.30. Framed-Pool, Framed-IPv6-Pool. . . . . . . . . . . . . . 14 + 3.31. Tunnel Attributes. . . . . . . . . . . . . . . . . . . . 14 + 4. RC4 EAPOL-Key Descriptor . . . . . . . . . . . . . . . . . . . 15 + 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 + 5.1. Packet Modification or Forgery . . . . . . . . . . . . . 18 + 5.2. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 19 + 5.3. Known Plaintext Attacks. . . . . . . . . . . . . . . . . 19 + 5.4. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 5.5. Outcome Mismatches . . . . . . . . . . . . . . . . . . . 20 + + + +Congdon, et al. Informational [Page 2] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 5.6. 802.11 Integration . . . . . . . . . . . . . . . . . . . 20 + 5.7. Key Management Issues. . . . . . . . . . . . . . . . . . 21 + 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 + 7.2. Informative References . . . . . . . . . . . . . . . . . 23 + 8. Table of Attributes. . . . . . . . . . . . . . . . . . . . . . 25 + 9. Intellectual Property Statement . . . . . . . . . . . . . . . 28 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 + 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 + +1. Introduction + + IEEE 802.1X enables authenticated access to IEEE 802 media, including + Ethernet, Token Ring, and 802.11 wireless LANs. Although Remote + Authentication Dial In User Service (RADIUS) support is optional + within IEEE 802.1X, it is expected that many IEEE 802.1X + Authenticators will function as RADIUS clients. + + 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 bridges 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. + +1.1. Terminology + + This document uses the following terms: + + Access Point (AP) + A Station that provides access to the distribution services via + the wireless medium for associated Stations. + + + + +Congdon, et al. Informational [Page 3] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + Association + The service used to establish Access Point/Station mapping and + enable Station invocation of the distribution system services. + + Authenticator + An Authenticator is an entity that requires 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. + + Station (STA) + Any device that contains an IEEE 802.11 conformant medium + access control (MAC) and physical layer (PHY) interface to the + wireless medium (WM). + + 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, several words are used to signify the requirements + of the specification. These words are often capitalized. The key + words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in [RFC2119]. + + + + + + + + + + + +Congdon, et al. Informational [Page 4] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +2. RADIUS Accounting Attributes + + With a few exceptions, the RADIUS accounting attributes defined in + [RFC2866], [RFC2867], 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 table on + the next page. + + 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. + + A Lost Carrier (2) termination cause indicates session termination + due to loss of physical connectivity for reasons other than roaming + between Access Points. For example, if the Supplicant disconnects a + point-to-point LAN connection, or moves out of range of an 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. + + + +Congdon, et al. Informational [Page 5] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + A Reauthentication Failure (20) termination cause indicates that a + previously authenticated Supplicant has failed to re-authenticate + successfully following expiry of the re-authentication timer or + explicit re-authentication 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 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 [IEEE8021X] does not act on + aggregated ports, it is possible for a Supplicant roaming between + Access Points to cause multiple RADIUS accounting packets to be sent + by 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, + + + + +Congdon, et al. Informational [Page 6] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + provided that 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 (IAPP). + + If the Acct-Multi-Session-Id were not unique between Access Points, + then it is possible that the chosen Acct-Multi-Session-Id will + 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 bridges or 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 AP MAC Address | Supplicant MAC Address | NTP Timestamp + + Here "|" represents concatenation, the original AP MAC Address is the + MAC address of the bridge or 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 roaming sessions, the Acct-Multi-Session-Id + may be moved between Access Points as part of IAPP or another handoff + scheme. + + The use of an 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-AF-23-83-C0-76-B8-44-E8" + +2.3. Acct-Link-Count + + The Acct-Link-Count attribute may be used to account for the number + of ports that have been aggregated. + +3. RADIUS Authentication + + This section describes how attributes defined in [RFC2865], + [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in + IEEE 802.1X authentication. + + + + + +Congdon, et al. Informational [Page 7] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +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 [RFC3579]. + + Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name + attribute may contain the Calling-Station-ID value, which is set to + the Supplicant MAC address. + +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 Access Point does not + have physical ports, a unique "association ID" is assigned to every + mobile Station upon a successful association exchange. As a result, + for an Access Point, if the association exchange has been completed + prior to authentication, 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, a unique NAS-Port + value may not be available. + +3.5. Service-Type + + For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and + Call Check (10) values are most commonly used. + + 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 + + + +Congdon, et al. Informational [Page 8] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 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 IEEE 802 media, the Framed-Protocol + attribute is not used by IEEE 802.1X Authenticators. + +3.7. Framed-IP-Address, Framed-IP-Netmask + + IEEE 802.1X does not provide a mechanism for IP address assignment. + Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can + only be used by IEEE 802.1X Authenticators that support IP address + assignment mechanisms. Typically this capability is supported by + layer 3 devices. + +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 to be applied to + the Supplicant's session. For use with an IEEE 802.1X Authenticator, + it may be used to indicate either layer 2 or layer 3 filters. Layer + 3 filters are typically only supported on IEEE 802.1X Authenticators + that act as layer 3 devices. + +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. The RADIUS server may send an EAP packet as + large as Framed-MTU minus four (4) octets, taking into account the + additional overhead for the IEEE 802.1X Version (1), Type (1) and + Body Length (2) fields. 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: + + + +Congdon, et al. Informational [Page 9] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 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 + + NOTE - the Framed-MTU size for IEEE 802.11 media may change as a + result of ongoing work being undertaken in the IEEE 802.11 Working + Group. Since some 802.11 stations cannot handle an MTU larger than + 1500 octets, it is recommended that RADIUS servers encountering a + NAS-Port-Type value of 802.11 send EAP packets no larger than 1496 + octets. + +3.11. Framed-Compression + + [IEEE8021X] does not include compression support. Therefore this + attribute is not understood by [IEEE8021X] 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 concept to the EAP Notification Type, defined in [RFC2284]. As + noted in [RFC3579], Section 2.6.5, when sending a displayable message + to an [IEEE8021X] Authenticator, displayable messages are best sent + within EAP-Message/EAP-Request/Notification attribute(s), and not + within Reply-Message attribute(s). + +3.13. Callback-Number, Callback-ID + + These attributes are not understood by IEEE 802.1X Authenticators. + + + + + + + + + + +Congdon, et al. Informational [Page 10] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +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]. Examples of the derivation of the MS-MPPE-Send-Key and + MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP + method are given in [RFC2716]. Details of the EAPOL-Key descriptor + are provided in Section 4. + +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. + + 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. + + + + +Congdon, et al. Informational [Page 11] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +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 wireless media + such as IEEE 802.11. It is possible for a wireless device to wander + out of range of all Access Points. In this case, the Idle-Timeout + attribute indicates the maximum time that a wireless 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 (upper case only), + with octet values separated by a "-". Example: "00-10-A4-23-19-C0". + In IEEE 802.11, where the SSID is known, 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". + +3.21. Calling-Station-Id + + For IEEE 802.1X Authenticators, this attribute is used to store the + Supplicant MAC address in ASCII format (upper case only), 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. + + + + + + + + + +Congdon, et al. Informational [Page 12] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.24. Port-Limit + + This attribute has no meaning when sent to an [IEEE8021X] + 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 + [RFC3579] is used to encapsulate EAP packets for transmission from + the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579] + Section 2.2. describes how the Authentication Server handles invalid + EAP packets passed to it by the Authenticator. + +3.28. Message-Authenticator + + As noted in [RFC3579] Section 3.1., the Message-Authenticator + attribute MUST be used to protect packets within a RADIUS/EAP + conversation. + +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. + + + + + + +Congdon, et al. Informational [Page 13] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +3.30. Framed-Pool, Framed-IPv6-Pool + + IEEE 802.1X does not provide a mechanism for IP address assignment. + Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be + used by IEEE 802.1X Authenticators that support IP address assignment + mechanisms. Typically this capability is supported by layer 3 + devices. + +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 used: + + Tunnel-Type=VLAN (13) + Tunnel-Medium-Type=802 + Tunnel-Private-Group-ID=VLANID + + Note that the VLANID is 12-bits, taking a value between 1 and 4094, + inclusive. Since the Tunnel-Private-Group-ID is of type String as + defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer + value is encoded as a string. + + 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). + + + + + +Congdon, et al. Informational [Page 14] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 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. + +4. RC4 EAPOL-Key Frame + + The RC4 EAPOL-Key frame is created and transmitted by the + Authenticator in order to provide media specific key information. + For example, within 802.11 the RC4 EAPOL-Key frame can be used to + distribute multicast/broadcast ("default") keys, or unicast ("key + mapping") keys. The "default" key is the same for all Stations + within a broadcast domain. + + The RC4 EAPOL-Key frame is not acknowledged and therefore the + Authenticator does not know whether the Supplicant has received it. + If it is lost, then the Supplicant and Authenticator will not have + the same keying material, and communication will fail. If this + occurs, the problem is typically addressed by re-running the + authentication. + + The RC4 EAPOL-Key frame is sent from the Authenticator to the + Supplicant in order to provision the "default" key, and subsequently + in order to refresh the "default" key. It may also be used to + refresh the key-mapping key. Rekey is typically only required with + weak ciphersuites such as WEP, defined in [IEEE80211]. + + Where keys are required, an EAP method that derives keys is typically + selected. Therefore the initial "key mapping" keys can be derived + from EAP keying material, without requiring the Authenticator to send + an RC4 EAPOL-Key frame to the Supplicant. An example of how EAP + keying material can be derived and used is presented in [RFC2716]. + + + + + + + + + +Congdon, et al. Informational [Page 15] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more + complete description is provided on the next page. + + 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 IEEE 802.1X, 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 Type and Packet Body Length fields. + + + + + +Congdon, et al. Informational [Page 16] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 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 + [RFC2548] to be used as the keying material. Note that the MS- + MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the + point of view of the Authenticator. From the Supplicant point of + reference, the terms are reversed. Thus the MS-MPPE-Recv-Key on + the Supplicant corresponds to the MS-MPPE-Send-Key on the + Authenticator, and the MS-MPPE-Send-Key on the Supplicant + corresponds to the MS-MPPE-Recv-Key on the Authenticator. + + 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 Version field, with the Key field filled in if + present, but with the Key Signature field set to zero. For the + computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is + used as the HMAC-MD5 key. + + + + +Congdon, et al. Informational [Page 17] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 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], [RFC3162], [RFC3579], and [RFC3576]. + + 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 all Access-Requests to + be authenticated or integrity protected. However, IEEE 802.1X is + based on EAP. As described in [3579], Section 3.1.: + + 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. + + As a result, when used with IEEE 802.1X, all RADIUS packets MUST be + authenticated and integrity protected. In addition, as described in + [3579], Section 4.2.: + + To address the security vulnerabilities of RADIUS/EAP, + implementations of this specification SHOULD support IPsec + [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP + [RFC2406] with non-null transform SHOULD be supported, and IPsec + ESP with a non-null encryption transform and authentication + + + +Congdon, et al. Informational [Page 18] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + support SHOULD be used to provide per-packet confidentiality, + authentication, integrity and replay protection. IKE SHOULD be + used for key management. + +5.2. Dictionary Attacks + + As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is + vulnerable to offline dictionary attack, based on capture of the + Response Authenticator or Message-Authenticator attribute. In order + to decrease the level of vulnerability, [RFC2865], Section 3 + recommends: + + 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. + + In addition, the risk of an offline dictionary attack can be further + mitigated by employing IPsec ESP with a non-null transform in order + to encrypt the RADIUS conversation, as described in [RFC3579], + Section 4.2. + +5.3. Known Plaintext Attacks + + Since IEEE 802.1X is based on EAP, which does not support PAP, the + RADIUS User-Password attribute is not used to carry hidden user + passwords. The hiding mechanism utilizes MD5, defined in [RFC1321], + in order to generate a key stream based on the RADIUS shared secret + and the 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. Since the User- + Password is known, the key stream corresponding to a given Request + Authenticator can be determined and stored. + + The vulnerability is described in detail in [RFC3579], Section 4.3.4. + Even though IEEE 802.1X Authenticators do not support PAP + authentication, a security vulnerability can still exist where the + same RADIUS shared secret is used for hiding User-Password as well as + other attributes. This can occur, for example, if the same RADIUS + proxy handles authentication requests for both IEEE 802.1X (which may + hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key + attributes) and GPRS (which may hide the User-Password attribute). + + The threat can be mitigated by protecting RADIUS with IPsec ESP with + a non-null transform, as described in [RFC3579], Section 4.2. In + addition, the same RADIUS shared secret MUST NOT be used for both + IEEE 802.1X authentication and PAP authentication. + + + +Congdon, et al. Informational [Page 19] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +5.4. Replay + + As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides + only limited support for replay protection. Replay protection for + RADIUS authentication and accounting can be provided by enabling + IPsec replay protection with RADIUS, as described in [RFC3579], + Section 4.2. + + As with the Request Authenticator, for use with IEEE 802.1X + Authenticators, the Acct-Session-Id SHOULD be globally and temporally + unique. + +5.5. Outcome Mismatches + + [RFC3579] Section 2.6.3. discusses the issues that arise when the EAP + packet encapsulated in an EAP-Message attribute does not agree with + the RADIUS Packet Type. For example, an EAP Success packet might be + encapsulated within an Access-Reject; an EAP Failure might be sent + within an Access-Accept; or an EAP Success or Failure might be sent + within an Access-Challenge. + + As described in [RFC3579] Section 2.6.3., these conflicting messages + are likely to cause confusion. To 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 (Access-Accept/Reject) and + not based on the contents of EAP-Message attributes, if present. + +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 an 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 are + used within various ciphersuites. It also does not specify + ciphersuites addressing the vulnerabilities discovered in WEP, + described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl]. + [IEEE8021X] only defines an authentication framework, leaving the + definition of the authentication methods to other documents, such as + [RFC2716]. + + Since [IEEE8021X] does not address 802.11 integration issues, + implementors are strongly advised to consult additional IEEE 802.11 + security specifications for guidance on how to adapt IEEE 802.1X for + use with 802.11. For example, it is likely that the IEEE 802.11 + + + +Congdon, et al. Informational [Page 20] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + enhanced security specification will define its own IEEE 802.11 key + hierarchy as well as new 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 IEEE 802.11 enhanced security + group completes its work. Known security issues include: + + [1] Default key-only support. 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 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, + resulting in inherent security weaknesses. + + Where per-Station key-mapping keys (e.g. unicast keys) are + unsupported, any Station possessing the default key can decrypt + traffic from other Stations or impersonate them. When used + along with a weak cipher (e.g. WEP), implementations supporting + only default keys provide more material for attacks such as + those described in [Fluhrer] and [Stubbl]. If in addition, the + default key is not refreshed periodically, IEEE 802.1X dynamic + key derivation provides little or no security benefit. For an + understanding of the issues with WEP, see [Berkeley], [Arbaugh], + [Fluhrer], and [Stubbl]. + + [2] Reuse of keying material. The EAPOL-Key descriptor specified in + section 4 uses the same keying material (MS-MPPE-Recv-Key) both + to encrypt the Key field within the EAPOL-Key descriptor, and to + encrypt data passed between the Station and Access Point. + Multi-purpose keying material is frowned upon, since multiple + uses can leak information helpful to an attacker. + + [3] Weak algorithms. The algorithm used to encrypt the Key field + within the EAPOL-Key descriptor is similar to the algorithm used + in WEP, and as a result, shares some of the same weaknesses. As + with WEP, the RC4 stream cipher is used to encrypt the key. As + input to the RC4 engine, the IV and key are concatenated rather + than being combined within a mixing function. As with WEP, the + IV is not a counter, and therefore there is little protection + against reuse. + + + + +Congdon, et al. Informational [Page 21] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 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. + +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. References + +7.1. Normative References + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible + Authentication Protocol (EAP)", RFC 2284, March 1998. + + [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting + Modifications for Tunnel Protocol Support", RFC 2867, + June 2000. + + + + + +Congdon, et al. Informational [Page 22] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., + Holdrege, M. and I. Goyret, "RADIUS Attributes for + Tunnel Protocol Support", RFC 2868, June 2000. + + [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS + Extensions", RFC 2869, June 2000. + + [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", + RFC 3162, August 2001. + + [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. + Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", RFC + 3576, July 2003. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote + Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)", RFC 3579, + September 2003. + + [IEEE8021X] IEEE Standards for Local and Metropolitan Area + Networks: Port based Network Access Control, IEEE Std + 802.1X-2001, June 2001. + +7.2. Informative References + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "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. and J. Vollbrecht, "Proxy Chaining and + Policy Implementation in Roaming", RFC 2607, June + 1999. + + [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication + Protocol", RFC 2716, October 1999. + + + +Congdon, et al. Informational [Page 23] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + [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. and D. Wagner, "Intercepting + Mobile Communications: The Insecurity of 802.11", ACM + SIGMOBILE, Seventh Annual International Conference on + Mobile Computing and Networking, July 2001, Rome, + Italy. + + [Arbaugh] Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11 + Wireless Network has No Clothes", Department of + Computer Science, University of Maryland, College + Park, March 2001. + + [Fluhrer] Fluhrer, S., Mantin, I. and A. Shamir, "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. and A. Rubin, "Using + the Fluhrer, Mantin and Shamir Attack to Break WEP", + 2002 NDSS Conference. + + + + + + +Congdon, et al. Informational [Page 24] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +8. 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 require layer 3 capabilities, and thus may not be + supported by all Authenticators. 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] + L3 8 Framed-IP-Address [RFC2865] + L3 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 25] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 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] + X 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 [RFC3579] + X 80 Message-Authenticator [RFC3579] + 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 26] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + + 802.1X # Attribute + X 85 Acct-Interim-Interval [RFC2869] + X 86 Acct-Tunnel-Packets-Lost [RFC2867] + X 87 NAS-Port-Id [RFC2869] + L3 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] + X 101 Error-Cause [RFC3576] + 802.1X # Attribute + + Key + === + X = May be used with IEEE 802.1X authentication + L3 = Implemented only by Authenticators with Layer 3 + capabilities + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 27] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +9. 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. + +10. Acknowledgments + + The authors would like to acknowledge Bob O'Hara of Airespace, 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. + + + + + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 28] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +11. 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 + + Phone: +1 425 706 6605 + Fax: +1 425 936 7329 + EMail: bernarda@microsoft.com + + Andrew Smith + Trapeze Networks + 5753 W. Las Positas Blvd. + Pleasanton, CA 94588-4084 + + Fax: +1 415 345 1827 + EMail: ah_smith@acm.org + + John Roese + Enterasys + + Phone: +1 603 337 1506 + EMail: jjr@enterasys.com + + 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 + + + + + + + + +Congdon, et al. Informational [Page 29] + +RFC 3580 IEEE 802.1X RADIUS September 2003 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 assignees. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Congdon, et al. Informational [Page 30] + |