RFC 3579
RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)
RFC 3579 🎀 RADIUS Support for EAP, bestie!
- RFC number: 3579
- Title: RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)
- Group: Network Working Group
- Authors: B. Aboba (Microsoft) and P. Calhoun (Airespace)
- Category: Informational
- Date: September 2003
- Updates: RFC 2869
Status of this Memo 📝
okay so this memo is informational 💅 It's giving "here's some useful info for the Internet community" and that's it. It does not specify an Internet standard of any kind, so don't go treating it like one 🙈 Distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
Abstract ✨
okay this doc is all about bringing RADIUS (Remote Authentication Dial In User Service) support to the Extensible Authentication Protocol (EAP), which is an authentication framework that can handle multiple authentication mechanisms 🦋 The vibe is that the Network Access Server (NAS) just forwards EAP packets back and forth to the RADIUS server, wrapped up inside EAP-Message attributes 🎁
The big win? The NAS can support any EAP authentication method without needing method-specific code, because all that logic lives on the RADIUS server 🧚 It's so smart, I'm obsessed 😭 EAP was originally built for PPP, but it's now also being used with IEEE 802 too 🌸
This document updates RFC 2869. 💜
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements. . . . . . . . . . . . . . 3
1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
2. RADIUS Support for EAP . . . . . . . . . . . . . . . . . . . . 4
2.1. Protocol Overview. . . . . . . . . . . . . . . . . . . . 5
2.2. Invalid Packets. . . . . . . . . . . . . . . . . . . . . 9
2.3. Retransmission . . . . . . . . . . . . . . . . . . . . . 10
2.4. Fragmentation. . . . . . . . . . . . . . . . . . . . . . 10
2.5. Alternative uses . . . . . . . . . . . . . . . . . . . . 11
2.6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Message-Authenticator. . . . . . . . . . . . . . . . . . 16
3.3. Table of Attributes. . . . . . . . . . . . . . . . . . . 18
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
4.1. Security Requirements. . . . . . . . . . . . . . . . . . 19
4.2. Security Protocol. . . . . . . . . . . . . . . . . . . . 20
4.3. Security Issues. . . . . . . . . . . . . . . . . . . . . 22
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 30
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1. Normative References . . . . . . . . . . . . . . . . . . 30
6.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A - Examples. . . . . . . . . . . . . . . . . . . . . . . 34
Appendix B - Change Log. . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 461. Introduction 🌷
okay so RADIUS is an authentication, authorization and accounting protocol that controls network access 🔐 Its authentication and authorization bits are specified in [RFC2865], accounting is in [RFC2866], and RADIUS over IPv6 is in [RFC3162] 🫶
EAP is defined in [RFC2284] and it's an authentication framework that supports multiple authentication mechanisms 💖 It can be used on dedicated links, switched circuits, and both wired and wireless links, so it's super versatile 🦋
To date, EAP has been implemented with hosts and routers that connect over switched circuits or dial-up lines using PPP [RFC1661] 📞 It's also been implemented with bridges supporting [IEEE802] 🌉 EAP encapsulation on IEEE 802 wired media is described in [IEEE8021X] 🧵
RADIUS attributes are variable length Type-Length-Value 3-tuples 📦 The lovely thing is that new attribute values can be added without disturbing existing implementations ✨ This spec covers the two RADIUS attributes that support EAP: EAP-Message and Message-Authenticator 🎀 These have a ton of field experience already, and the purpose of this document is to clarify things and sort out interoperability issues 🙌
As noted in [RFC2865], a Network Access Server (NAS) that does not implement a given service MUST NOT implement the RADIUS attributes for that service 🚫 This means a NAS that can't offer EAP service MUST NOT implement the RADIUS attributes for EAP 💅 And a NAS MUST treat a RADIUS Access-Accept requesting an unavailable service as an Access-Reject instead 🙅♀️
1.1. Specification of Requirements 📜
In this document, several words are used to signify the requirements of the specification 🧐 They're often capitalized, and 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] 🌈
1.2. Terminology 📖
This document frequently uses the following terms, so let's get the vocab down 💜
authenticator 🛂 The end of the link requiring the authentication. It's also known as the Network Access Server (NAS) or RADIUS client. In IEEE 802.1X terminology, the term Authenticator is used.
peer 🧑💻 The other end of the point-to-point link (PPP), point-to-point LAN segment (IEEE 802.1X) or wireless link, which is being authenticated by the authenticator. In IEEE 802.1X, this end is known as the Supplicant.
authentication server 🏰 An authentication server is an entity that gives an authentication service to an authenticator (NAS). It verifies, from the credentials the peer provides, the identity claim the peer makes. It may also provide credentials so the peer can verify the identity of the authentication server 🔍 In this document, the NAS is assumed to act as a pass-through, forwarding EAP packets between the RADIUS server and the EAP peer 🔁
So the RADIUS server operates as an authentication server 👑
silently discard 🤫 This means the implementation throws the packet away without any further processing. The implementation SHOULD be able to log the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter 📊
displayable message 💬 This is a human readable string of characters, and it MUST NOT affect the operation of the protocol 🙅 The message encoding MUST follow the UTF-8 transformation format [RFC2279] 🌏
Network Access Server (NAS) 🚪 The device that provides access to the network. It's also known as the Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client 🫧
service 🛎️ The NAS provides a service to the user, such as IEEE 802 or PPP 💁♀️
session ⏳ Each service the NAS provides to a peer is a session. A session begins at the point where service is first provided and ends at the point where service is ended. A peer may have multiple sessions in parallel or in series if the NAS supports that, and each session generates a separate start and stop accounting record 🎬
2. RADIUS Support for EAP 🔥
okay so EAP, described in [RFC2284], gives us a standard way to support extra authentication methods without the NAS needing an upgrade for each new one 🙌 Smart cards, Kerberos [RFC1510], Public Key [RFC2716], One Time Passwords [RFC2284], and others can all be added this way 🔐
The flexibility is the main character energy here 💅 EAP is what selects a specific authentication mechanism. Instead of making the NAS get updated for every new method, EAP lets an authentication server implement the methods, while the NAS acts as a pass-through for some or all methods and peers 🦋
A NAS MAY authenticate local peers while also acting as a pass-through for non-local peers and for authentication methods it doesn't implement locally 🏠 A NAS implementing this spec is not required to use RADIUS to authenticate every peer ✨ But once the NAS starts acting as a pass-through for a particular session, it can no longer do local authentication for that session 🚧
To put EAP inside RADIUS, this document introduces two new attributes, EAP-Message and Message-Authenticator 🎀 This section explains how they can be used to provide EAP support within RADIUS 🧚
2.1. Protocol Overview 🎀
Okay so in RADIUS/EAP, RADIUS is basically the delivery driver 🚚, shuttling RADIUS-encapsulated EAP Packets back and forth between the NAS and an authentication server. That's its whole job, and it does it iconically.
The authenticating peer and the NAS kick off the EAP convo by negotiating use of EAP 💬. Once EAP is agreed on, the NAS SHOULD send an initial EAP-Request message to the authenticating peer. That's usually an EAP-Request/Identity, but it could also be an EAP-Request for an authentication method (Types 4 and greater) 🔐. A NAS MAY be configured to start with a default authentication method. This is so useful when the identity gets figured out another way (like through Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info) 📞, when there's one auth method that's required and already has its own identity exchange baked in, or when identity hiding is the goal, so the identity isn't requested until after a protected channel is set up 🙈🔒.
The peer replies with an EAP-Response. The NAS MAY determine from the Response that it should proceed with local authentication 🏠. Or, the NAS MAY act as a pass-through and wrap the EAP-Response inside EAP-Message attribute(s) sent to the RADIUS server in a RADIUS Access-Request packet 🎁. If the NAS sent an EAP-Request/Identity as the first packet, the peer answers with an EAP-Response/Identity. The NAS may determine that the peer is local and handle it with local authentication. If there's no match in the list of local users, the NAS wraps the EAP-Response/Identity in an EAP-Message attribute, tucked inside an Access-Request packet 📦.
When a RADIUS server gets a valid Access-Request packet containing EAP-Message attribute(s), and it's compliant with this specification and wants to authenticate with EAP, it MUST respond with an Access-Challenge packet containing EAP-Message attribute(s) 👑. If the RADIUS server doesn't support EAP or doesn't want to authenticate with EAP, it MUST respond with an Access-Reject 🙅♀️.
EAP-Message attribute(s) hold a single EAP packet, which the NAS unwraps and passes along to the authenticating peer 💌. The peer then sends back an EAP-Response packet, and the NAS wraps that in an Access-Request containing EAP-Message attribute(s). EAP is a 'lock step' protocol, so apart from the initial Request, a new Request can't be sent until a valid Response comes back 🔁. No skipping ahead, bestie.
The convo keeps going until the RADIUS server sends either an Access-Reject or an Access-Accept packet 🏁. Getting an Access-Reject MUST result in the NAS denying access to the authenticating peer 🚫. An Access-Accept packet successfully ends the authentication phase ✅. The NAS MUST NOT "manufacture" a Success or Failure packet just because of a timeout 🙅♀️💀. After a suitable number of timeouts have passed, the NAS SHOULD end the EAP conversation instead ⏳.
Using RADIUS, the NAS can act as a pass-through for an EAP conversation between the peer and the authentication server, without having to implement the EAP method used between them 🦋. When the NAS starts the conversation by sending an EAP-Request for an authentication method, the NAS doesn't necessarily need to fully implement the EAP method in that initial EAP-Request. Depending on the initial method, it may be enough for the NAS to be configured with the initial packet to send to the peer, and then just act as a pass-through for the messages after that 🧚. Heads up though: since the NAS only wraps the EAP-Response in its initial Access-Request, the initial EAP-Request inside the authentication method isn't available to the RADIUS server. So for the RADIUS server to keep the convo going, either the initial EAP-Request is vestigial (so the RADIUS server doesn't need to know about it), or the important info from it (like a nonce) gets reflected in the initial EAP-Response so the RADIUS server can grab it without ever seeing the initial EAP-Request 🧠.
If the initial EAP-Request from the NAS is for an authentication Type (4 or greater), the peer MAY respond with a Nak, saying it'd prefer a different authentication method that isn't implemented locally 🙅. In that case, the NAS SHOULD send an Access-Request wrapping the received EAP-Response/Nak 📨. This gives the RADIUS server a hint about the authentication method(s) the peer prefers, though it doesn't say anything about the Type of the original Request 🤷♀️. It also gives the server the Identifier used in the initial EAP-Request, so Identifier conflicts can be avoided 🆔.
To check whether the alternatives the peer prefers are allowed, the RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) that wrap an EAP-Request/Identity (Type 1) 🔍. That lets the server figure out who the peer is, so it can look up the right authentication policy. Or, an EAP-Request for an authentication method (Type 4 or greater) could be sent instead 🔄. Since the RADIUS server might not know the Type of the initial EAP-Request, it's possible for it to pick an unacceptable method, and then the peer just sends another Nak 😬.
Now, to let non-EAP aware RADIUS proxies forward the Access-Request packet, here's the rule 📜. If the NAS first sends an EAP-Request/Identity to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity it got from the peer into the User-Name attribute. It MUST also include that Type-Data field of the EAP-Response/Identity in the User-Name attribute of every Access-Request after that 🏷️. Proxies are assumed to act as pass-throughs, so they can't be expected to parse an EAP-Response/Identity wrapped inside EAP-Message attribute(s) 🙈. If the NAS first sends an EAP-Request for an authentication method, and the peer identity can't be figured out from the EAP-Response, then the User-Name attribute SHOULD be determined some other way 🔧. As noted in [RFC2865] Section 5.6, it is recommended that Access-Requests use the value of the Calling-Station-Id as the value of the User-Name attribute 📞.
Having the NAS send the initial EAP-Request packet has a few big perks 🌟:
- It saves a round trip between the NAS and the RADIUS server 🏃♀️.
- An Access-Request only gets sent to the RADIUS server if the authenticating peer sends an EAP-Response, which confirms it supports EAP ✅. When peers might be EAP unaware, starting a RADIUS Access-Request on a "carrier sense" or "media up" signal can lead to tons of authentication exchanges that never finish 😭. For example, on wired networks [IEEE8021X] Supplicants usually don't start the 802.1X conversation with an EAPOL-Start. So an IEEE 802.1X-enabled bridge might not be able to tell whether the peer supports EAP until it gets a Response to the initial EAP-Request 🌉.
- It lets some peers be authenticated locally 🏠✨.
Okay, but this technique can't be used everywhere, even though it has serious advantages 🥲. Sometimes the peer identity is already known (like when authentication and accounting are handled based on Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info), but the right EAP method might change based on that identity 🔀.
Instead of sending an initial EAP-Request packet to the authenticating peer, the NAS MAY send an Access-Request packet to the RADIUS server once it detects the peer's presence 📡. That packet contains an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) that wrap an EAP-Request/Identity (Type 1) 🙋♀️. But the server can also send an EAP-Request for an authentication method (Type 4 or greater) 🔐.
EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data) 🫧. The Calling-Station-Id SHOULD be included in the User-Name attribute. This can result in the NAS sending a RADIUS Access-Request to the RADIUS server without first checking that the peer supports EAP 😳. Since this technique can leave a big pile of unfinished RADIUS conversations, it SHOULD NOT be used by default in situations where EAP unaware peers are common, or where peer support for EAP can't be determined on first contact (for example, [IEEE8021X] Supplicants that don't start the conversation with an EAPOL-Start) 🚫.
For proxied RADIUS requests, there are two ways to process things 🔀. If the domain is determined by the Calling-Station-Id, Called-Station-Id and/or Originating-Line-Info, the RADIUS server may proxy the initial RADIUS Access-Request/EAP-Start 📬. If the realm is determined by the peer identity, the local RADIUS server MUST respond with an Access-Challenge that includes an EAP-Message attribute wrapping an EAP-Request/Identity packet 🪪. The response from the authenticating peer SHOULD be proxied to the final authentication server 🎯.
Last but not least 💅: if an Access-Request is sent to a RADIUS server that doesn't support the EAP-Message attribute, then an Access-Reject MUST be sent back 🛑. When the NAS gets an Access-Reject, it MUST deny access to the authenticating peer 🙅♀️🔥.
2.2. Invalid Packets ✨
okay so while the NAS is just acting as a pass-through, it MUST check the EAP header fields (Code, Identifier, Length) before forwarding any EAP packet to or from the RADIUS server 💅. When a packet comes in from the peer, the NAS checks the Code (2) and Length fields, then compares the Identifier against the current one, which the RADIUS server gave in the most recently validated EAP-Request 👀. When a packet comes back from the RADIUS server (wrapped inside an Access-Challenge), the NAS checks the Code (1) and Length fields, then updates the current Identifier value 🦋. Any pending EAP Responses that don't match the current Identifier get quietly discarded by the NAS 🫥.
ngl the tricky part is that EAP method fields (Type, Type-Data) usually aren't checked by a NAS that's just passing things along 😭. So even with all these checks, a NAS can still end up forwarding an invalid EAP packet to or from the RADIUS server 💀. A RADIUS server that gets EAP-Message attribute(s) it doesn't understand SHOULD decide whether the error is fatal or non-fatal based on the EAP Type 🧠. If the RADIUS server decides it's a fatal error, it MUST send an Access-Reject that contains an EAP-Message attribute wrapping EAP-Failure 🚫.
If the RADIUS server decides it's a non-fatal error, it MAY send an Access-Challenge to the NAS with EAP-Message attribute(s) plus an Error-Cause attribute [RFC3576] set to value 202 (decimal), "Invalid EAP Packet (Ignored)" 🌸. That Access-Challenge SHOULD wrap the most recently sent EAP-Request packet, using the same Identifier value 🔁. When a NAS running an older version of this spec gets one of these, it unwraps the EAP-Request and sends it to the peer, and the peer will retransmit its EAP-Response 🫶.
A NAS that follows this spec and receives an Access-Challenge with an Error-Cause attribute of value 202 (decimal) SHOULD throw out the EAP-Response it sent most recently to the RADIUS server, then check whether any other EAP-Response packets have arrived that match the current Identifier value ✨. If it finds one, a new EAP-Response packet MUST be sent to the RADIUS server inside an Access-Request, and the EAP-Message attribute(s) in the Access-Challenge get silently discarded 🎀. If there's no EAP-Response packet available, the EAP-Request wrapped in the Access-Challenge gets sent to the peer, and the retransmission timer is reset ⏱️.
Now for Denial of Service (DoS) attacks, which are not it 🙅♀️. The NAS is advised to set aside a finite buffer for EAP packets coming from the peer, and to drop packets according to a sensible policy once that buffer is full 🛡️. The RADIUS server is also advised to allow only a modest number of invalid EAP packets in a single session before ending the session with an Access-Reject 🚪. By default, a value of 5 invalid EAP packets is recommended 🔢.
2.3. Retransmission
as noted in [RFC2284], if an EAP packet gets lost in transit between the authenticating peer and the NAS (or the other way around), the NAS will retransmit 🔄.
sometimes you need to adjust retransmission strategies and authentication timeouts 🕰️. For example, when a token card is in use, the user might need extra time to find the card and type in the token 🪪. The NAS usually doesn't know these parameters, so the RADIUS server has to provide them 🧚. That's done by including a Session-Timeout attribute in the Access-Challenge packet ⏳.
If an Access-Challenge carries both a Session-Timeout and an EAP-Message, the Session-Timeout value sets the EAP retransmission timer for that one EAP Request, and only that Request 💜. Once the EAP-Request has been sent, the NAS starts the retransmission timer. If the timer runs out before an EAP-Response for that Request shows up, the EAP-Request gets retransmitted 🔁.
2.4. Fragmentation
using the EAP-Message attribute, the RADIUS server can wrap up an EAP packet that's bigger than the MTU on the link between the NAS and the peer 📦. The RADIUS server can't use MTU discovery to figure out the link MTU, so the Framed-MTU attribute may be included in an Access-Request packet that has an EAP-Message attribute, so the RADIUS server knows the size 📏. A RADIUS server that got a Framed-MTU attribute in an Access-Request MUST NOT send any later packet in that EAP conversation with EAP-Message attributes whose concatenated values go over the Framed-MTU value 🚧. The link type (set by the NAS-Port-Type attribute) has to be taken into account too 🧠.
For example, as noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, the RADIUS server can send an EAP packet as big as Framed-MTU minus four (4) octets 📶. That leaves room for the IEEE 802.1X Version (1), Type (1) and Body Length (2) fields 💅.
2.5. Alternative Uses
right now, the conversation between security servers and the RADIUS server is often proprietary because there's no standard for it 🙃. To get more standardization and let RADIUS vendors and security vendors actually work together, it is recommended that RADIUS-encapsulated EAP be used for this conversation 🤝.
this is great because the RADIUS server can support EAP without needing any authentication-specific code 🙌. That authentication code can live on a security server instead 🏠.
When RADIUS-encapsulated EAP is used between a RADIUS server and a security server, the security server will usually send back an Access-Accept without the attributes that an Access-Accept normally has 🫠. So the RADIUS server MUST add those attributes before it sends the Access-Accept to the NAS 🎀.
2.6. Usage Guidelines
2.6.1. Identifier Space
in EAP, every session gets its own unique Identifier space 🌈. RADIUS server implementations MUST be able to tell apart EAP packets that have the same Identifier but live in different sessions coming from the same NAS 👯. Sessions can be told apart using NAS and session identification attributes 🪪. The NAS identification attributes are NAS-Identifier, NAS-IPv6-Address and NAS-IPv4-Address 🖥️. The session identification attributes are User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id, Called-Station-Id, Calling-Station-Id and Originating-Line-Info 📋.
2.6.2. Role Reversal
EAP is peer-to-peer, so an independent and simultaneous authentication can happen in the reverse direction too 🔀. Both peers can act as authenticators and authenticatees at the same time 🪞.
however, this spec does not support role reversal 🙅♀️. A RADIUS server MUST answer an Access-Request that wraps an EAP-Request with an Access-Reject 🚫. To keep the peer from retransmitting, the Access-Reject SHOULD include an EAP-Response/Nak packet that says there's no preferred method, wrapped in EAP-Message attribute(s) 🙈.
2.6.3. Conflicting Messages
the NAS MUST make its access control decision based only on the RADIUS Packet Type (Access-Accept/Access-Reject) 🔑. The access control decision MUST NOT be based on what's inside the EAP packet(s) in any EAP-Message attributes, if there are any 🚫.
Access-Accept packets SHOULD have only one EAP-Message attribute, containing EAP Success 🥳. In the same way, Access-Reject packets SHOULD have only one EAP-Message attribute, containing EAP Failure 😔.
when the encapsulated EAP packet doesn't match the result the RADIUS Packet Type implies, things get messy 🌀. The NAS and the peer end up with different ideas about how the authentication went 😵💫.
For example, if the NAS gets an Access-Reject with an encapsulated EAP Success, it won't grant access to the peer 🚪. But the peer gets the EAP Success and thinks it authenticated successfully 🥲.
If the NAS gets an Access-Accept with an encapsulated EAP Failure, it will grant access to the peer 🔓. But when the peer gets the EAP Failure, it thinks authentication failed 💔. If an Access-Accept or Access-Reject has no EAP-Message attribute, the peer might not find out the outcome at all, while the NAS still allows or denies access 🫥.
As described in [RFC2284], EAP Success and Failure packets are never acknowledged, and they end the EAP conversation 🔚. So if they're wrapped in an Access-Challenge, no response comes back, which means the NAS won't send any more Access-Requests to the RADIUS server for that session 🛑. The RADIUS server then never tells the NAS whether to allow or deny access, but the peer still hears the outcome of the authentication 😬.
To avoid these conflicts, a RADIUS server SHOULD NOT send any of the following combinations 📝:
Access-Accept/EAP-Message/EAP Failure
Access-Accept/no EAP-Message attribute
Access-Accept/EAP-Start
Access-Reject/EAP-Message/EAP Success
Access-Reject/no EAP-Message attribute
Access-Reject/EAP-Start
Access-Challenge/EAP-Message/EAP Success
Access-Challenge/EAP-Message/EAP Failure
Access-Challenge/no EAP-Message attribute
Access-Challenge/EAP-Startthe RADIUS server is the one responsible for avoiding conflicts, so the NAS MUST NOT "manufacture" EAP packets to fix contradictory messages it receives 🛠️. This behavior was originally required by [IEEE8021X], and it will be deprecated in the future 🌅.
2.6.4. Priority
a RADIUS Access-Accept or Access-Reject packet MAY contain EAP-Message attribute(s) 📬. To make sure RADIUS packets get processed correctly, the NAS MUST process the attributes, including the EAP-Message attribute(s), before it processes the Accept/Reject indication 🥇.
2.6.5. Displayable Messages 💬✨
Okay bestie, so the Reply-Message attribute (from [RFC2865], Section 5.18) carries text that can be shown to the peer 🫶. It's kinda like EAP Notification from [RFC2284]. When the RADIUS server wants to send a displayable message to a NAS during an EAP conversation, it MUST wrap that message inside EAP-Message/EAP-Request/Notification attribute(s) 🎀. Reply-Message attribute(s) MUST NOT show up in any RADIUS message that has an EAP-Message attribute, because that's just messy 🙈. And an EAP-Message/EAP-Request/Notification SHOULD NOT be included in an Access-Accept or Access-Reject packet 💅.
Some existing implementations let the NAS take the text out of a Reply-Message attribute, copy it into the Type-Data field of an EAP-Request/Notification packet, fill in the Identifier field, and send that to the peer. But ngl, this causes a few problems 😭:
- [1] Unexpected Responses. When the peer gets an EAP-Request/Notification, it sends back an EAP-Response/Notification. The NAS then forwards that to the RADIUS server inside EAP-Message attribute(s). The RADIUS server might not be expecting an Access-Request that has an
EAP-Message/EAP-Response/Notificationattribute 💀.
Here's the tea: say a Reply-Message shows up in an Access-Accept or Access-Reject packet with no EAP-Message attribute(s) at all. If that text gets copied into the Type-Data of an EAP-Request/Notification and sent to the peer, the NAS ends up sending an Access-Request containing an EAP-Message/EAP-Response/Notification attribute to the RADIUS server. Since an Access-Accept or Access-Reject packet ends the RADIUS conversation, that Access-Request is totally unexpected 🙃, and it could get read as the start of a brand new conversation 👀.
- [2] Identifier conflicts. An EAP-Request/Notification is an EAP packet with an Identifier field, but a Reply-Message attribute doesn't have one 😤. So a NAS that wants to turn a Reply-Message into an EAP-Request/Notification has to pick an Identifier value itself. That value could clash with one the RADIUS server already picked for another packet in the same EAP conversation, which could mix up a new packet with a retransmission 🌀.
To dodge all of this drama, a NAS that gets a Reply-Message attribute from the RADIUS server SHOULD silently discard the attribute, instead of trying to translate it into an EAP Notification Request 🧚✨.
3. Attributes 🎀
The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in Access-Request packets, and either NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address attributes MUST be included. Next, to let EAP-unaware proxies forward the Access-Reply, if the NAS put a User-Name attribute in an Access-Request, the RADIUS server MUST include the User-Name attribute in later Access-Accept packets 🌸. Without it, accounting and billing get really hard to manage 💸. The User-Name attribute in the Access-Accept packet doesn't have to match the one in the Access-Request.
3.1. EAP-Message 🦋
Description
This attribute carries EAP [RFC2284] packets, so the NAS can authenticate peers with EAP without needing to understand the EAP method it's passing along. It's giving layers, honestly 🧁.
The NAS puts EAP messages it receives from the authenticating peer into one or more EAP-Message attributes, then forwards them to the RADIUS server inside an Access-Request message. If there are multiple EAP-Message attributes in an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in that packet 📋. The RADIUS server can send EAP-Message attributes back in Access-Challenge, Access-Accept and Access-Reject packets 💌.
When RADIUS is used to enable EAP authentication, Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets SHOULD contain one or more EAP-Message attributes. If more than one EAP-Message attribute is included, the attributes are assumed to be concatenated to form a single EAP packet 🧩.
Multiple EAP packets MUST NOT be encoded within EAP-Message attributes that are in a single Access-Challenge, Access-Accept, Access-Reject or Access-Request packet 🚫.
EAP is expected to power a bunch of authentication methods, including ones with strong cryptography 🔐. To stop attackers from breaking EAP by going after RADIUS/EAP (for example, by changing EAP Success or EAP Failure packets) 😱, RADIUS has to provide per-packet authentication and integrity protection. Non-negotiable, bestie.
So the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets that contain an EAP-Message attribute 🛡️.
An Access-Request with EAP-Message attribute(s) but no Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server 🗑️. A RADIUS server that supports the EAP-Message attribute MUST calculate the correct value of the Message-Authenticator, and MUST silently discard the packet if it doesn't match the value sent. A RADIUS server that does NOT support the EAP-Message attribute MUST return an Access-Reject if it gets an Access-Request containing an EAP-Message attribute 🙅♀️.
Access-Challenge, Access-Accept, or Access-Reject packets with EAP-Message attribute(s) but no Message-Authenticator attribute SHOULD be silently discarded by the NAS 🫣. A NAS that supports the EAP-Message attribute MUST calculate the correct value of the Message-Authenticator, and MUST silently discard the packet if it doesn't match the value sent 🔍.
Here's a quick look at the EAP-Message attribute format. The fields are sent from left to right ➡️:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
79 for EAP-Message 🏷️
Length
>= 3 📏
String
The String field holds an EAP packet, as defined in [RFC2284]. If there are multiple EAP-Message attributes in a packet, their values should be concatenated, which lets RADIUS carry EAP packets longer than 253 octets 🚀.
3.2. Message-Authenticator 🔏
Description
This attribute MAY be used to authenticate and integrity-protect Access-Requests, which helps prevent spoofing 🕵️♀️. It MAY be used in any Access-Request. It MUST be used in any Access-Request, Access-Accept, Access-Reject or Access-Challenge that includes an EAP-Message attribute 🫶.
A RADIUS server that receives an Access-Request with a Message-Authenticator attribute present MUST calculate the correct value of the Message-Authenticator, and silently discard the packet if it doesn't match the value sent 🗑️.
A RADIUS client that receives an Access-Accept, Access-Reject or Access-Challenge with a Message-Authenticator attribute present MUST calculate the correct value of the Message-Authenticator, and silently discard the packet if it doesn't match the value sent 💫.
This attribute isn't required in Access-Requests that include the User-Password attribute, but it's super useful for stopping attacks on other kinds of authentication 🧠. It's meant to stop an attacker from setting up a "rogue" NAS and running online dictionary attacks against the RADIUS server 🕳️. It does NOT protect against "offline" attacks, where the attacker grabs packets with (for example) a CHAP challenge and response, then runs a dictionary attack on those packets offline 😤.
Here's the Message-Authenticator attribute format. Fields go from left to right ➡️:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
80 for Message-Authenticator 🏷️
Length
18 📏
String
When it's in an Access-Request packet, Message-Authenticator is an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet, including Type, ID, Length and Authenticator, using the shared secret as the key, like this 🔑:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)When the message integrity check is calculated, the signature string should be treated as sixteen octets of zero 0️⃣.
For Access-Challenge, Access-Accept, and Access-Reject packets, the Message-Authenticator is calculated as follows, using the Request-Authenticator from the Access-Request this packet is replying to 💌:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)When the message integrity check is calculated, the signature string should be treated as sixteen octets of zero. The shared secret is used as the key for the HMAC-MD5 message integrity check. The Message-Authenticator is calculated and inserted into the packet before the Response Authenticator is calculated 🎉.
3.3. Table of Attributes 📋
okay so this table is basically your cheat sheet 🧚 It tells you which attributes can show up in packets that carry EAP-Message attribute(s), and how many of each you get. Big heads up: the EAP-Message and Message-Authenticator attributes from this doc MUST NOT be present in an Accounting-Request 🙅♀️ And if a table entry is missing, the values from [RFC2548], [RFC2865], [RFC2868], [RFC2869] and [RFC3162] should be assumed 💅
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0 0 0 0 2 User-Password [Note 1]
0 0 0 0 3 CHAP-Password [Note 1]
0 0 0 0 18 Reply-Message
0 0 0 0 60 CHAP-Challenge
0 0 0 0 70 ARAP-Password [Note 1]
0 0 0 0 75 Password-Retry
1+ 1+ 1+ 1+ 79 EAP-Message [Note 1]
1 1 1 1 80 Message-Authenticator [Note 1]
0-1 0 0 0 94 Originating-Line-Info [Note 3]
0 0 0-1 0-1 101 Error-Cause [Note 2]
Request Accept Reject Challenge # AttributeNow the notes, which are where the drama is 🎀
[Note 1] okay this one is important bestie 🚨 An Access-Request that contains either a User-Password or CHAP-Password or ARAP-Password or one or more EAP-Message attributes MUST NOT contain more than one type of those four attributes. If it does not contain any of those four attributes, it SHOULD contain a Message-Authenticator. If any packet type contains an EAP-Message attribute it MUST also contain a Message-Authenticator. A RADIUS server receiving an Access-Request not containing any of those four attributes and also not containing a Message-Authenticator attribute SHOULD silently discard it 💀
[Note 2] The Error-Cause attribute is defined in [RFC3576] 📖
[Note 3] The Originating-Line-Info attribute is defined in [NASREQ] 📖
And here's what the entries actually mean, so you can read the table like a pro 👑
0 This attribute MUST NOT be present.
0+ Zero or more instances of this attribute MAY be present.
0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present.
1+ One or more of these attributes MUST be present.4. Security Considerations 🔐
Okay the security section is giving serious plot twist energy 😭 Read this one slowly, it's not a drill.
4.1. Security Requirements 🛡️
So RADIUS/EAP is what handles authentication and authorization for network access, which means both the RADIUS and EAP parts of the conversation are targets 🎯 The threats are discussed in [RFC2607], [RFC2865], and [RFC3162]. Here's the villain list:
[1] An adversary may attempt to acquire confidential data and identities by snooping RADIUS packets. 👀
[2] An adversary may attempt to modify packets containing RADIUS messages. ✏️
[3] An adversary may attempt to inject packets into a RADIUS conversation. 💉
[4] An adversary may launch a dictionary attack against the RADIUS shared secret. 📚
[5] An adversary may launch a known plaintext attack, hoping to recover the key stream corresponding to a Request Authenticator. 🔑
[6] An adversary may attempt to replay a RADIUS exchange. 🔁
[7] An adversary may attempt to disrupt the EAP negotiation, in order to weaken the authentication, or gain access to peer passwords. 🥀
[8] An authenticated NAS may attempt to forge NAS or session identification attributes, 🎭
[9] A rogue (unauthenticated) NAS may attempt to impersonate a legitimate NAS. 👤
[10] An attacker may attempt to act as a man-in-the-middle. 🕵️♀️
To deal with all of this, it is necessary to support confidentiality, data origin authentication, integrity, and replay protection on a per-packet basis ✨ Bi-directional authentication between the RADIUS client and server also needs to be provided. There is no requirement that the identities of RADIUS clients and servers be kept confidential (e.g., from a passive eavesdropper), so that part is kinda chill 🫶
4.2. Security Protocol 🔒
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 🔐
Within RADIUS [RFC2865], a shared secret is used for hiding attributes such as User-Password, as well as in computing the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computing both the Request Authenticator and the Response Authenticator 🧁
Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPSEC AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret 🤓
Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret ⚠️
When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform 🚫
A typical IPsec policy for an IPsec-capable RADIUS client is Initiate IPsec, from me to any destination port UDP 1812. This causes an IPsec SA to be set up by the RADIUS client before it sends any RADIUS traffic. If some RADIUS servers contacted by the client don't support IPsec, then you'll need a more granular policy: Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812 🎯
For an IPsec-capable RADIUS server, a typical IPsec policy is Accept IPsec, from any to me, destination port 1812. This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec 🙈
Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role 🪪
RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec 🏰
Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec 🏰
Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployments supporting only certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client 📜
Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), IKE Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group pre-shared key. Instead, Aggressive Mode SHOULD be used. IKEv2, a work in progress, may address this issue in the future. Where RADIUS client addresses are statically assigned, either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used 🛜
Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers 🧠
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling of RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983] 🎀
4.3. Security Issues 🧩
This section gives you more detail on the vulnerabilities identified in Section 4.1., and how they may be mitigated. The vulnerabilities include:
- Privacy issues 🤫
- Spoofing and hijacking 🎭
- Dictionary attacks 📚
- Known plaintext attacks 🔑
- Replay attacks 🔁
- Negotiation attacks 🤝
- Impersonation 👤
- Man in the middle attacks 🕵️♀️
- Separation of authenticator and authentication server 🧱
- Multiple databases 🗄️
4.3.1. Privacy Issues 📍
okay bestie, let's talk privacy 🫣 RADIUS messages can carry the User-Name attribute along with NAS-IP-Address or NAS-Identifier attributes, so an attacker snooping on RADIUS traffic might be able to figure out where peers are in real time. people often assume RADIUS is physically secure on wireless networks because it usually travels over the wired network, and that's supposed to limit how much location info leaks 🙈
but here's the plot twist 😭 an authenticated attacker can spoof ARP packets [RFC826] to divert RADIUS traffic onto the wireless network. then they can grab RADIUS packets, glean peer location info from them, or run a known plaintext or offline dictionary attack on them 💀 to shut this down, implementations of this specification SHOULD use IPsec ESP with non-null transform and per-packet encryption, authentication, integrity and replay protection to protect both RADIUS authentication [RFC2865] and accounting [RFC2866] traffic, as described in Section 4.2 🔐
4.3.2. Spoofing and Hijacking 🕵️
so Access-Request packets with a User-Password attribute establish the identity of both the user and the NAS, because of how the shared secret between the NAS and RADIUS server gets used 🔑 Access-Request packets with CHAP-Password or EAP-Message attributes don't have a User-Password attribute, though. so the Message-Authenticator attribute SHOULD be used in Access-Request packets that don't have a User-Password attribute, so the NAS sending the request can be identified 🫶
an attacker might try to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the security server 👀 RADIUS [RFC2865] doesn't support encryption beyond attribute hiding. as described in [RFC2865], only Access-Reply and Access-Challenge packets are integrity protected. and the per-packet authentication and integrity protection mechanism in [RFC2865] has known weaknesses [MD5Attack], which makes it a tempting target for anyone trying to subvert RADIUS/EAP 😈
to level up the security, the Message-Authenticator attribute MUST be used in all RADIUS packets containing an EAP-Message attribute 🛡️ implementations of this specification SHOULD also use IPsec ESP with non-null transform and per-packet encryption, authentication, integrity and replay protection, as described in Section 4.2 ✨
4.3.3. Dictionary Attacks 🔤
the RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response Authenticator or Message-Authenticator attribute 😬 to lower that risk, [RFC2865] recommends the following, word for word:
The secret (password shared between the client and the RADIUS
server) SHOULD be at least as large and unguessable as a
well-chosen password. It is preferred that the secret be at least
16 octets.the risk of an offline dictionary attack can be cut down even more by using IPsec ESP with non-null transform to encrypt the RADIUS conversation, as described in Section 4.2 🌸
4.3.4. Known Plaintext Attacks 🧩
okay this one is a little spicy 🌶️ since EAP [RFC2284] doesn't support PAP, the RADIUS User-Password attribute isn't used to carry hidden user passwords within RADIUS/EAP conversations. but the User-Password hiding mechanism, defined in [RFC2865], uses MD5 [RFC1321] to generate a key stream from the RADIUS shared secret and the Request Authenticator. where PAP is in use, someone can collect key streams for a given Request Authenticator value by capturing RADIUS conversations from a PAP authentication attempt made with a known password. since the User-Password is known, the key stream for that Request Authenticator can be worked out and stored 😱
so if the Request Authenticator repeats, attributes encrypted with the RADIUS attribute hiding mechanism should be considered compromised 💔 that includes more than the User-Password attribute (which isn't used with EAP). it also covers things like Tunnel-Password [RFC2868, section 3.5] and the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes [RFC2548, section 2.4], which include a Salt field as part of the hiding algorithm.
to avoid all this drama, [RFC2865], Section 3 advises:
Since it is expected that the same secret MAY be used to
authenticate with servers in disparate geographic regions, the
Request Authenticator field SHOULD exhibit global and temporal
uniqueness.even with the Salt field defined in [RFC2548], Section 2.4, a repeated Request Authenticator doesn't save you 😭 that's because MD5 [RFC1321] is used to make the key stream, not HMAC-MD5 [RFC2104]. the key stream is calculated from the 128-bit RADIUS shared secret (S), the 128-bit Request Authenticator (R), and the Salt field (A), using the formula b(1) = MD5(S + R + A). the Salt goes at the end, and it's sent in the clear. so if the Request Authenticator repeated on a network where PAP is in use, the salted key stream could be worked out from the User-Password key stream by continuing the MD5 calculation with the Salt field 🙃
and even though EAP doesn't do PAP, things can still go wrong if the same RADIUS shared secret is used to hide User-Password and other attributes. this can happen, for example, when the same RADIUS proxy handles authentication requests for both EAP and PAP 🫠
the threat can be mitigated by protecting RADIUS with IPsec ESP with non-null transform, as described in Section 4.2. where RADIUS shared secrets are configured, the RADIUS shared secret used by a NAS supporting EAP MUST NOT be reused by a NAS utilizing the User-Password attribute, since improper shared secret hygiene could lead to compromise of hidden attributes. keep your secrets separate, bestie 🔐💅
4.3.5. Replay Attacks 🔁
RADIUS only gives limited support for replay protection, sadly 😩 RADIUS Access-Requests get liveness from the 128-bit Request Authenticator. however, the Request Authenticator is not a replay counter. since RADIUS servers may not keep a cache of previous Request Authenticators, the Request Authenticator doesn't provide replay protection either.
RADIUS accounting [RFC2866] doesn't support replay protection at the protocol level. because accounting servers need to be able to fail over between each other, protocol-based replay protection isn't enough to stop duplicate accounting records 📑 the good news is that once the accounting server has accepted a record, duplicates can be spotted using the Acct-Session-Id [RFC2866, section 5.5] and Event-Timestamp [RFC2869, section 5.3] attributes 🎀
accounting is a different beast from authentication 🧐 RADIUS accounting doesn't use the Request Authenticator as a nonce. instead, the Request Authenticator holds an MD5 hash calculated over the Code, Identifier, Length, and request attributes of the Accounting Request packet, plus the shared secret. the Response Authenticator also holds an MD5 hash, calculated over the Code, Identifier and Length, the Request Authenticator field from the Accounting-Request packet being replied to, the response attributes, and the shared secret.
since the Accounting Response Authenticator depends partly on the Accounting Request Authenticator, you can't replay an Accounting-Response unless the Request Authenticator repeats 🙌 EAP methods like EAP TLS [RFC2716] include liveness checks on both sides, which helps. but not all EAP messages include liveness, so that only gives you incomplete protection 🥲
for strong replay protection on RADIUS authentication and accounting, turn on IPsec replay protection with RADIUS, as described in Section 4.2 👑
4.3.6. Negotiation Attacks 💅
Okay so a negotiation attack is when a sneaky rogue NAS, tunnel server, RADIUS proxy or RADIUS server tries to trick the authenticating peer into picking a less secure authentication method 🙅♀️. A session that should totally be authenticated with EAP could get pushed down to CHAP or PAP instead 💀. Or a connection that would normally use a strong EAP method like EAP-TLS [RFC2716] could get forced onto something weaker like MD5-Challenge. Rogue devices used to feel like a far-away problem, but after compromises of telephone company switching systems, such as those described in [Masters], it's giving very not-far-away 😭.
Protection against negotiation attacks requires the elimination of downward negotiations 🔒. The RADIUS exchange may be further protected by use of IPsec, as described in Section 4.2 ✨. If IPsec isn't in the picture, the vulnerability can be mitigated with per-connection policy on the authenticating peer's side and per-peer policy on the RADIUS server's side 🦋. For the authenticating peer, authentication policy should be set on a per-connection basis. That way it can negotiate a strong EAP method for one service and a weaker one for another, which is very much a different-services-different-vibes situation 🎀.
With per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected 🌸. So there's a presumption that a peer selecting EAP requires that level of security. If it can't be provided, it's likely there's some kind of misconfiguration, or even that the authenticating peer is contacting the wrong server 🙈. Should the NAS not be able to negotiate EAP, or should the EAP-Request sent by the NAS be of a different EAP type than what is expected, the authenticating peer MUST disconnect. An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate a weaker method, such as CHAP or PAP. In wireless networks, the service advertisement itself may be spoof-able, so an attacker could fool the peer into negotiating an authentication method suitable for a less secure network 👀.
For a NAS, it may not be possible to determine whether a peer is required to authenticate with EAP until the peer's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. Alternatively, some peer might be authenticated locally by the NAS while other peers are authenticated via RADIUS. In such cases, if any peers of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every session. This avoids forcing a peer to support more than one authentication type, which could weaken security 🍓.
If CHAP is negotiated, the NAS will pass the User-Name and CHAP-Password attributes to the RADIUS server in an Access-Request packet. If the peer is not required to use EAP, then the RADIUS server will respond with an Access-Accept or Access-Reject packet as appropriate. However, if CHAP has been negotiated but EAP is required, the RADIUS server MUST respond with an Access-Reject, rather than an Access-Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST refuse to renegotiate authentication, even if the renegotiation is from CHAP to EAP 🚫.
If EAP is negotiated but is not supported by the RADIUS proxy or server, then the server or proxy MUST respond with an Access-Reject. In these cases, a PPP NAS MUST send an LCP-Terminate and disconnect the peer. This is the correct behavior, since the authenticating peer is expecting EAP to be negotiated, and that expectation cannot be fulfilled 🙌. An EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose 🥲. A peer connecting from one location (with an EAP-capable proxy) might successfully authenticate via EAP, while the same peer connecting at another location (and hitting an EAP-incapable proxy) might be consistently disconnected.
4.3.7. Impersonation 🎭
[RFC2865] Section 3 states:
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address attributes may not match the source address. Since the NAS-Identifier attribute need not contain an FQDN, this attribute also may not correspond to the source address, even indirectly, with or without a proxy present 🤷♀️.
As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification attributes. This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within a RADIUS Access-Request in order to impersonate another NAS. It's also possible for a rogue NAS to forge session identification attributes such as Called-Station-Id, Calling-Station-Id, and Originating-Line-Info 😱.
This could fool the RADIUS server into subsequently sending Disconnect or CoA-Request messages [RFC3576] containing forged session identification attributes to a NAS targeted by an attacker. Yikes, that's a whole plot twist 💀.
To address these vulnerabilities, RADIUS proxies SHOULD check whether NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address, NAS-Identifier) match the source address of packets originating from the NAS. Where a match is not found, an Access-Reject SHOULD be sent, and an error SHOULD be logged 🚨.
However, such a check may not always be possible. Since the NAS-Identifier attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS-IP-Address or NAS-IPv6-Address attributes may not be feasible 🙃.
To allow verification of NAS and session identification parameters, EAP methods can support the secure exchange of these parameters between the EAP peer and EAP server ✨. NAS identification attributes include NAS-IP-Address, NAS-IPv6-Address and Called-Station-Id. Session identification attributes include User-Name and Calling-Station-Id. The secure exchange of these parameters between the EAP peer and server enables the RADIUS server to check whether the attributes provided by the NAS match those provided by the peer. Similarly, the peer can check the parameters provided by the NAS against those provided by the EAP server. This enables detection of a rogue NAS 🕵️♀️.
4.3.8. Man in the Middle Attacks 👥
RADIUS only provides security on a hop-by-hop basis, even where IPsec is used. As a result, an attacker gaining control of a RADIUS proxy could attempt to modify EAP packets in transit 😵. To protect against this, EAP methods SHOULD incorporate their own per-packet integrity protection and authentication mechanisms 🔐.
4.3.9. Separation of Authenticator and Authentication Server 🧩
As noted in [RFC2716], it is possible for the EAP peer and authenticator to mutually authenticate, and derive a Master Session Key (MSK) for a ciphersuite used to protect subsequent data traffic. This doesn't present an issue on the peer, since the peer and EAP client reside on the same machine. All that's required is for the EAP client module to derive and pass a Transient Session Key (TSK) to the ciphersuite module 🧁.
The situation is more complex when EAP is used with RADIUS, since the authenticator and authentication server may not reside on the same host 🌍.
In the case where the authenticator and authentication server reside on different machines, there are several implications for security. First, mutual authentication will occur between the peer and the authentication server, not between the peer and the authenticator. This means it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to, using EAP alone 🙀.
As described in Section 4.2, when RADIUS/EAP is used to encapsulate EAP packets, IPsec SHOULD be used to provide per-packet authentication, integrity, replay protection and confidentiality 🛡️. The Message-Authenticator attribute is also required in RADIUS Access-Requests containing an EAP-Message attribute sent from the NAS or tunnel server to the RADIUS server. Since the Message-Authenticator attribute involves an HMAC-MD5 message integrity check, it is possible for the RADIUS server to verify the integrity of the Access-Request as well as the NAS or tunnel server's identity, even where IPsec is not used. Similarly, Access-Challenge packets containing an EAP-Message attribute sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 message integrity check. This enables the NAS or tunnel server to determine the integrity of the packet and verify the identity of the RADIUS server, even where IPsec is not used. Moreover, EAP packets sent using methods that contain their own integrity protection cannot be successfully modified by a rogue NAS or tunnel server 💖.
The second issue that arises where the authenticator and authentication server reside on separate hosts is that the EAP Master Session Key (MSK) negotiated between the peer and authentication server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the MSK from the authentication server to the NAS or tunnel server that needs it. The specification of the key transport and wrapping mechanism is outside the scope of this document. However, it is expected that the wrapping mechanism will provide confidentiality, integrity and replay protection, and data origin authentication 🔑.
4.3.10. Multiple Databases 🗂️
In many cases a security server will be deployed along with a RADIUS server in order to provide EAP services. Unless the security server also functions as a RADIUS server, two separate user databases will exist, each containing information about the security requirements for the user. This is a weakness, since security may be compromised by a successful attack on either of the servers, or on their databases 😬. With multiple user databases, adding a new user may require multiple operations, which increases the chances for error. The problems are further magnified in the case where user information is also being kept in an LDAP server. In that case, three stores of user information may exist. Three! 🙃
In order to address these threats, consolidation of databases is recommended. This can be achieved by having both the RADIUS server and security server store information in the same database; by having the security server provide a full RADIUS implementation; or by consolidating both the security server and the RADIUS server onto the same machine 🌈.
5. IANA Considerations 📋
This specification does not create any new registries, or define any new RADIUS attributes or values 🫶.
6. References 📚
6.1. Normative References 📚
These are the must-read docs for this spec, bestie. Everything below is the normative reference list, with all the details kept.
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
- [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
- [RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
- [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
- [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
- [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", 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.
6.2. Informative References 🌸
These are the extra-credit reads. They're super helpful for background, but they're not required to get the core idea.
- [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, November 1982.
- [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
- [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
- [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.
- [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.
- [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
- [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
- [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990.
- [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.
- [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
- [Masters] Slatalla, M. and J. Quittner, "Masters of Deception." HarperCollins, New York, 1995.
- [NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
Appendix A - Examples 🎀
Okay, so this appendix is basically a bunch of little stories 📖 between three characters: the authenticating peer, the NAS, and the RADIUS server. The OTP and EAP-TLS bits are just there to make things concrete. Other authentication protocols could totally have been used instead, though they might act a little differently 💅.
First up, the NAS sends an EAP-Request/Identity as its very first packet, and the exchange goes like this:
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-SuccessNext, the NAS kicks things off with an EAP-Request for EAP TLS [RFC2716], and the identity gets worked out from the contents of the client certificate. It's giving full cert drama 🔐:
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=EAP-TLS
(TLS client_hello)->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Challenge/
EAP-Message/
EAP-Request/
EAP-Type=EAP-TLS
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=EAP-TLS
(TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Challenge/
EAP-Message/
EAP-Request/
EAP-Type=EAP-TLS
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=EAP-TLS ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=EAP-TLS->
<-RADIUS Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-SuccessNow the NAS sends an EAP-Start packet to the RADIUS server first. Plot twist 🦋:
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Identity (MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-SuccessLast one, and it's a little messy 🙈. The NAS starts with an EAP-Request for EAP TLS [RFC2716], but the peer replies with a Nak, saying it would rather use another method that the NAS doesn't have locally:
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=EAP-TLS
(TLS Start, S bit set)
EAP-Response/
EAP-Type=Nak
(Alternative(s))->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Nak ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/Okay, so the first conversation picks up right where we left off, with the OTP exchange wrapping up. 🎀
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- EAP-SuccessNow flip it around! 🔄 When the authenticating peer is the one trying to authenticate the NAS, the convo goes like this 💅:
Authenticating peer NAS RADIUS Server
------------------- --- -------------
EAP-Request/
Challenge, MD5 ->
RADIUS Access-Request/
EAP-Message/EAP-Request/
Challenge, MD5 ->
<- RADIUS
Access-Reject/
EAP-Message/
EAP-Response/
Nak (no alternative)
<- EAP-Response/Nak
(no alternative)
EAP-Failure ->Next up is the sneaky one 🙈 An attacker jumps in and inserts an invalid EAP Response, and it's giving plot twist. Watch how the good guy's real response still gets through in the end 👑:
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- EAP-Request/
EAP-Type=Foo
EAP-Response/
EAP-Type=Foo ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Foo ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
EAP-Type=Foo
<- EAP-Request/
EAP-Type=Foo
Attacker spoof:
EAP-Response/
EAP-Type=Bar ->
Good guy:
EAP-Response/
EAP-Type=Foo ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Bar ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
EAP-Type=Foo,
Error-Cause="Invalid EAP
Packet (Ignored)"
RADIUS Access-Request/
EAP-Message/EAP-Response/
EAP-Type=Foo ->
<- Access-Accept/
EAP-Message/Success
<- EAP SuccessNow the client fails EAP auth 😭, but before it disconnects, it gets an error message. Sad, but at least it's informative. 🥀
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Response/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- EAP-Request/
OTP/OTP Challenge
EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request/
Notification
<- EAP-Request/
Notification
EAP-Response/
Notification ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
Notification ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure
<- EAP-Failure
(client disconnected)Here's a case where the RADIUS server or proxy doesn't support EAP-Message, and no error message gets sent back. Ghosted, basically 👻:
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Reject
(User Disconnected)Next, the local RADIUS server does support EAP-Message, but the remote one doesn't 🧚. So the local server's challenge gets relayed along, and the remote server's reject comes back through the proxy:
Authenticating peer NAS RADIUS server
------------------- --- -------------
RADIUS Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/
EAP-Response/
Identity
<- EAP-Request/
Identity
EAP-Response/
Identity
(MyID) ->
RADIUS Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Reject
(proxied from remote
RADIUS server)
(User Disconnected)Now PPP is the link, and the authenticating peer doesn't speak EAP at all, even though EAP is required for that user. 🙅♀️ So the NAS basically says "no EAP, no entry," and the attempt gets rejected:
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)And last but not least, PPP is the link, the NAS doesn't support EAP at all, and EAP is required for that user. Same vibe, different starting point 🌸:
Authenticating peer NAS RADIUS server
------------------- --- -------------
<- PPP LCP Request-CHAP
auth
PP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)Appendix B - Change Log ✨
Here's what changed since RFC 2869, bestie 📝:
- A NAS may simultaneously support both local authentication and pass-through; once the NAS enters pass-through mode within a session, it cannot revert back to local authentication. Also EAP is explicitly described as a 'lock step' protocol. (Section 2).
- The NAS may initiate with an EAP-Request for an authentication Type. If the Request is NAK'd, the NAS should send an initial Access-Request with an EAP-Message attribute containing an EAP-Response/Nak.
- The RADIUS server may treat an invalid EAP Response as a non-fatal error (Section 2.2)
- For use with RADIUS/EAP, the Password-Retry (Section 2.3) and Reply-Message (2.6.5) attributes are deprecated. 💀
- Each EAP session has a unique Identifier space (Section 2.6.1).
- Role reversal is not supported (Section 2.6.2).
- Message combinations (e.g. Access-Accept/EAP-Failure) that conflict are discouraged (Section 2.6.3).
- Only a single EAP packet may be encapsulated within a RADIUS message (Section 3.1).
- An Access-Request lacking explicit authentication as well as a Message- Authenticator attribute SHOULD be silently discarded (Section 3.3).
- The Originating-Line-Info attribute is supported (Section 3.3).
- IPsec ESP with non-null transform SHOULD be used and the usage model is described in detail (Section 4.2).
- Additional discussion of security vulnerabilities (Section 4.1) and potential fixes (Section 4.3).
- Separated normative (Section 6.1) and informative (Section 6.2) references.
- Added additional examples (Appendix A): a NAS initiating with an EAP-Request for an authentication Type; attempted role reversal. 🎉
Intellectual Property Statement 📜
Okay, legal-ish stuff, but it matters 🫶. The IETF doesn't take a position on whether any intellectual property or other rights that someone might claim over the tech in this doc are valid or how far they reach. It also doesn't say it has looked for any such rights. If you want the IETF's rules on rights for standards-track and standards-related docs, go check BCP-11. Claims of rights that have been filed for publication, plus any promised licenses, or the outcome of anyone trying to get a general license or permission to use those proprietary rights, can be requested 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 let them know. Send that info to the IETF Executive Director. 💌
Acknowledgments 🌈
Huge thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco Systems, Jari Arkko of Ericsson, and Ashwin Palekar, Tim Moore, and Narendra Gidwani of Microsoft for the super useful chats about this problem space. The authors also want to shout out Tony Jeffree, Chair of IEEE 802.1, for helping sort out the RADIUS/EAP issues in IEEE 802.1X-2001. 👑✨
Authors' Addresses ✨
Okay bestie, here are the people who wrote this thing 🫶 Bernard Aboba was at Microsoft Corporation, and Pat R. Calhoun was at Airespace. Their contact info is below, exactly as it was written:
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 706 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Pat R. Calhoun
Airespace
110 Nortech Parkway
San Jose, California, 95134
USA
Phone: +1 408 635 2023
Fax: +1 408 635 2020
EMail: pcalhoun@airespace.comFull Copyright Statement 💅
Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸
Okay, legal stuff, but it's actually chill 🙈 You can copy and share this document, and you can even share translations of it. You're also allowed to make derivative works that comment on it, explain it, or help people implement it, and you can publish and distribute those too, in whole or in part, with no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work.
The document itself can't be modified in any way, though. You can't remove the copyright notice, and you can't take out the references to the Internet Society or other Internet organizations. The exceptions are when you need to modify it to develop Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or when you need to translate it into languages other than English.
The limited permissions above are perpetual, meaning the Internet Society and its successors or assignees will never revoke them 🦋
This document and the info in it is provided on an "AS IS" basis, and the Internet Society and the Internet Engineering Task Force disclaim all warranties. Here is that part in its exact wording, because it matters:
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. So the Internet Society keeps the RFC Editor running, which is honestly iconic 👑
📦 where this page comes from
- ietf: rfc3579 2003-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms