Diameter Extensible Authentication Protocol (EAP) Application
Extracted elements (32)
A preferred protocol flow has the NAS issue EAP-Request/Identity locally and forward the EAP-Response/Identity directly in the first DER, reducing Diameter round trips compared to having the server send the identity request. This optimization cannot always be applied when user identity is unavailable.
EAP authentication in Diameter occurs end-to-end between the EAP client and the home Diameter server, reducing replay and man-in-the-middle attack opportunities and enabling mutual authentication that PAP/CHAP roaming environments cannot provide.
Scenario 3 (direct EAP with AUTHENTICATE_ONLY, followed by a separate NASREQ AUTHORIZE_ONLY via local proxy) exists for environments where the home server cannot supply all necessary authorization AVPs, with NASREQ used for the authorization leg because realm routing is application-based.
The Diameter EAP-Master-Session-Key AVP can be translated to the vendor-specific RADIUS MS-MPPE-Recv-Key and MS-MPPE-Send-Key attributes: the first up to 32 octets go into MS-MPPE-Recv-Key and the next up to 32 octets into MS-MPPE-Send-Key, with encryption as described in RFC 2548.
When translating a RADIUS Access-Request to a DER, multiple RADIUS EAP-Message attributes are concatenated into a single EAP-Payload AVP; an empty RADIUS EAP-Message (length 2) maps to an empty EAP-Payload signifying EAP-Start.
When translating from Diameter to RADIUS accounting, the MS-Acct-EAP-Type attribute does not support expanded EAP types; type values greater than 255 should be translated to type 254.
A Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an EAP Request packet (role reversal), and a Diameter server receiving such a packet MUST respond with a failure Result-Code.
A Diameter-EAP-Answer containing an EAP-Payload of type EAP-Success or EAP-Failure MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH; the Result-Code SHOULD match the contained EAP packet to avoid contradictory outcomes between the NAS and the peer.
A Diameter-EAP-Request MUST contain one EAP-Payload AVP; a subsequent DER in a multi-round exchange MUST include any State AVPs that were present in the preceding DEA.
A Diameter server determining that a fatal EAP error has occurred MUST send a Diameter-EAP-Answer with a failure Result-Code and an EAP-Payload AVP encapsulating an EAP Failure packet.
A Diameter server determining that a non-fatal EAP error has occurred MUST send a Diameter-EAP-Answer with DIAMETER_MULTI_ROUND_AUTH Result-Code and no EAP-Payload AVP, but MUST include an EAP-Reissued-Payload AVP encapsulating the previous EAP Request to simplify RADIUS translation.
A Diameter server that has received a Framed-MTU AVP in a Diameter-EAP-Request MUST NOT send any subsequent EAP-Payload AVP in that conversation whose length exceeds the specified Framed-MTU value, accounting for link-type overhead.
A Key-Name AVP sent in a Diameter-EAP-Request MUST NOT contain any data; a home Diameter server receiving a non-empty EAP-Key-Name AVP in a DER MUST silently discard the AVP.
Diameter nodes conforming 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.
Diameter server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct EAP sessions using the Session-Id AVP. If an EAP session is terminated mid-exchange, the NAS MUST select a new Diameter Session-Id for any subsequent EAP sessions.
The access device MUST NOT rely on the contents of the optional EAP-Payload AVP in a Diameter-EAP-Answer to determine whether service is to be provided; only the Result-Code AVP is authoritative for this decision.
The Reply-Message AVP MUST NOT be included in any Diameter message containing an EAP-Payload AVP.
When the NAS issues the EAP-Request/Identity message to the EAP client, it SHOULD interpret the returned EAP-Response/Identity packet and copy its value to a User-Name AVP in the Diameter-EAP-Request, to enable realm-based routing.
While acting as a pass-through, the NAS MUST validate the EAP header fields (Code, Identifier, Length) prior to forwarding an EAP packet to or from the Diameter server; pending EAP Responses that do not match the current Identifier are silently discarded.
Diameter messages may contain User-Name and location-revealing AVPs (Origin-Host, Calling-Station-Id). User identity may also appear in cleartext inside EAP-Payload AVPs visible between the user and the NAS. Mitigations include EAP methods with identity protection and using Session-Id or pseudonyms for accounting.
The Accounting-EAP-Auth-Method AVP (AVP Code 465, type Unsigned64) identifies the EAP method(s) used to authenticate the user. For expanded EAP types, its value is (Vendor-Id × 2^32 + Vendor-Type). It MAY appear multiple times in Accounting-Request messages.
The Diameter-EAP-Answer (DEA) command uses Command-Code 268 with the 'R' bit cleared. It is sent by the server to indicate multi-round continuation (DIAMETER_MULTI_ROUND_AUTH), authentication success (DIAMETER_SUCCESS with optional EAP-Master-Session-Key and authorization AVPs), or failure.
The Diameter-EAP-Request (DER) command uses Command-Code 268 with the 'R' bit set. It carries an EAP-Response from the EAP client to the Diameter server and includes mandatory AVPs: Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Realm, Auth-Request-Type, and EAP-Payload.
The EAP-Key-Name AVP (RADIUS Attribute Type 102, type OctetString) carries an opaque key identifier generated by the EAP method. It is included in the DEA only if an empty EAP-Key-Name AVP was present in the DER, and the NAS cannot populate it because it operates in pass-through mode.
The EAP-Master-Session-Key AVP (AVP Code 464, type OctetString) carries keying material generated by the EAP method and delivered from the home Diameter server to the NAS for protecting communications between the user and the NAS; its link-layer usage is out of scope.
The EAP-Payload AVP (AVP Code 462, type OctetString) encapsulates the actual EAP packet being exchanged between the EAP client and the home Diameter server. An empty EAP-Payload in a DER signals EAP-Start.
The EAP-Reissued-Payload AVP (AVP Code 463, type OctetString) carries the previous EAP Request when the server signals a non-fatal error via DIAMETER_MULTI_ROUND_AUTH without an EAP-Payload, enabling RADIUS translation to include the reissued packet.
This document allocates Command-Code 268 for DER/DEA, AVP Codes 462–465 for EAP-Payload, EAP-Reissued-Payload, EAP-Master-Session-Key, and Accounting-EAP-Auth-Method from the Diameter AVP Code namespace, RADIUS Attribute Type 102 for EAP-Key-Name, and Application ID 5 for the Diameter EAP application.
Because Diameter has no end-to-end (NAS-to-home-server) security, any proxy agent processing a DEA can read the EAP-Master-Session-Key. The specification strongly recommends avoiding Diameter agents that cannot be trusted to keep session keys secret.
Compromised Diameter agents can manipulate AVPs in DEA/DER messages to grant unauthorized access, redirect user sessions or DNS to attacker-controlled hosts, modify routing tables, remove packet filters, or execute CLI commands on the NAS. Some attacks can be mitigated by configuring the NAS to reject unexpected AVPs.
Even with EAP mutual authentication, the home server cannot restrict what service parameters (e.g., SSID, BSSID) the NAS advertises. A compromised NAS can lie about its identity to the client. The NAS possessing session keys proves it is an authorized NAS, but not its exact identity.
Negotiation attacks can cause an EAP peer to fall back to weaker methods (PAP, CHAP). Mitigation requires per-connection policy at the peer (disconnect if EAP unavailable) and per-user policy at the home server (reject non-EAP authentication). If any NAS peers MUST use EAP, the NAS MUST attempt to negotiate EAP for every session.