RFC 4072
Diameter Extensible Authentication Protocol (EAP) Application
RFC 4072 💖 Diameter Extensible Authentication Protocol (EAP) Application
okay so this is the RFC that makes EAP work over Diameter 🎀 It's from the Network Working Group, and it's a Standards Track document, which means it's an official protocol spec and not just someone's opinion 💅 It was dated August 2005. The authors are P. Eronen, Ed. (Nokia), T. Hiller (Lucent Technologies), and G. Zorn (Cisco Systems) 🫶 The header doesn't list anything it obsoletes or updates ✨
Status of This Memo
this part is the official-y bit, but it matters 🧚 This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋
Copyright Notice
Copyright (C) The Internet Society (2005). 🌈
Abstract
so EAP gives you a standard way to support lots of different authentication methods 🔥 This document defines the Command-Codes and AVPs needed to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server 💜
Table of Contents
1. Introduction ...................................................2
1.1. Conventions Used in This Document ........................3
2. Extensible Authentication Protocol Support in Diameter .........3
2.1. Advertising Application Support ..........................3
2.2. Protocol Overview ........................................4
2.3. Sessions and NASREQ Interaction ..........................6
2.3.1. Scenario 1: Direct Connection .....................7
2.3.2. Scenario 2: Direct Connection with Redirects ......8
2.3.3. Scenario 3: Direct EAP, Authorization via Agents ..9
2.3.4. Scenario 4: Proxy Agents .........................10
2.4. Invalid Packets .........................................10
2.5. Retransmission ..........................................11
2.6. Fragmentation ...........................................12
2.7. Accounting ..............................................12
2.8. Usage Guidelines ........................................13
2.8.1. User-Name AVP ....................................13
2.8.2. Conflicting AVPs .................................13
2.8.3. Displayable Messages .............................14
2.8.4. Role Reversal ....................................14
2.8.5. Identifier Space .................................14
3. Command-Codes .................................................14
3.1. Diameter-EAP-Request (DER) Command ......................15
3.2. Diameter-EAP-Answer (DEA) Command .......................16
4. Attribute-Value Pairs .........................................18
4.1. New AVPs ................................................18
4.1.1. EAP-Payload AVP ..................................18
4.1.2. EAP-Reissued-Payload AVP .........................18
4.1.3. EAP-Master-Session-Key AVP .......................19
4.1.4. EAP-Key-Name AVP .................................19
4.1.5. Accounting-EAP-Auth-Method AVP ...................19
5. AVP Occurrence Tables .........................................19
5.1. EAP Command AVP Table ...................................20
5.2. Accounting AVP Table ....................................21
6. RADIUS/Diameter Interactions ..................................22
6.1. RADIUS Request Forwarded as Diameter Request ............22
6.2. Diameter Request Forwarded as RADIUS Request ............23
6.3. Accounting Requests .....................................24
7. IANA Considerations ...........................................24
8. Security Considerations .......................................24
8.1. Overview ................................................24
8.2. AVP Editing .............................................26
8.3. Negotiation Attacks .....................................27
8.4. Session Key Distribution ................................28
8.5. Privacy Issues ..........................................28
8.6. Note about EAP and Impersonation ........................29
9. Acknowledgements ..............................................29
10. References ....................................................30
10.1. Normative References ....................................30
10.2. Informative References ..................................301. Introduction ✨
okay so EAP is defined in [EAP], and it's an authentication framework that supports multiple authentication mechanisms 💅 It works on dedicated links, switched circuits, and wired as well as wireless links, so it's very flexible 🦋
so far EAP has been used with hosts and routers that connect via switched circuits or dial-up lines using PPP [RFC1661], with IEEE 802 wired switches [IEEE-802.1X], and with IEEE 802.11 wireless access points [IEEE-802.11i] 🌸 It has also been adopted for IPsec remote access in IKEv2 [IKEv2] 🔥
this document specifies the Diameter EAP application, which carries EAP packets between a Network Access Server (NAS) working as an EAP Authenticator and a back-end authentication server 🎀 It's based on the Diameter Network Access Server Application [NASREQ] and is meant for environments similar to NASREQ 💜
in the Diameter EAP application, authentication happens between the EAP client and its home Diameter server 🫶 This end-to-end authentication lowers the chance of fraudulent authentication, like replay and man-in-the-middle attacks 🙈 It also allows mutual authentication, which PAP and CHAP can't do in a roaming PPP environment. Main character energy 👑
the Diameter EAP application relies heavily on [NASREQ], and in earlier versions it was part of the Diameter NASREQ application 🧚 It can also be used together with NASREQ, picking the application based on the user authentication mechanism (EAP or PAP/CHAP). It defines new Command-Codes and Attribute-Value Pairs (AVPs), and it can work together with RADIUS EAP support [RFC3579] 🍓
1.1. Conventions Used in This Document
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 🫶
2. Extensible Authentication Protocol Support in Diameter 💖
2.1. Advertising Application Support
okay this is the part where nodes say "hey, I can do EAP" 🙌 Diameter nodes that conform to this specification MUST advertise support by including the Diameter EAP Application ID value of 5 in the Auth-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [BASE] ✨
if the NAS gets a response with the Result-Code set to DIAMETER_APPLICATION_UNSUPPORTED [BASE], it means the Diameter server in the home realm doesn't support EAP 💀 If possible, the access device MAY try to negotiate another authentication protocol, like PAP or CHAP 🌈 An access device SHOULD be cautious when deciding whether a less secure authentication protocol gets used, since this could be the result of a downgrade attack (see Section 8.3) 🚨 downgrade attacks are not it, bestie 😭
(part 1 of 8, more coming soon 🧚💜)
2.2. Protocol Overview 🌸
okay bestie, so the EAP convo kicks off once EAP gets started inside a link layer, like PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i] ✨. Once EAP is up and running, the access device usually sends a Diameter-EAP-Request with an empty EAP-Payload AVP to the Diameter server. That's basically an EAP-Start 🦋
If the Diameter home server is willing to do EAP auth, it replies with a Diameter-EAP-Answer carrying an EAP-Payload AVP with an encapsulated EAP packet inside 💌. The Result-Code AVP gets set to DIAMETER_MULTI_ROUND_AUTH, which basically means "more rounds incoming, don't leave yet" 💅. The access device then forwards the EAP payload to the EAP client. Here's the vibe:
User NAS Server
| | |
| (initiate EAP) | |
|<------------------------------>| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Start) |
| |------------------------------->|
| | |
| | Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| | EAP-Payload(EAP Request #1) |
| |<-------------------------------|
| EAP Request #1 | |
|<-------------------------------| |
: : :
: ...continues... :The first Diameter-EAP-Answer in a multi-round exchange usually includes an EAP-Request/Identity, asking the EAP client to say who they are 🪪. When the client sends back its EAP-Response, the access device fires off a second Diameter-EAP-Request, with the client's EAP payload tucked inside the EAP-Payload AVP.
The preferred move is for the access device to send the EAP-Request/Identity to the client itself, then forward the EAP-Response/Identity packet, wrapped in the EAP-Payload AVP, as a Diameter-EAP-Request to the server (peep the diagram below 👀). This cuts down on the number of Diameter message round trips 🏎️. When the access device issues the EAP-Request/Identity, it SHOULD interpret the EAP-Response/Identity packet returned by the peer, and copy its value into a User-Name AVP in the Diameter-EAP-Request. This is clutch in roaming environments, because the Destination-Realm is needed for routing 🗺️. Just know this move can't be used everywhere, since there are situations where the user's identity isn't needed at all (like when authorization is based on a calling or called phone number) 📞.
User NAS Server
| | |
| (initiate EAP) | |
|<------------------------------>| |
| | |
| EAP Request(Identity) | |
|<-------------------------------| |
| | |
| EAP Response(Identity) | |
|------------------------------->| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Response) |
| |------------------------------->|
: : :
: ...continues... :The convo keeps going until the Diameter server sends a Diameter-EAP-Answer with a Result-Code AVP showing success or failure, plus an optional EAP-Payload 🎭. The access device uses the Result-Code AVP to decide whether service gets provided to the EAP client. The access device MUST NOT rely on the contents of the optional EAP-Payload to make that call 🚫.
: ...continued... :
: : :
| EAP Response #N | |
|------------------------------->| |
| | Diameter-EAP-Request |
| | EAP-Payload(EAP Response #N) |
| |------------------------------->|
| | |
| | Diameter-EAP-Answer |
| | Result-Code=DIAMETER_SUCCESS |
| | EAP-Payload(EAP Success) |
| | [EAP-Master-Session-Key] |
| | (authorization AVPs) |
| |<-------------------------------|
| | |
| EAP Success | |
|<-------------------------------| |If authorization was requested, a Diameter-EAP-Answer with Result-Code set to DIAMETER_SUCCESS SHOULD also include the right authorization AVPs for the requested service (see Section 5 and [NASREQ]) 🎁. Sometimes the home server can't provide all the necessary authorization AVPs. In that case, a separate authorization step MAY be used, as described in Section 2.3.3. And Diameter-EAP-Answer messages with Result-Code set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs 💜.
A Diameter-EAP-Answer with a successful Result-Code MAY also include an EAP-Master-Session-Key AVP. That holds keying material for protecting the communication between the user and the NAS 🔐. How that keying material gets used depends on the link layer in question, and that's beyond the scope of this document 🙅♀️.
A home Diameter server MAY request EAP re-authentication by issuing a Re-Auth-Request [BASE] message to the Diameter client 🔁.
If an EAP authentication session gets interrupted by a home server failure, the session MAY be directed to an alternate server 🏃♀️. But the authentication session will have to be restarted from the beginning 😭.
2.3. Sessions and NASREQ Interaction 🧩
The previous section covered the basic protocol between the NAS and the home server 📖. Since the Diameter-EAP-Answer message may include a Master Session Key (MSK) for protecting the communication between the user and the NAS, we really have to make sure that key doesn't fall into the wrong hands 🕵️♀️.
Basic Diameter security mechanisms (IPsec and TLS) protect Diameter messages hop-by-hop 🔒. There aren't any end-to-end (NAS-to-home server) security mechanisms defined for Diameter yet, so this section walks through possible scenarios for how the messages could be transport protected using those hop-by-hop mechanisms 💫.
This list of scenarios isn't meant to be exhaustive, and you can mix them up 🍹. For instance, the first proxy agent after the NAS could use redirects like in Scenario 2 to bypass any extra proxy agents 🦋.
2.3.1. Scenario 1: Direct Connection 🎯
The simplest case is when the NAS contacts the home server directly. All the authorization AVPs and EAP keying material get delivered by the home server ✨.
NAS home server
| |
| Diameter-EAP-Request |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) |
|---------------------------------------------------------------->|
| |
| Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| EAP-Payload(EAP Request) |
|<----------------------------------------------------------------|
| |
: ...more EAP Request/Response pairs... :
| |
| Diameter-EAP-Request |
| EAP-Payload(EAP Response) |
|---------------------------------------------------------------->|
| |
| Diameter-EAP-Answer |
| Result-Code=DIAMETER_SUCCESS |
| EAP-Payload(EAP Success) |
| EAP-Master-Session-Key |
| (authorization AVPs) |
|<----------------------------------------------------------------|This one's most likely to show up in small networks, or anywhere Diameter agents aren't needed to provide routing or extra authorization AVPs 💖.
2.3.2. Scenario 2: Direct Connection with Redirects
okay so in this scenario, the NAS uses a redirect agent to find the home server 🧭 The rest of the session proceeds as before 💖
NAS Local redirect agent Home server
| | |
| Diameter-EAP-Request | |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) | |
|------------------------------->| |
| | |
| Diameter-EAP-Answer |
| Redirect-Host=homeserver.example.com |
| Redirect-Host-Usage=REALM_AND_APPLICATION |
|<-------------------------------| |
| : |
| Diameter-EAP-Request : |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) : |
|---------------------------------------------------------------->|
| : |
: ...rest of the session continues as in first case... :
: : :The advantage here is that knowledge of realms and home servers is centralized in a redirect agent 🦋 So you don't have to touch the NAS config when, for example, a new roaming agreement is made 🎀
2.3.3. Scenario 3: Direct EAP, Authorization via Agents
In this one, the EAP authentication is done directly with the home server (with Auth-Request-Type set to AUTHENTICATE_ONLY) 🔐 and the authorization AVPs get pulled from local proxy agents 🌸 This scenario is meant for environments where the home server can't give the NAS all the authorization AVPs it needs 🫶
NAS Local proxy agent Home server
| : |
| Diameter-EAP-Request : |
| Auth-Request-Type=AUTHENTICATE_ONLY |
| EAP-Payload(EAP Start) : |
|---------------------------------------------------------------->|
| : |
| : Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| : EAP-Payload(EAP Request) |
|<----------------------------------------------------------------|
| : |
: ...more EAP Request/Response pairs... :
| : |
| Diameter-EAP-Request : |
| EAP-Payload(EAP Response) : |
|---------------------------------------------------------------->|
| : |
| : Diameter-EAP-Answer |
| : Result-Code=DIAMETER_SUCCESS |
| : EAP-Payload(EAP Success) |
| : EAP-Master-Session-Key |
| : (authorization AVPs) |
|<----------------------------------------------------------------|
| | |
| AA-Request | |
| Auth-Request-Type=AUTHORIZE_ONLY |
| (some AVPs from first session) | |
|------------------------------->| |
| | |
| AA-Answer | |
| Result-Code=DIAMETER_SUCCESS | |
| (authorization AVPs) | |
|<-------------------------------| |The NASREQ application is used here for authorization 👑 because the realm-specific routing table routes based on application, not on Diameter commands 💅
2.3.4. Scenario 4: Proxy Agents
This one is basically Scenario 1, except the NAS talks to the home server through proxies 🧚 Heads up though: the proxies can see the EAP session keys, so it's not suitable for environments where proxies can't be trusted 🙈
NAS Local proxy/relay agent Home server
| | |
| Diameter-EAP-Request | |
| Auth-Request-Type=AUTHORIZE_AUTHENTICATE |
| EAP-Payload(EAP Start) | |
|------------------------------->|------------------------------->|
| | |
| | Diameter-EAP-Answer |
| Result-Code=DIAMETER_MULTI_ROUND_AUTH |
| | EAP-Payload(EAP Request) |
|<-------------------------------|<-------------------------------|
| : |
: ...more EAP Request/Response pairs... :
| : |
| Diameter-EAP-Request | |
| EAP-Payload(EAP Response) | |
|------------------------------->|------------------------------->|
| | |
| | Diameter-EAP-Answer |
| | Result-Code=DIAMETER_SUCCESS |
| | EAP-Payload(EAP Success) |
| | EAP-Master-Session-Key |
| | (authorization AVPs) |
|<-------------------------------|<-------------------------------|2.4. Invalid Packets
Okay bestie, this part is all about catching bad EAP packets 🚨 While acting as a pass-through, the NAS MUST validate the EAP header fields (Code, Identifier, Length) before forwarding an EAP packet to or from the Diameter server 🔍 When an EAP packet comes in from the peer, the NAS checks the Code (Code 2=Response) and Length fields, then matches the Identifier against the current Identifier, which the Diameter server supplied in the most recently validated EAP Request 📬 When an EAP packet comes from the Diameter server (wrapped inside a Diameter-EAP-Answer), the NAS checks the Code (Code 1=Request) and Length fields, then updates the current Identifier value ✨ Pending EAP Responses that don't match the current Identifier value get silently discarded by the NAS 🫥
Since EAP method fields (Type, Type-Data) typically aren't validated by a NAS acting as a pass-through, it's still possible for a NAS to forward an invalid EAP packet to or from the Diameter server, even with all those checks 😭
A Diameter server that gets an EAP-Payload AVP it doesn't understand SHOULD figure out whether the error is fatal or non-fatal, based on the EAP Type 🧐 If it decides a fatal error happened, it MUST send a Diameter-EAP-Answer with a failure Result-Code and an EAP-Payload AVP encapsulating an EAP Failure packet 💀 If it decides a non-fatal error happened, it MUST send a Diameter-EAP-Answer with DIAMETER_MULTI_ROUND_AUTH Result-Code, but no EAP-Payload AVP 🔁 To simplify RADIUS translation, this message MUST also include an EAP-Reissued-Payload AVP encapsulating the previous EAP Request the server sent 🎀
When the NAS receives a Diameter-EAP-Answer without an EAP-Payload AVP (and with DIAMETER_MULTI_ROUND_AUTH Result-Code), it SHOULD discard the EAP-Response packet it most recently sent to the Diameter server 🗑️ Then it checks whether any more EAP Response packets that match the current Identifier value have arrived 👀 If so, a new EAP Response packet, if one's available, MUST be sent to the Diameter server within a Diameter-EAP-Request 🚀 If no EAP Response packet is available, the previous EAP Request gets resent to the peer, and the retransmission timer is reset ⏰
For DoS protection 🛡️ it's advisable for the NAS to allocate a finite buffer for EAP packets received from the peer, and to discard packets according to an appropriate policy once that buffer has been exceeded 💜 The Diameter server is also advised to permit only a modest number of invalid EAP packets within a single session, before terminating the session with DIAMETER_AUTHENTICATION_REJECTED Result-Code 🙅♀️ By default, a value of 5 invalid EAP packets is recommended 🔢
2.5. Retransmission
So as [EAP] notes, 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'll need to tweak retransmission strategies and authentication time-outs 🕰️ For example, when a token card is used, the user may need extra time to find the card and type in the token 🪙 Since the NAS usually doesn't know those parameters, the Diameter server has to provide them 💖
If a Multi-Round-Time-Out AVP [BASE] shows up in a Diameter-EAP-Answer that also has an EAP-Payload AVP, that value sets the EAP retransmission timer for that EAP Request, and only that one ⏱️✨
2.6. Fragmentation
Using the EAP-Payload AVP, the Diameter server can wrap up an EAP packet that's bigger than the MTU on the link between the NAS and the peer 📦 The server can't use MTU discovery to figure out the link MTU, so a Framed-MTU AVP may be included in a Diameter-EAP-Request message to tell it 📏
Once a Diameter server has received a Framed-MTU AVP in a Diameter-EAP-Request message, it MUST NOT send any later packet in this EAP conversation with an EAP-Payload AVP whose length goes over the Framed-MTU value 🚫 It has to take the link type (given by the NAS-Port-Type AVP) into account too 🧠 For example, as [RFC3580] Section 3.10 notes, for a NAS-Port-Type value of IEEE 802.11, the RADIUS server may send an EAP packet as large as Framed-MTU minus four (4) octets 📶 That leaves room for the IEEE 802.1X Version (1 octet), Type (1 octet) and Body Length (2 octets) fields 💅
2.7. Accounting 💖
okay so when a user gets authenticated with EAP, the NAS MAY add an Accounting-Auth-Method AVP [NASREQ] with value 5 (EAP) to its Accounting-Request messages. this spec adds one more AVP for accounting ✨ one or more Accounting-EAP-Auth-Method AVPs (see Section 4.1.5) MAY show up in Accounting-Request messages to say which EAP method(s) were used to authenticate the user 🎀
if the NAS authenticated the user with a locally implemented EAP method, it already knows which method was used and SHOULD put it in an Accounting-EAP-Auth-Method AVP 🔥
if the auth was done with Diameter-EAP-Request/Answer messages, the Diameter server SHOULD include one or more Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets that have a successful result code 👑 then the NAS SHOULD include those AVPs in its Accounting-Request messages 💅
2.8. Usage Guidelines 🧁
2.8.1. User-Name AVP 🪪
unless the access device reads the EAP-Response/Identity packet that the authenticating peer sent back, it has no idea who the user is 🙈 and ngl some EAP methods do identity protection, so the real identity isn't even in EAP-Response/Identity. so the Diameter Server SHOULD return the user's identity by inserting a User-Name AVP into Diameter-EAP-Answer messages whose Result-Code is DIAMETER_SUCCESS ✨ a separate billing identifier or pseudonym MAY be used for privacy reasons (see Section 8.5) 🦋 if the NAS can't get the user's identity, the Session-Id AVP MAY be used for accounting and billing, but operationally that could be really hard to manage 💀
2.8.2. Conflicting AVPs ⚔️
a Diameter-EAP-Answer message carrying an EAP-Payload of type EAP-Success or EAP-Failure MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH 🚫
some lower layers assume the EAP server made the authorization decision, so the peer treats EAP Success as "access granted" 🌸 in that case the Result-Code SHOULD match the EAP packet inside it: success for EAP-Success, failure for EAP-Failure. if they don't match, it gets messy, because the NAS and the peer end up concluding different outcomes. for example, if the NAS gets a failure Result-Code with an encapsulated EAP Success, it won't grant access. but the peer sees that EAP Success and thinks access was granted. yikes 😭
this can be really hard to avoid when Diameter proxy agents make authorization decisions, since proxies can change the Result-Code AVP sent by the home server 🫠 because it's the Diameter server's job to avoid conflicts, the NAS MUST NOT "manufacture" EAP result packets to fix the contradictory messages it receives. this behavior, originally mandated within [IEEE-802.1X], is now deprecated 🙅♀️
2.8.3. Displayable Messages 💬
the Reply-Message AVP [NASREQ] MUST NOT be included in any Diameter message that contains an EAP-Payload AVP 🤫
2.8.4. Role Reversal 🔄
some environments that use EAP, like PPP, support peer-to-peer operation. both parties are authenticators and authenticatees at the same time, in two simultaneous and independent EAP conversations. it's giving double the chaos 🌈
this spec is meant for communication between an EAP (passthrough) authenticator and a backend authentication server. a Diameter client MUST NOT send a Diameter-EAP-Request that encapsulates an EAP Request packet, and a Diameter server that receives such a packet MUST respond with a failure Result-Code 🙅♀️
2.8.5. Identifier Space 🆔
in EAP, each session has its own unique Identifier space. Diameter server implementations MUST be able to tell apart EAP packets that have the same Identifier, live in distinct EAP sessions, and come from the same NAS. they do this with the Session-Id AVP 🧚
if a Diameter NAS is in the middle of a multi-round auth exchange and notices that the EAP session between the client and the NAS was terminated, it MUST select a new Diameter Session-Id for any later EAP sessions. this is needed so a restarted EAP auth process can be told apart from the continuation of an ongoing one (same user, same NAS and port) 👀
in RADIUS, you get the same functionality by including or omitting the State attribute 💜 the translation rules in [NASREQ] make sure an Access-Request without the State attribute maps to a new Diameter Session-Id AVP value. a translation agent also always includes a State attribute in Access-Challenge messages, so it's available for a RADIUS NAS 🫶
3. Command-Codes 🎀
this section defines new Command-Code values that MUST be supported by all Diameter implementations conforming to this specification. the following commands are defined here:
Command-Name Abbrev. Code Reference
--------------------------------------------------------
Diameter-EAP-Request DER 268 3.1
Diameter-EAP-Answer DEA 268 3.2when the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used for AUTHORIZE_ONLY messages with EAP (see Section 2.3.3), an Application Identifier value of 1 (NASREQ) is used, and the commands follow the rules and ABNF defined in [NASREQ] 🍓
when the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA) commands are used together with the Diameter EAP application, they follow the rules in [NASREQ] and [BASE]. the accounting commands use Application Identifier value 3 (Diameter Base Accounting), and the others use 0 (Diameter Common Messages) ✨
3.1. Diameter-EAP-Request (DER) Command 📨
the Diameter-EAP-Request (DER) command is indicated by the Command-Code field set to 268 and the 'R' bit set in the Command Flags field. it's sent by a Diameter client to a Diameter server and carries an EAP-Response from the EAP client. the Diameter-EAP-Request MUST contain one EAP-Payload AVP with the actual EAP payload. an EAP-Payload AVP with no data MAY be sent to the Diameter server to kick off an EAP authentication session 🌟
the DER message MAY be the result of a multi-round authentication exchange, which happens when the DEA comes back with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH [BASE] 🔁 a subsequent DER message MUST include any State AVPs [NASREQ] that were present in the DEA. for re-authentication, it is recommended that the Identity request be skipped to cut down on authentication round trips. this only works when the user's identity is already known by the home Diameter server 💖
Message format 📜
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ NAS-Port-Id ]
[ NAS-Port-Type ]
[ Origin-State-Id ]
[ Port-Limit ]
[ User-Name ]
{ EAP-Payload }
[ EAP-Key-Name ]
[ Service-Type ]
[ State ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Callback-Number ]
[ Called-Station-Id ]
[ Calling-Station-Id ]
[ Originating-Line-Info ]
[ Connect-Info ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-IPv6-Prefix ]
[ Framed-IP-Netmask ]
[ Framed-MTU ]
[ Framed-Protocol ]
* [ Tunneling ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]3.2. Diameter-EAP-Answer (DEA) Command 💅
okay so the DEA is the answer message 🦋 It's got Command-Code 268 with the R bit cleared in the Command Flags field, and the Diameter server sends it to the client for one of three reasons:
- Multi-round auth is happening 🔁 The server is still expecting a follow-up Diameter-EAP-Request. You flag this by setting the
Result-CodetoDIAMETER_MULTI_ROUND_AUTH, and it MAY include zero or more State AVPs. - The client won 🏆 The EAP client has been successfully authenticated and authorized. The message MUST include the
Result-CodeAVP showing success, and it SHOULD include anEAP-Payloadof typeEAP-Success. This event MUST cause the access device to provide service to the EAP client. 🔥 - The client didn't pass 💀 The EAP client has not been successfully authenticated and/or authorized, so
Result-Codeis set to show failure. The message SHOULD include anEAP-Payload, but this AVP is not used to decide whether service gets provided.
ngl this part matters: if the original request asked for authorization, a successful response MUST include the authorization AVPs that are relevant to the service being provided ✨
Message format
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ EAP-Payload ]
[ EAP-Reissued-Payload ]
[ EAP-Master-Session-Key ]
[ EAP-Key-Name ]
[ Multi-Round-Time-Out ]
[ Accounting-EAP-Auth-Method ]
[ Service-Type ]
* [ Class ]
* [ Configuration-Token ]
[ Acct-Interim-Interval ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
[ Idle-Timeout ]
[ Authorization-Lifetime ]
[ Auth-Grace-Period ]
[ Auth-Session-State ]
[ Re-Auth-Request-Type ]
[ Session-Timeout ]
[ State ]
* [ Reply-Message ]
[ Origin-State-Id ]
* [ Filter-Id ]
[ Port-Limit ]
[ Callback-Id ]
[ Callback-Number ]
[ Framed-Appletalk-Link ]
* [ Framed-Appletalk-Network ]
[ Framed-Appletalk-Zone ]
* [ Framed-Compression ]
[ Framed-Interface-Id ]
[ Framed-IP-Address ]
* [ Framed-IPv6-Prefix ]
[ Framed-IPv6-Pool ]
* [ Framed-IPv6-Route ]
[ Framed-IP-Netmask ]
* [ Framed-Route ]
[ Framed-Pool ]
[ Framed-IPX-Network ]
[ Framed-MTU ]
[ Framed-Protocol ]
[ Framed-Routing ]
* [ NAS-Filter-Rule ]
* [ QoS-Filter-Rule ]
* [ Tunneling ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ AVP ]4. Attribute-Value Pairs ✨
this section does two jobs 🎀 It defines new AVPs that belong only to the EAP Diameter application, and it describes how AVPs defined somewhere else get used in the EAP application (but only when that usage is noteworthy).
4.1. New AVPs
4.1.1. EAP-Payload AVP
The EAP-Payload AVP (AVP Code 462) is of type OctetString. Its whole job is to wrap up the actual EAP packet being swapped between the EAP client and the home Diameter server 📦
4.1.2. EAP-Reissued-Payload AVP
The EAP-Reissued-Payload AVP (AVP Code 463) is of type OctetString. You can read about how it's used in Section 2.4 🌸
4.1.3. EAP-Master-Session-Key AVP
The EAP-Master-Session-Key AVP (AVP Code 464) is of type OctetString. It holds keying material for protecting the communications between the user and the NAS 🔐 How that keying material actually gets used depends on the link layer in question, and that's beyond the scope of this document.
4.1.4. EAP-Key-Name AVP
The EAP-Key-Name AVP (Radius Attribute Type 102) is of type OctetString. It holds an opaque key identifier (name) that the EAP method generated 🧚 Exactly how the name gets used depends on the link layer, which is beyond this document (check out [EAPKey] for more tea on that).
ok but here's the tea ☕ Not all link layers use this name, and most EAP methods don't generate it right now. The NAS runs in pass-through mode, so it can't know the Key-Name before the AAA server hands it over. Because of that, a Key-Name AVP sent in a Diameter-EAP-Request MUST NOT contain any data. If a home Diameter server gets a Diameter-EAP-Request with a Key-Name AVP that has non-empty data, it MUST silently discard the AVP. The home Diameter server SHOULD include this AVP in a Diameter-EAP-Response only if an empty EAP-Key-Name AVP was in the Diameter-EAP-Request 🫶
4.1.5. Accounting-EAP-Auth-Method AVP
The Accounting-EAP-Auth-Method AVP (AVP Code 465) is of type Unsigned64. For expanded types [EAP, Section 5.7], this AVP contains the value ((Vendor-Id * 2^32) + Vendor-Type) 🎀
The use of this AVP is described in Section 2.7.
5. AVP Occurrence Tables 🎀
the tables below use these symbols:
0 The AVP MUST NOT be present in the message
0+ Zero or more instances of the AVP MAY be present in the message
0-1 Zero or one instance of the AVP MAY be present in the message
1 One instance of the AVP MUST be present in the messageheads up 👀 AVPs that can only show up inside a Grouped AVP aren't represented in these tables.
5.1. EAP Command AVP Table
this table lists the AVPs that may be present in the DER and DEA Commands, as defined in this document 💖 The AVPs listed are defined both here and in [NASREQ].
+---------------+
| Command-Code |
|-------+-------+
Attribute Name | DER | DEA |
------------------------------------|-------+-------|
Accounting-EAP-Auth-Method | 0 | 0+ |
Acct-Interim-Interval [BASE] | 0 | 0-1 |
Auth-Application-Id [BASE] | 1 | 1 |
Auth-Grace-Period [BASE] | 0-1 | 0-1 |
Auth-Request-Type [BASE] | 1 | 1 |
Auth-Session-State [BASE] | 0-1 | 0-1 |
Authorization-Lifetime [BASE] | 0-1 | 0-1 |
Callback-Id [NASREQ] | 0 | 0-1 |
Callback-Number [NASREQ] | 0-1 | 0-1 |
Called-Station-Id [NASREQ] | 0-1 | 0 |
Calling-Station-Id [NASREQ] | 0-1 | 0 |
Class [BASE] | 0 | 0+ |
Configuration-Token [NASREQ] | 0 | 0+ |
Connect-Info [NASREQ] | 0-1 | 0 |
Destination-Host [BASE] | 0-1 | 0 |
Destination-Realm [BASE] | 1 | 0 |
EAP-Master-Session-Key | 0 | 0-1 |
EAP-Key-Name | 0-1 | 0-1 |
EAP-Payload | 1 | 0-1 |
EAP-Reissued-Payload | 0 | 0-1 |
Error-Message [BASE] | 0 | 0-1 |
Error-Reporting-Host [BASE] | 0 | 0-1 |
Failed-AVP [BASE] | 0 | 0+ |
Filter-Id [NASREQ] | 0 | 0+ |
Framed-Appletalk-Link [NASREQ] | 0 | 0-1 |
Framed-Appletalk-Network [NASREQ] | 0 | 0+ |
Framed-Appletalk-Zone [NASREQ] | 0 | 0-1 |
Framed-Compression [NASREQ] | 0+ | 0+ |
Framed-Interface-Id [NASREQ] | 0-1 | 0-1 |
Framed-IP-Address [NASREQ] | 0-1 | 0-1 |
Framed-IP-Netmask [NASREQ] | 0-1 | 0-1 |
Framed-IPv6-Prefix [NASREQ] | 0+ | 0+ |
Framed-IPv6-Pool [NASREQ] | 0 | 0-1 |
Framed-IPv6-Route [NASREQ] | 0 | 0+ |
Framed-IPX-Network [NASREQ] | 0 | 0-1 |
Framed-MTU [NASREQ] | 0-1 | 0-1 |
Framed-Pool [NASREQ] | 0 | 0-1 |
Framed-Protocol [NASREQ] | 0-1 | 0-1 |
Framed-Route [NASREQ] | 0 | 0+ |
Framed-Routing [NASREQ] | 0 | 0-1 |
Idle-Timeout [NASREQ] | 0 | 0-1 |
Multi-Round-Time-Out [BASE] | 0 | 0-1 |
NAS-Filter-Rule [NASREQ] | 0 | 0+ |
NAS-Identifier [NASREQ] | 0-1 | 0 |
NAS-IP-Address [NASREQ] | 0-1 | 0 |
NAS-IPv6-Address [NASREQ] | 0-1 | 0 |
NAS-Port [NASREQ] | 0-1 | 0 |
NAS-Port-Id [NASREQ] | 0-1 | 0 |
NAS-Port-Type [NASREQ] | 0-1 | 0 |
Originating-Line-Info [NASREQ] | 0-1 | 0 |
Origin-Host [BASE] | 1 | 1 |
Origin-Realm [BASE] | 1 | 1 |
Origin-State-Id [BASE] | 0-1 | 0-1 |
Port-Limit [NASREQ] | 0-1 | 0-1 |
Proxy-Info [BASE] | 0+ | 0+ |
QoS-Filter-Rule [NASREQ] | 0 | 0+ |
Re-Auth-Request-Type [BASE] | 0 | 0-1 |
Redirect-Host [BASE] | 0 | 0+ |
Redirect-Host-Usage [BASE] | 0 | 0-1 |
Redirect-Max-Cache-Time [BASE] | 0 | 0-1 |
Reply-Message [NASREQ] | 0 | 0+ |
Result-Code [BASE] | 0 | 1 |
Route-Record [BASE] | 0+ | 0+ |
Service-Type [NASREQ] | 0-1 | 0-1 |
Session-Id [BASE] | 1 | 1 |
Session-Timeout [BASE] | 0 | 0-1 |
State [NASREQ] | 0-1 | 0-1 |
Tunneling [NASREQ] | 0+ | 0+ |
User-Name [BASE] | 0-1 | 0-1 |5.2. Accounting AVP Table 📒
okay so this table tells you which AVPs from this doc are supposed to show up in Accounting messages, as defined in [BASE] 🧾
+-----------+
| Command |
| Code |
|-----+-----+
Attribute Name | ACR | ACA |
---------------------------------------|-----+-----+
Accounting-EAP-Auth-Method | 0+ | 0 |6. RADIUS/Diameter Interactions 🔁
Section 9 of [NASREQ] gives basic guidelines for translation agents that convert between RADIUS and Diameter 🪄 These guidelines SHOULD be followed for the Diameter EAP application too, plus a few extra guidelines in this section. Also, this doc doesn't stop implementations from making up additional methods, as long as the translation doesn't break the RADIUS or the Diameter protocols. Bestie, don't break the protocols 💅
6.1. RADIUS Request Forwarded as Diameter Request 🎀
RADIUS Access-Request to Diameter-EAP-Request:
- RADIUS EAP-Message attribute(s) get translated into a Diameter EAP-Payload AVP. If there are multiple RADIUS EAP-Message attributes, they get concatenated and translated into a single Diameter EAP-Payload AVP 🧩
- An empty RADIUS EAP-Message attribute (with length 2) means EAP-Start, and it gets translated into an empty EAP-Payload AVP 🌱
Diameter-EAP-Answer to RADIUS Access-Accept/Reject/Challenge:
- The Diameter EAP-Payload AVP gets translated into RADIUS EAP-Message attribute(s). If needed, the value gets split into multiple RADIUS EAP-Message attributes ✂️
- The Diameter EAP-Reissued-Payload AVP gets translated into a message that has RADIUS EAP-Message attribute(s) plus a RADIUS Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet (Ignored)" [RFC3579] 🙈
- As described in [NASREQ], if the Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH and the Multi-Round-Time-Out AVP is present, it gets translated into the RADIUS Session-Timeout attribute ⏰
- The Diameter EAP-Master-Session-Key AVP can be translated into the vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key attributes [RFC2548]. The first up to 32 octets of the key get stored into MS-MPPE-Recv-Key, and the next up to 32 octets (if present) get stored into MS-MPPE-Send-Key. The encryption of this attribute is described in [RFC2548] 🔐
- If Diameter Accounting-EAP-Auth-Method AVPs are present, they get discarded 🗑️
6.2. Diameter Request Forwarded as RADIUS Request 🦋
Diameter-EAP-Request to RADIUS Access-Request:
- The Diameter EAP-Payload AVP gets translated into RADIUS EAP-Message attribute(s) 💖
- An empty Diameter EAP-Payload AVP means EAP-Start, and it gets translated into an empty RADIUS EAP-Message attribute 🌸
- The type (or expanded type) field from the EAP-Payload AVP can be saved either in a local state table, or encoded in a RADIUS Proxy-State attribute. This info is needed to build an Accounting-EAP-Auth-Method AVP for the answer message (see below) 🧠
RADIUS Access-Accept/Reject/Challenge to Diameter-EAP-Answer:
- If the RADIUS Access-Challenge message does NOT contain an Error-Cause attribute [RFC3576] with value 202 (decimal), "Invalid EAP Packet (Ignored)" [RFC3579], any RADIUS EAP-Message attributes get translated into a Diameter EAP-Payload AVP, concatenated if there are multiple attributes 🫶
Heads up: that bullet only applies when the 202 Error-Cause is missing. If it's there, the next bullet takes over.
- If the Error-Cause attribute with value 202 is present, any RADIUS EAP-Message attributes get translated into a Diameter EAP-Reissued-Payload AVP, concatenated if there are multiple attributes 🔄
- As described in [NASREQ], if the Session-Timeout attribute is present in a RADIUS Access-Challenge message, it gets translated into the Diameter Multi-Round-Time-Out AVP ⏳
- If the vendor-specific RADIUS MS-MPPE-Recv-Key and/or MS-MPPE-Send-Key attributes [RFC2548] are present, they can be translated into a Diameter EAP-Master-Session-Key AVP. The attributes have to be decrypted before conversion, and the Salt, Key-Length and Padding sub-fields get discarded. The Key sub-fields get concatenated (MS-MPPE-Recv-Key first, MS-MPPE-Send-Key next), and the concatenated value gets stored into a Diameter EAP-Master-Session-Key AVP 🗝️
- If the Diameter-EAP-Answer will have a successful result code, the saved state (see above) can be used to build an Accounting-EAP-Auth-Method AVP 🎉
6.3. Accounting Requests 📊
In Accounting-Requests, the vendor-specific RADIUS MS-Acct-EAP-Type attribute [RFC2548] can be translated into a Diameter Accounting-EAP-Auth-Method AVP, and vice versa 🔁
When translating from Diameter to RADIUS, note that the MS-Acct-EAP-Type attribute does NOT support expanded EAP types. Type values greater than 255 should be translated to type 254 🧐
7. IANA Considerations 🗂️
This doc doesn't create any new namespaces for IANA to maintain, but it DOES need new values in namespaces that were already defined in the Diameter Base protocol and RADIUS specs 💜
- This document defines one new Diameter command (in Section 3) whose Command Code is allocated from the Command Code namespace defined in [BASE]. The Command Code for DER / DEA is 268 ⚡
- This document defines four new AVPs whose AVP Codes are allocated from the AVP Code namespace defined in [BASE] as follows:
462 for EAP-Payload (defined in Section 4.1.1),
463 for EAP-Reissued-Payload (defined in Section 4.1.2),
464 for EAP-Master-Session-Key (defined in Section 4.1.3), and
465 for Accounting-EAP-Auth-Method (defined in Section 4.1.5).- This document defines one new AVP (attribute) whose AVP Code (Attribute Type) is to be allocated from the Attribute Type namespace defined in [RFC2865] and [RFC3575]. The Radius Attribute Type for EAP-Key-Name (defined in Section 4.1.4) is 102 🔑
- This document defines one new Diameter application (in Section 2.1) whose Application ID is to be allocated from the Application Identifier namespace defined in [BASE]. The Application ID for Diameter EAP is 5 🌈
8. Security Considerations 🔒
8.1. Overview 🛡️
Okay, this section is serious business, bestie 😭 Diameter peer-to-peer connections can be protected with IPsec or TLS. These are believed to give sufficient protection under the normal Internet threat model, which means assuming the authorized nodes in the protocol haven't been compromised, but the attacker fully controls the communication channels between them. That includes eavesdropping, message modification, insertion, man-in-the-middle and replay attacks. The details and related security considerations are discussed in [BASE] 👀
On top of the authentication that IPsec or TLS gives you, authorization is ALSO required. Here, authorization means deciding whether a Diameter message from an authenticated Diameter peer should be accepted (NOT authorizing users who are requesting network access from a NAS) 🙅♀️ So when a Diameter server gets a Diameter-EAP-Request, it has to decide whether the client is allowed to act as a NAS for that specific user, service type, and so on. And when a NAS contacts a server to send a Diameter-EAP-Request, it has to figure out whether that server is authorized to act as home server for the realm in question 🏠
Authorization can involve local Access Control Lists (ACLs), information in certificates, or some other means. See [BASE] for more discussion and related security considerations. Also, authorization issues are especially relevant when Diameter redirects are used 🚨 Redirection reduces the number of nodes that can see the contents of Diameter messages, but a compromised Diameter agent may not supply the right home server's address. If the Diameter client can't tell whether this particular server is authorized to act as home server for this particular user, then the security of the communications rests on the redirect agent 😬
The hop-by-hop security mechanisms (IPsec and TLS) combined with proper authorization give good protection against "outside" attackers, except for denial-of-service attacks 🧱 The rest of this section covers attacks by nodes that have been properly authorized (to function as a NAS, Diameter agent, or Diameter server) but abuse that authorization or have been compromised. In general, it's not possible to completely protect against attacks by compromised nodes, but this section offers advice on limiting the extent of the damage 🫣
Attacks involving eavesdropping or modification of EAP messages are beyond the scope of these document. See [EAP] for discussion of these security considerations (including method negotiation, dictionary attacks, and privacy issues). While these attacks can be carried out by an attacker between the client and the NAS, compromised NASes and Diameter agents are naturally also in a good position to modify and eavesdrop on the EAP messages 👁️
Similarly, attacks involving the link layer protocol used between the client and the NAS, such as PPP or IEEE 802.11, are beyond the scope of this document 📡
8.2. AVP Editing 💅
okay so Diameter agents can modify, insert, and delete AVPs 🧚 They're usually supposed to modify AVPs, and the protocol genuinely can't tell a well-intentioned change from a malicious one (see [RFC2607] for more discussion) 😭 A compromised NAS or server can also just send a different set of AVPs than you'd expect 💀
So the real question is: what can an attacker who has compromised an authorized NAS, agent, or server do using Diameter EAP messages? 🙈 Some of it is super obvious. Like, a Diameter agent can let unauthorized users in by changing the Result-Code to DIAMETER_SUCCESS 🚨 Other stuff is sneakier, and we'll get into it below. Authentication method negotiation attacks get their own section right after this one 🦋
By putting the right AVPs into an AA-Answer/Diameter-EAP-Answer message, an attacker may be able (depending on implementation and configuration details) to:
- Give unauthorized users access, or deny access to authorized users (
Result-Code). - Give an attacker a login session to a host otherwise protected by firewalls, or redirect an authorized user's login session to a host controlled by the attacker (
Login-Host). - Route an authorized user's traffic through a host controlled by the attacker (various tunneling AVPs).
- Redirect an authorized user's DNS requests to a malicious DNS server (various vendor-specific AVPs).
- Modify routing tables at the NAS and thus redirect packets destined for someone else (
Framed-Route,Framed-Routing). - Remove packet filters and other restrictions for the user (
Filter,Callback, various vendor-specific AVPs). - Cause the NAS to call some number, possibly an expensive toll number controlled by the attacker (callback AVPs).
- Execute Command Line Interface (CLI) commands on the NAS (various vendor-specific attributes).
By modifying an AA-Request/Diameter-EAP-Request, an attacker may be able to:
- Change
NAS-Identifier/NAS-Port/Origin-Host(or another attribute) so that a valid user appears to be accessing the network from a different NAS than in reality. - Modify
Calling-Station-ID(either to hide the true value, gain access, or frame someone else). - Modify password change messages (some vendor-specific attributes).
- Modify usage information in accounting messages.
- Modify contents of
ClassandStateAVPs.
Some of these attacks can be prevented if the NAS or server is configured to not accept some particular AVPs, or accepts them only from some nodes 🛡️
8.3. Negotiation Attacks 🎭
This section is all about attacks where the NAS, any Diameter agents, or the Diameter server try to get the authenticating user to pick some authentication method other than EAP, such as PAP or CHAP (negotiation attacks within EAP are discussed in [EAP], Section 7.8) 👀
The vulnerability can be mitigated with a per-connection policy on the authenticating peer, and a per-user policy on the Diameter server ✨ For the authenticating peer, the authentication policy should be set on a per-connection basis.
With a per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected 🙌 So an authenticating peer that selects EAP is presumed to require that level of security. If that security can't be provided, there's likely a misconfiguration, or the authenticating peer may be talking to the wrong server 😬 In this case, the authenticating peer simply disconnects.
Similarly, with a per-user policy, the home server will not accept authentication methods other than EAP for users for which EAP support is expected 💖
For a NAS, it may not be possible to figure out whether a peer is required to authenticate with EAP until the peer's identity is known 🤔 For example, for shared-uses NASes, one reseller may implement EAP while another does not. Alternatively, some peers might be authenticated locally by the NAS while other peers are authenticated via Diameter. In those 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 🔐
8.4. Session Key Distribution 🔑
Since there are currently no end-to-end (NAS-to-home server) security mechanisms specified for Diameter, any agents that process Diameter-EAP-Answer messages can see the contents of the EAP-Master-Session-Key AVP 😱 For this reason, this specification strongly recommends avoiding Diameter agents when they cannot be trusted to keep the keys secret.
In environments where agents are present, a few factors should be considered when deciding whether the agents that are authorized (and considered "trustworthy enough") to grant access to users and specify various authorization and tunneling AVPs are also "trustworthy enough" to handle the session keys 🧐 These factors include (but are not limited to) the type of access provided (e.g., public Internet or corporate internet), the security level of the agents, and the possibilities for attacking the user's traffic after it has been decrypted by the NAS.
Note that the keys communicated in Diameter messages are usually short-term session keys (or short-term master keys that are used to derive session keys) ⏳ To actually cause any damage, those session keys have to end up with some malicious party, who must be able to eavesdrop on, modify, or insert traffic between the user and the NAS during the lifetime of those keys (for example, in 802.11i the attacker must also eavesdrop the "four-way handshake") 🫣
8.5. Privacy Issues 🕵️♀️
Diameter messages can contain AVPs that identify the user (e.g., User-Name) and approximate the user's location (e.g., Origin-Host for WLAN access points, Calling-Station-Id for fixed phone lines) 📍 So any Diameter nodes that process the messages may be able to work out the geographic location of users. Yikes.
Note that in many cases, the user identity is also sent in the clear inside EAP-Payload AVPs, and it may be possible to eavesdrop on that between the user and the NAS 🙈
This can be somewhat mitigated by using EAP methods that provide identity protection (see [EAP], Section 7.3), and by using Session-Id or pseudonyms for accounting 🎀
8.6. Note about EAP and Impersonation 🥸
If the EAP method used does not provide mutual authentication, obviously anyone can impersonate the network to the user 🚩 Even when EAP mutual authentication is used, it happens between the user and the Diameter home server. See [EAPKey] for an extensive discussion of the details and their implications.
There's one issue worth pointing out here. As described in [EAPKey], the current EAP architecture does not allow the home server to restrict which service parameters or identities (such as SSID or BSSID in 802.11 wireless LANs) are advertised by the NAS to the client 😤 In other words, a compromised NAS can change its BSSID or SSID, and so appear to offer a different service than intended. Even if these parameters are included in Diameter-EAP-Answer messages, the NAS can tell the client different values.
So the NAS's possession of the session keys proves that the user is talking to an authorized NAS, but a compromised NAS can lie about its exact identity 🫠 See [EAPKey] for discussion of how individual EAP methods can provide authentication of NAS service parameters and identities.
Note that this authentication may be pretty limited in many environments. For instance, in wireless LANs the user doesn't usually know securely the identity (such as BSSID) of the "right" access point; it's simply picked from a beacon message that has the correct SSID and good signal strength (something that is super easy to spoof 📡). So simply authenticating the identity may not let the user tell the "right" access point apart from all the others 💀
9. Acknowledgements 🫶
This Diameter application relies heavily on earlier work on the Diameter NASREQ application [NASREQ] and RADIUS EAP support [RFC3579]. A lot of the material in this specification has been copied from these documents 🌸
The authors would also like to thank the following people for their contributions to this document: Bernard Aboba, Jari Arkko, Julien Bournelle, Pat Calhoun, Henry Haverinen, John Loughney, Yoshihiro Ohba, and Joseph Salowey 💜
10. References 📚
10.1. Normative References 🔗
[BASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[NASREQ] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC
4005, August 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.10.2. Informative References 📚
okay bestie, these are the "go read this if you want the deep dive" references 🤓 they're not required to get the main idea, but they're the receipts behind the whole thing 💅
[EAPKey] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)
Key Management Framework", Work in Progress, July
2004.
[IEEE-802.1X] Institute of Electrical and Electronics Engineers,
"Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X,
September 2001.
[IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks -
Specific requirements - Part 11: Wireless Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications: Amendment 6: Medium Access Control
(MAC) Security Enhancements", IEEE Standard
802.11i-2004, July 2004.
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", Work in Progress, June 2004.
[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.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[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.
[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.Authors' Addresses 🎀
these are the people who wrote it, so you know who to thank (or yell at) 🫶
Pasi Eronen (editor)
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Tom Hiller
Lucent Technologies
1960 Lucent Lane
Naperville, IL 60566
USA
Phone: +1 630 979 7673
EMail: tomhiller@lucent.com
Glen Zorn
Cisco Systems
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
USA
Phone: +1 425 344 8113
EMail: gwz@cisco.comFull Copyright Statement 💖
okay, the legal bit, but make it cute 🙈
Copyright (C) The Internet Society (2005). ✨
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So the authors still own their stuff, ngl 🦋
This document and the information contained herein are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Basically, nobody is promising it's perfect, so vibe check accordingly 💀
Intellectual Property 🦋
this part is about patents and who owns what, so let's get into it 👑
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim to have done any independent effort to find any of those rights. Info on how rights work for RFC documents lives in BCP 78 and BCP 79, so go there if you're curious 🤓
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🌸
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. Basically, if you spot something sus, say something 📣
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 💜
📦 where this page comes from
- ietf: rfc4072 2005-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms