Diameter Support for the EAP Re-authentication Protocol (ERP)
Extracted elements (27)
Implicit bootstrapping (during initial EAP authentication) makes the ER server immediately available for re-authentication but wastes resources deriving keys for peers that may never use ERP. Explicit bootstrapping (during first re-authentication) is more resource-efficient but requires a round trip to the home EAP server, increasing first re-authentication latency.
The ERP-RK-Request and ERP-Realm AVPs have the 'M' flag cleared so that legacy Diameter nodes that do not support ERP can safely ignore them without generating an error, enabling backward compatibility with RFC 4072 deployments.
The protocol reuses existing Diameter EAP commands (DER/DEA from RFC 4072) rather than defining new command codes, relying solely on a new Application Id to distinguish ERP traffic. This minimizes the protocol footprint while enabling correct Diameter routing.
If the home Diameter server does not support the Diameter ERP extensions, it simply ignores the ERP-RK-Request AVP (because 'M' bit is cleared) and continues per RFC 4072 without bootstrapping the ER server.
Diameter nodes conforming to this specification in the role of the ER server MUST advertise support by including an Auth-Application-Id AVP with a value of Diameter ERP (13) in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
If no ER server is available in either the local or home domain, an DIAMETER_UNABLE_TO_DELIVER error MUST be generated as specified in RFC 6733 and returned to the authenticator.
If the home Diameter EAP server does not support ERP extensions and receives an EAP-Initiate message, it MUST send an EAP/DEA with a Result-Code indicating Permanent Failure, and the Failed-AVP AVP MUST be included containing a copy of the EAP-Payload AVP.
If there is an ER server in the same domain as the authenticator, Diameter routing MUST be configured so that ERP/DER messages reach that server even if the Destination-Realm differs from the local domain.
In case of multiple physical home EAP servers, if the ER server wants to reach the same home EAP server, the ER server SHOULD cache the Destination-Host AVP corresponding to that home EAP server.
The Key-Lifetime AVP MUST NOT be greater than the remaining lifetime of the EMSK from which the keying material was derived, ensuring keys do not outlive their root secret.
The value of the Key-Type AVP MUST be set to 1 for rRK or 2 for rMSK when used within the Diameter ERP application.
When the authentication completes successfully and the EAP method has generated an EMSK, the home EAP server MUST derive the rRK as specified in RFC 6696 using the saved ERP realm name and include it in a Key AVP with Key-Type set to rRK.
When the ER server proxies a Diameter-EAP-Answer with a Session-Id corresponding to a message to which it added ERP-RK-Request and the Result-Code is DIAMETER_SUCCESS, it MUST examine, save, and remove any Key AVP with Key-Type set to rRK.
A new permanent failure Result-Code value DIAMETER_ERROR_EAP_CODE_UNKNOWN (5048) is defined, used by the Diameter server to inform the peer that the received EAP-Payload AVP contains an EAP packet with an unknown EAP code.
During implicit bootstrapping, the ER server acts as a Diameter EAP Proxy; Diameter routing MUST be configured to route Diameter EAP application messages through this proxy so it can intercept DEA messages carrying the rRK and add ERP-RK-Request to outbound DER messages.
During re-authentication, the authenticator creates an ERP/DER message with Application Id set to 13 (Diameter ERP), Auth-Application-Id set to 13, User-Name and Destination-Realm derived from the keyName-NAI, and EAP-Payload containing the EAP-Initiate/Re-auth message.
The Diameter ERP application transports ERP messages between an ER authenticator and the ER server using Application Id 13. It reuses the Diameter-EAP-Request (DER) and Diameter-EAP-Answer (DEA) commands with the new Application Id, referred to as ERP/DER and ERP/DEA.
The ERP-Realm AVP (AVP Code 619) is of type DiameterIdentity and contains the name of the realm in which the ER server is located. It has the 'M' and 'V' bits cleared.
The ERP-RK-Request AVP (AVP Code 618) is a Grouped AVP used by the ER server to indicate its willingness to act as the ER server for a particular session. It contains a mandatory ERP-Realm AVP and has the 'M' and 'V' bits cleared.
The Key AVP (defined in RFC 6734) is of type Grouped and carries either the rRK or rMSK along with associated attributes including Key-Type, Keying-Material, Key-Name, and Key-Lifetime sub-AVPs.
The Key-Name AVP contains the EMSKname that identifies the keying material. The derivation of this name is specified in RFC 6696.
The Keying-Material AVP contains the rRK (sent from the home EAP server to the ER server) or the rMSK (sent from the ER server to the authenticator). Derivation and usage are specified in RFC 6696.
IANA allocated a new value in the 'Result-Code AVP Values - Permanent Failure' registry: DIAMETER_ERROR_EAP_CODE_UNKNOWN (code 5048), as defined in Section 9.
IANA allocated Application Id 13 ('Diameter ERP') in the 'Application IDs' registry of the AAA Parameters registries under the 'Standards Action' range with 'Specification Required' policy.
IANA allocated two new AVP Codes in the 'AVP Codes' registry: ERP-RK-Request (code 618) and ERP-Realm (code 619), as defined in Section 8.
Because the Diameter ERP application transmits sensitive cryptographic key material (rRK, rMSK), all transport MUST be protected using TLS, DTLS, or IPsec ESP. If TLS or DTLS is used, the bulk encryption algorithm negotiated MUST be non-null; if ESP is used, the encryption algorithm MUST also be non-null.
The ERP-RK-Request AVP uses ABNF: `ERP-RK-Request ::= < AVP Header: 618 > { ERP-Realm } * [ AVP ]`. AVP code 618, Grouped type, 'M' and 'V' bits cleared.