summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3580.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc3580.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc3580.txt')
-rw-r--r--doc/rfc/rfc3580.txt1683
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc3580.txt b/doc/rfc/rfc3580.txt
new file mode 100644
index 0000000..b87235c
--- /dev/null
+++ b/doc/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]
+