RFC 3580
IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
RFC 3580: IEEE 802.1X RADIUS Usage Guidelines 💖
Bestie, this one is all about how IEEE 802.1X Authenticators should use RADIUS! 🎀
- Network Working Group 🌸
- RFC number: 3580
- Title: IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines
- Authors: P. Congdon (Hewlett Packard Company), B. Aboba (Microsoft), A. Smith (Trapeze Networks), G. Zorn (Cisco Systems), J. Roese (Enterasys) 👑
- Category: Informational 🦋
- Date: September 2003 ✨
- Obsoletes / Updates: the title block doesn't list any RFCs that this one obsoletes or updates 🙈
Status of This Memo
Okay so this memo gives information to the Internet community. It is not an Internet standard of any kind 🙅♀️. Distribution of this memo is unlimited, so share it with your whole group chat! 💅
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
Abstract
This document gives suggestions on how IEEE 802.1X Authenticators can use Remote Authentication Dial In User Service (RADIUS). The material is also included in a non-normative Appendix inside the IEEE 802.1X specification, and it's being presented as an IETF RFC for informational purposes. 🧚
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
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 . . . . . . . . . . . . . . . . . . . 301. Introduction ✨
IEEE 802.1X turns on authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. RADIUS support is optional inside 802.1X, but it's expected that lots of 802.1X Authenticators will work 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 a backend Authentication Server, so it can be deployed with stand-alone bridges or Access Points, as well as in centrally managed setups. 🍓
When you want to centrally manage authentication, authorization and accounting (AAA) for IEEE 802 networks, a backend authentication and accounting server is the move. In those situations, IEEE 802.1X Authenticators are expected to act as AAA clients. 🫶
This document gives suggestions on RADIUS usage by IEEE 802.1X Authenticators. Support for any AAA protocol is optional for IEEE 802.1X Authenticators, which is why this specification was folded into a non-normative Appendix within the IEEE 802.1X specification. 🎀
1.1. Terminology
Here are the terms this document uses, bestie: 📚
- Access Point (AP): A Station that provides access to the distribution services via the wireless medium for associated Stations. 📡
- Association: The service used to establish Access Point/Station mapping and enable Station invocation of the distribution system services. 🔗
- Authenticator: 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 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: 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
Several words in this document are used to signal the requirements of the specification. They're 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]. 📖
2. RADIUS Accounting Attributes 🦋
With a few exceptions, the RADIUS accounting attributes defined in [RFC2866], [RFC2867], and [RFC2869] mean the same thing in IEEE 802.1X sessions as they do in dialup sessions, so no extra commentary is needed. It's giving consistency 🙌.
These attributes need more discussion:
Acct-Terminate-CauseAcct-Multi-Session-IdAcct-Link-Count
2. RADIUS Accounting Attributes ✨
2.1. Acct-Terminate-Cause 💖
okay so this attribute tells you how the session was terminated, as described in [RFC2866] 🎀. [IEEE8021X] defines the termination cause values below, and the table shows each one next to its RADIUS equivalent 💅
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/AWhen you're using this attribute, User Request (1) is the one for when the session ended because an EAPOL-Logoff came in from the Supplicant 🙈 And when a session gets moved because of roaming, the EAPOL state machines treat that as a Supplicant Logoff. Lowkey iconic 🦋
A Lost Carrier (2) termination cause means the session ended because the physical connection dropped, and it's not because of roaming between Access Points. Like, if the Supplicant unplugs a point-to-point LAN connection, or wanders out of range of an Access Point, this is the one that gets used 📡 So Lost Carrier (2) basically equals a Port Disabled condition in the EAPOL state machines ✨
A Supplicant Restart (19) termination cause means the Supplicant state machines got re-initialized 🔄
A Reauthentication Failure (20) termination cause means a Supplicant that was already authenticated couldn't re-authenticate successfully, either after the re-authentication timer expired or after an explicit re-authentication request from management action 😭
Within [IEEE80211], periodic re-authentication can be useful for preventing reuse of an initialization vector with a given key 🔐 Here's the tea: since a successful re-authentication doesn't end the session, accounting packets aren't sent just because 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 happens before association, accounting packets aren't sent until an association occurs 🫶
An Admin Reset (6) termination cause means the Port has been administratively forced into the unauthorized state 👑
A Port Reinitialized (21) termination cause means the Port's MAC has been reinitialized 🌈
A Port Administratively Disabled (22) termination cause means the Port has been administratively disabled 💀
2.2. Acct-Multi-Session-Id 🌸
The whole purpose of this attribute is to make it possible to link together multiple related sessions 🔗 Even though [IEEE8021X] doesn't act on aggregated ports, a Supplicant roaming between Access Points can cause multiple RADIUS accounting packets to be sent by different Access Points. Chaotic but make it make sense 🙈
Where the Access Points support it, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant ✨ In that situation, if the session context gets transferred between Access Points, accounting packets MAY be sent without a corresponding authentication and authorization exchange, as long as Association has occurred. BUT, in that situation it's assumed that the Acct-Multi-Session-Id gets transferred between the Access Points as part of the Inter-Access Point Protocol (IAPP) 📦
If the Acct-Multi-Session-Id wasn't unique between Access Points, then the chosen Acct-Multi-Session-Id could overlap with an existing value already allocated on that Access Point. The Accounting Server would then be unable to tell a roaming session apart from a multi-link session 😵💫
So the Acct-Multi-Session-Id attribute is unique among all the bridges or Access Points, Supplicants and sessions 💅 To get that uniqueness, it's suggested that the Acct-Multi-Session-Id be of the form:
Original AP MAC Address | Supplicant MAC Address | NTP TimestampHere "|" represents concatenation. The original AP MAC Address is the MAC address of the bridge or Access Point where the session started, and the 64-bit NTP timestamp indicates the beginning of the original session ⏰ To keep the Acct-Multi-Session-Id consistent between roaming sessions, it may be moved between Access Points as part of IAPP or another handoff scheme 🎀
Using an Acct-Multi-Session-Id of this form guarantees uniqueness among all Access Points, Supplicants and sessions 🏆 And since the NTP timestamp doesn't wrap on reboot, there's no possibility that a rebooted Access Point could pick an Acct-Multi-Session-Id that gets confused with one from a previous session 🥹
Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X it gets 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 🎀
Okay, this section is all about how attributes defined in [RFC2865], [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] get used in IEEE 802.1X authentication 💜
3.1. User-Name 🫶
In IEEE 802.1X, the Supplicant typically provides its identity through an EAP-Response/Identity message 🪪 Where that's available, the Supplicant identity goes into the User-Name attribute, and it's 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 doesn't support PAP or CHAP authentication, the User-Password, CHAP-Password or CHAP-Challenge attributes aren't 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 the Authenticator will still be reachable even if one of the interfaces fails 🛟
3.4. NAS-Port 🔌
For use with IEEE 802.1X, the NAS-Port will contain the port number of the bridge, if that's available. Access Points don't have physical ports, though 🙃 Instead, a unique "association ID" gets assigned to every mobile Station upon a successful association exchange. So for an Access Point, if the association exchange was completed before authentication, the NAS-Port attribute will contain the association ID, which is a 16-bit unsigned integer 🔢 Where IEEE 802.1X authentication happens before 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 the most commonly used ones 💅
A Service-Type of Framed means that appropriate 802 framing should be used for the connection 🖼️ A Service-Type of Authenticate Only (8) means no authorization information needs to be returned in the Access-Accept 🙌 As described in [RFC2865], a Service-Type of Call Check is included in an Access-Request packet to ask the RADIUS server to accept or reject the connection attempt. That's 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's 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 doesn't provide a mechanism for IP address assignment. So 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's therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and it can't 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, because it has to account for the extra overhead from the IEEE 802.1X Version (1), Type (1) and Body Length (2) fields 🧮 For EAP over IEEE 802 media, the Framed-MTU values (which don't include LLC/SNAP overhead) and maximum frame length values (not including the preamble) are as follows:
Maximum Frame
Media Framed-MTU Length
========= =============== ==============
Ethernet 1500 1522
802.3 1500 1522
802.4 8174 8193
802.5 (4 Mbps) 4528 4550
802.5 (16 Mbps) 18173 18200
802.5 (100 Mb/s) 18173 18200
802.6 9191 9240
802.9a 1500 1518
802.11 2304 2346
802.12 (Ethernet) 1500 1518
802.12 (Token Ring) 4502 4528
FDDI 4479 4500NOTE - 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 can't 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] doesn't include compression support. So this attribute is not understood by [IEEE8021X] Authenticators 🙅♀️
3.12. Displayable Messages 💬
The Reply-Message attribute, defined in section 5.18 of [RFC2865], shows text that can be displayed to the user 💖. It's kinda like the EAP Notification Type from [RFC2284] ✨. As noted in [RFC3579], Section 2.6.5, when you send a displayable message to an [IEEE8021X] Authenticator, those messages are best sent inside EAP-Message/EAP-Request/Notification attribute(s), not inside Reply-Message attribute(s) 🫶.
3.13. Callback-Number, Callback-ID 📞
These attributes are not understood by IEEE 802.1X Authenticators 🙈.
3.14. Framed-Route, Framed-IPv6-Route 🗺️
The Framed-Route and Framed-IPv6-Route attributes provide routes that are to be configured for the Supplicant ✨. So they're only relevant for IEEE 802.1X Authenticators that act as layer 3 devices. A bridge or Access Point can't understand them 💀.
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 how to derive 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 this is 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 it's 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 it's 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 it's sent in an Access-Challenge, this attribute represents the maximum number of seconds that an IEEE 802.1X Authenticator should wait for an EAP-Response before retransmitting ⏳. In this case, the Session-Timeout attribute is used to load the suppTimeout constant within the backend state machine of IEEE 802.1X 🎯.
3.18. Idle-Timeout 😴
The Idle-Timeout attribute is described in [RFC2865] 📖. For IEEE 802 media other than 802.11, the media are always on 🟢. As a result, the Idle-Timeout attribute is typically only used with wireless media such as IEEE 802.11 📶. It's 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 that originated the Access-Request 🫶.
3.23. NAS-Port-Type 🔌
For use with IEEE 802.1X, the NAS-Port-Type values of Ethernet (15), Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be used 🦄.
3.24. Port-Limit 🚫
This attribute has no meaning when sent to an [IEEE8021X] Authenticator 🙅♀️.
3.25. Password-Retry 🔑
In IEEE 802.1X, the Authenticator always transitions to the HELD state after an authentication failure 🛑. So this attribute doesn't 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 it's 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 it's 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 🔒. No cap, this one is a big deal 😭.
3.29. NAS-Port-Id 🪪
This attribute is used to identify the IEEE 802.1X Authenticator port which authenticates the Supplicant 🎯. The NAS-Port-Id differs from the NAS-Port in that it is a string of variable length, whereas the NAS-Port is a 4 octet value 📏.
3.30. Framed-Pool, Framed-IPv6-Pool 🏊♀️
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=VLANIDNote 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).
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 🔑
Okay so the RC4 EAPOL-Key frame is made and sent by the Authenticator to deliver media-specific key info ✨. In 802.11, for example, it can hand out multicast/broadcast ("default") keys or unicast ("key mapping") keys. The "default" key is the same for every Station in a broadcast domain 🌸.
This frame is not acknowledged, so the Authenticator has no idea whether the Supplicant actually got it 😭. If it gets lost, the Supplicant and Authenticator end up with different keying material and communication breaks. The usual fix is re-running the authentication 💀.
The frame goes from the Authenticator to the Supplicant to provision the "default" key, and later to refresh it 🦋. It can also refresh the key-mapping key. Rekey is typically only required with weak ciphersuites such as WEP, defined in [IEEE80211] 🧚.
Where keys are needed, people usually pick an EAP method that derives keys, which is so iconic 👑. That means the initial "key mapping" keys can come from EAP keying material, so the Authenticator doesn't have to send an RC4 EAPOL-Key frame to the Supplicant at all. An example of how EAP keying material can be derived and used is presented in [RFC2716] 💜.
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 tells you what kind of packet is being sent. For an EAPOL-Key Descriptor, the Packet Type field contains 0x03.
Packet Body Length 📏 The Packet Body Length is two octets. It holds the length of the EAPOL-Key descriptor in octets, not counting the Version, Packet Type and Packet Body Length fields.
Type 🧩 The Type field is a single octet. The Key descriptor is defined differently for each Type. This specification only documents 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 holds the key in encrypted form, and it is Key Length long. That's 5 octets (40 bits) for WEP, and 13 octets (104 bits) for WEP-128. If Packet Body Length = 44, the Key field is absent, and Key Length says how many least significant octets from the MS-MPPE-Send-Key attribute [RFC2548] to use as the keying material.
Heads up 🚨: the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the Authenticator's point of view. From the Supplicant's point of view, the terms flip. So 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. Mind the mix-up, bestie 💅.
Replay Counter ⏱️ The Replay Counter field is 8 octets. It doesn't 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 that says what type of key is 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 holds an HMAC-MD5 message integrity check computed over the EAPOL-Key descriptor, starting from the Version field. The Key field is filled in if present, but the Key Signature field is set to zero for the computation. For the computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is used as the HMAC-MD5 key.
Key 🗝️ If Packet Body Length = 44 + Key Length, then the Key field holds the key in encrypted form, and it is Key Length octets long. If Packet Body Length = 44, the Key field is absent, and the least significant Key Length octets from the MS-MPPE-Send-Key attribute are used as the keying material. When the Key field is encrypted using RC4, the RC4 encryption key is formed by concatenating the 16 octet (128 bit) Key-IV field with the 32 octet MS-MPPE-Recv-Key attribute. That yields a 48 octet RC4 key (384 bits) 🌟.
5. Security Considerations 🛡️
Since this document describes using RADIUS for authentication, authorization, and accounting in IEEE 802.1X-enabled networks, it's vulnerable to all the threats that show up 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. But 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.
So when it's used with IEEE 802.1X, all RADIUS packets MUST be authenticated and integrity protected 🔒. Also, 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 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. To decrease that 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.
Plus, the risk of an offline dictionary attack can be cut down even more by using IPsec ESP with a non-null transform 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 isn't used to carry hidden user passwords. The hiding mechanism uses MD5, defined in [RFC1321], to generate a key stream based on the RADIUS shared secret and the Request Authenticator. Where PAP is in use, it's possible to collect key streams for a given Request Authenticator value. You do this by capturing RADIUS conversations for a PAP authentication attempt using a known password. Since the User-Password is known, the key stream for a given Request Authenticator can be worked out and stored 💀.
The vulnerability is described in detail in [RFC3579], Section 4.3.4. Even though IEEE 802.1X Authenticators don't 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 happen, 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. Also, the same RADIUS shared secret MUST NOT be used for both IEEE 802.1X authentication and PAP authentication 🚫.
5.4. Replay 🔁
As noted in [RFC3579] Section 4.3.5., the RADIUS protocol only provides 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. talks about the issues that come up when the EAP packet encapsulated in an EAP-Message attribute doesn't 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. So to make sure access decisions made by IEEE 802.1X Authenticators match what the RADIUS server wants, the Authenticator has to decide 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 📶
okay so [IEEE8021X] was built for wired IEEE 802 networks like Ethernet 🔌, which means it does not explain how to securely adapt IEEE 802.1X for use with 802.11 (wifi). That job is left to an enhanced security specification being developed within IEEE 802.11 🫶
For example, [IEEE8021X] doesn't say whether authentication happens before or after association 🤷♀️, and it doesn't say how the derived keys get used inside the various ciphersuites. It also doesn't define any ciphersuites that fix the vulnerabilities found in WEP, which are described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl] 😭. [IEEE8021X] only sets up an authentication framework and leaves the actual authentication methods to other documents, like [RFC2716] 🧚
Since [IEEE8021X] doesn't cover the 802.11 integration stuff, implementors are strongly advised to check out the additional IEEE 802.11 security specifications for guidance on adapting IEEE 802.1X for 802.11 📚 It's likely that the IEEE 802.11 enhanced security specification will define its own IEEE 802.11 key hierarchy, plus 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, once the IEEE 802.11 enhanced security group finishes its work 🥲 In the meantime, here are the known security issues:
- Default key-only support. IEEE 802.1X lets you derive per-Station unicast keys, which [IEEE80211] calls "key mapping keys" 🗝️ Keys used to encrypt multicast/broadcast traffic are called "default keys". The tea is that in some 802.11 implementations, the unicast keys (derived during the EAP authentication process) are only used to encrypt, authenticate, and integrity protect the EAPOL-Key descriptor, as described in Section 4. 💀 These implementations only support default keys, which are normally just for multicast/broadcast traffic, to secure all traffic, unicast or multicast/broadcast. That's a lot of inherent security weakness 😬
When per-Station key-mapping keys (e.g. unicast keys) aren't supported, any Station holding the default key can decrypt traffic from other Stations or impersonate them 👀 If you pair that with a weak cipher (e.g. WEP), these implementations hand attackers more material for attacks like the ones in [Fluhrer] and [Stubbl] 🫠 And if the default key isn't refreshed periodically too, IEEE 802.1X dynamic key derivation gives you little or no security benefit. To understand the WEP problems better, check out [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl] 📖
- Reuse of keying material. The EAPOL-Key descriptor specified in section 4 uses the same keying material (MS-MPPE-Recv-Key) 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 info that helps an attacker 🕵️♀️
- Weak algorithms. The algorithm used to encrypt the Key field within the EAPOL-Key descriptor is similar to the one used in WEP, so it shares some of the same weaknesses 🥀 Just like WEP, the RC4 stream cipher is used to encrypt the key. As input to the RC4 engine, the IV and key get concatenated instead of being combined within a mixing function 😵 And just like WEP, the IV isn't a counter, so there's very little protection against reuse 🚩
Because of all these vulnerabilities, implementors who want to use the EAPOL-Key descriptor described in this document are urged to check out the 802.11 enhanced security specification for a more secure alternative 🛡️ It's also a good idea to keep up with the evolving literature on WEP vulnerabilities, so you understand the risks better and can figure out an appropriate re-keying interval 🔄✨
6. IANA Considerations 🎀
This specification doesn't create any RADIUS attributes or new number spaces for IANA administration 🙌 It does, however, require assigning new values to existing RADIUS attributes. Those are:
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.
- [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.
- [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.
8. Table of Attributes ✨
okay so this section is basically the cheat sheet 📋 it tells you which RADIUS attributes MAY be sent and received during IEEE 802.1X authentication 🦋 the L3 tag marks the ones that need layer 3 capabilities, which means not every Authenticator is gonna support them, so lowkey check first 💅 and for every attribute, the reference in brackets is the actual source of truth, so go there for the real usage details 🙈
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
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
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 # AttributeKey
X = May be used with IEEE 802.1X authentication
L3 = Implemented only by Authenticators with Layer 3
capabilities9. Intellectual Property Statement 🎀
okay this one is the legal-ish bit 💼 the IETF doesn't take a position on whether any intellectual property or other rights might apply to the technology in this document, or whether licenses to use it are available, and it doesn't say it has tried to find any such rights 🫶 if you want the IETF's procedures on rights for standards-track docs, look in BCP-11 📚 copies of any claimed rights, or assurances of licenses, or the results of an attempt to get a general license for implementers or users, can be obtained from the IETF Secretariat 🌸
the IETF also invites anyone who's aware of copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard to tell them about it, and the info goes to the IETF Executive Director 💜
10. Acknowledgments 🌈
the authors wanted to give a shoutout to Bob O'Hara of Airespace, David Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of Microsoft, and Andrea Li, Albert Young and Dave Bagby of 3Com for helping out with this document 🥹✨ so iconic of them 👑
11. Authors' Addresses 💌
these are the people who wrote it, with their contact info, so you know who to ping 📬
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
12. Full Copyright Statement ✨
Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
this document and translations of it can be copied and shared, and derivative works that comment on or explain it, or help implement it, can be made and shared too, as long as the copyright notice and this paragraph stay on every copy 💖 but the document itself can't be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet orgs, unless it's needed for developing Internet standards (then the Internet Standards process copyright procedures have to be followed), or to translate it into languages other than English 🌍
the permissions above are perpetual and won't be revoked by the Internet Society or its successors or assignees 🦋
this document and the info in it is provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, including but not limited to any warranty that using the info won't 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 💅
📦 where this page comes from
- ietf: rfc3580 2003-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms