Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers
Extracted elements (27)
The default SK derivation follows the methodology of RFC 5295 Section 3.1: SK = KDF(PSK, key label | '\0' | Ni | Nr | IDi | length), where KDF is HMAC-SHA-256 and the key label is '[email protected]'. This binds the SK to the specific IKEv2 session parameters to ensure key freshness and limit scope.
The protocol provides IKEv2 nonces and identity attributes to the HAAA so that the HAAA can compute a session-specific SK, avoiding transmission of a long-term PSK over the Diameter interface and supporting per-session key derivation by external protocols such as 3GPP2 X.S0047 and X.S0058.
RFC 5778 defined Diameter interworking for Mobile IPv6 between the Home Agent and Diameter server using EAP or Mobile IPv6 Authentication Protocol, but did not cover SK-based IKEv2 authentication. This document fills that gap and is complementary to RFC 5778.
If no SK associated with the IKEv2 peer is found, the IKEv2 server MUST send an Authorize-Only (Auth-Request-Type set to 'Authorize-Only') Diameter IKEv2-SK-Request message to the HAAA to obtain the SK.
If the authorization procedure is successful, the IKEv2-SK-Answer message SHALL include the Key AVP; the Key-Type AVP SHALL be set to IKEv2 SK (3) and the Keying-Material AVP SHALL contain the SK.
If the IDi payload contains an identity meaningful for the Diameter infrastructure (such as an NAI), it SHALL be used by the IKEv2 server to populate the User-Name AVP in the Diameter message.
If the Key-Lifetime AVP is included in the IKEv2-SK-Answer, then the associated key SHALL NOT be used by the receiver of the answer if the lifetime has expired.
The IKEv2 server MUST support the Authorization Session State Machine defined in RFC 6733, since the HAAA may maintain Diameter session state or be stateless as indicated by the presence or absence of Auth-Session-State AVP.
The IKEv2 server SHALL include the IKEv2-Identity AVP in the IKEv2-SK-Request message; the Initiator-Identity AVP SHALL be populated with the IDi field extracted from the IKE_AUTH message.
The IKEv2 server SHALL include the IKEv2-Nonces AVP with the initiator and responder nonces (Ni and Nr) exchanged during the initial IKEv2 exchange in the IKEv2-SK-Request message.
When applications define their own SK-generation algorithm, it is strongly RECOMMENDED that nonces Ni and Nr be used in the computation, and RECOMMENDED that IDi be used. IDr SHOULD NOT be used because a mismatch between IDr asserted by the peer and IDr returned by the responder would result in different SKs being generated.
When the IKEv2 server receives an Abort-Session-Request (ASR) message from the HAAA, it MUST delete the corresponding IKE_SA and all CHILD_SAs set up through it.
Diameter IKE SK (IKESK) Application Identifier is assigned the value 11. This identifier is used when the IKEv2 peer is to be authenticated and authorized using IKEv2 with SK-based authentication.
The IKEv2-Identity AVP (Code 590) is of type Grouped and contains the Initiator-Identity (mandatory) and optionally the Responder-Identity as included in the IKE_AUTH message.
The IKEv2-Nonces AVP (Code 587) is of type Grouped and contains the nonces Ni and Nr exchanged between the IKEv2 peer and server during the IKEv2 initial exchange; both sub-AVPs are mandatory within the group.
The IKEv2-SK-Answer (IKESKA) command uses Command Code 329 with the 'R' bit cleared and Application-Id 11. It is sent by the HAAA to the IKEv2 server and SHALL include the Key AVP (from RFC 6734) on successful authorization.
The IKEv2-SK-Request (IKESKR) command uses Command Code 329 with the 'R' bit set and Application-Id 11. It is sent from the IKEv2 server to the HAAA to initiate IKEv2 with SK authorization, and MUST include IKEv2-Nonces and IKEv2-Identity AVPs.
The Initiator-Identity AVP (Code 591) is of type Grouped and contains a mandatory ID-Type AVP (Code 592, Enumerated) and Identification-Data AVP (Code 593, OctetString), representing the IDi payload of the IKE_AUTH message.
The Ni AVP (Code 588) is of type OctetString and contains the IKEv2 initiator nonce from the Nonce Data field. The Nr AVP (Code 589) is of type OctetString and contains the IKEv2 responder nonce.
The Responder-Identity AVP (Code 594) is of type Grouped and contains the identity type and identification data of the IDr payload of the IKE_AUTH message, reusing ID-Type (Code 592) and Identification-Data (Code 593).
IANA allocated Application Identifier value 11 for 'Diameter IKE SK (IKESK)' from the Application Identifier namespace defined in RFC 6733.
IANA allocated Command Code 329 for IKEv2-SK-Request/Answer from the Diameter Command Code namespace defined in RFC 6733.
IANA assigned Key-Type AVP value 3 to represent 'IKEv2 SK', indicating that an IKEv2 shared key is being transported in the Key AVP (defined in RFC 6734).
IANA registered eight new Diameter AVP codes: IKEv2-Nonces (587), Ni (588), Nr (589), IKEv2-Identity (590), Initiator-Identity (591), ID-Type (592), Identification-Data (593), and Responder-Identity (594).
Diameter messages between the IKEv2 server and the HAAA may traverse AAA brokers or Diameter agents and are only hop-by-hop protected; any intermediate agent processing IKEv2-SK-Answer messages can see the contents of the Key AVP, so the communication path must be secured.
To mitigate exposure of a long-lived PSK, the HAAA is expected to derive and return a session-specific SK rather than the PSK itself. Use of short-lived secrets based on prior network access authentication and the inclusion of nonces is strongly recommended to ensure key freshness and limit key scope.
The IKEv2-SK-Request message format includes mandatory Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Realm, Auth-Request-Type, IKEv2-Identity, and IKEv2-Nonces AVPs; optional fields include User-Name, Key-SPI, Destination-Host, NAS-Identifier, and NAS-IP-Address.