EDHOC Authenticated with AKA

Introduction The Authentication and Key Agreement (AKA) protocol is a widely used mechanism for authenticating devices in mobile networks, as specified for 3G, 4G, and 5G systems RFC4187 . It relies on a long-term symmetric key pre-shared between the user's secure element (e.g., a SIM card) and the home network. This document defines EDHOC-AKA, an authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol that utilizes the AKA mechanism. The primary innovation of EDHOC-AKA is that it does not define a new standalone protocol flow. Instead, it profiles the EDHOC Pre-Shared Key (PSK) authentication method specified in [draft-ietf-lake-edhoc-psk-06]. The core concept is as follows:

The Initiator (e.g., a mobile device) and Responder (e.g., a service network) execute an AKA challenge-response exchange.
This exchange is carried within the External Authorization Data (EAD) fields of the standard EDHOC message flow.
Upon successful completion of the AKA exchange, both parties derive a shared, session-specific key, denoted here as K_AKA.
This K_AKA is then used as the PSK required by the EDHOC-PSK authentication method.

This approach allows EDHOC-AKA to inherit the computational efficiency and security properties of EDHOC-PSK, such as identity protection against passive attackers and Perfect Forward Secrecy (PFS) against certain adversaries, while integrating seamlessly with established mobile network authentication infrastructure. This document specifies the mapping of AKA parameters to EAD fields, the derivation of K_AKA, and the necessary processing steps, while referencing [draft-ietf-lake-edhoc-psk-06] for the underlying protocol mechanics.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174]. Readers are expected to be familiar with the terms and concepts described in EDHOC and EDHOC-PSK [draft-ietf-lake-edhoc-psk-06].

AKA: Authentication and Key Agreement. A challenge-response protocol based on a symmetric key.
K: The long-term secret key shared between a user's secure element and their home network.
SUPI/SUCI: Subscription Permanent Identifier / Subscription Concealed Identifier. The user's permanent and concealed identities in 5G.
AKA Vector: A set of parameters generated by the network for an AKA challenge, typically including RAND (random challenge), AUTN (authentication token), XRES (expected response), CK (ciphering key), and IK (integrity key).
K_AKA: A session-specific key derived from the AKA-generated keys (CK, IK), which serves as the PSK for the EDHOC-PSK protocol.

Protocol

Relationship to EDHOC-PSK EDHOC-AKA is a profile of EDHOC-PSK and follow the protocol flow, key derivation logic, and message formatting specified in [draft-ietf-lake-edhoc-psk-06]. The fundamental difference lies in how the PSK is obtained. In a typical EDHOC-PSK scenario, the PSK is a static key provisioned out-of-band. In EDHOC-AKA, the PSK is dynamically derived in each session via an AKA exchange. This AKA exchange is performed using the EAD mechanism defined in .

Deriving the Session-Special PSK(K_AKA) The Responder (network) initiates an AKA challenge by obtaining an AKA vector from the home network based on the Initiator's identity. The Initiator responds to the challenge. If the exchange is successful, both parties derive the session keys CK and IK. These keys are then used to derive K_AKA, which will be used as the PSK for the current EDHOC session. The key derivation function (KDF) for this purpose is application-specific but MUST produce a key of the length required by the selected EDHOC cipher suite. For example, a common method is to use the EDHOC-KDF: K_AKA = EDHOC-KDF(CK, "K_AKA", IK, desired_key_length) The context string "K_AKA" ensures that the derived key is unique to this purpose.

Message Flow of EDHOC-AKA The message flow is identical to that of EDHOC-PSK, as shown in Figure 1 of [draft-ietf-lake-edhoc-psk-06]. The AKA-specific parameters are transported in EAD fields as follows:

EAD_1: Sent by the Initiator in message_1. It contains the Initiator's identity (e.g., SUCI) needed by the Responder to fetch the correct AKA vector.
EAD_2: Sent by the Responder in message_2. It contains the AKA challenge parameters (RAND and AUTN).
EAD_3: Sent by the Initiator in message_3. It contains the AKA response (RES).
EAD_4: Sent by the Responder in message_4. It MAY contain a final confirmation of the AKA authentication result from the network.

| message_1 | | | G_Y, Enc(C_R, EAD_2({RAND,AUTN}))| |<-------------------------------------------+ message_2 | | | Enc(ID_CRED_PSK, AEAD(EAD_3({RES}))) | +------------------------------------------> | message_3 | | | AEAD(EAD_4({Auth-Result})) | |<-------------------------------------------+ message_4 | | Figure 1: Overview of Message Flow of EDHOC-AKA ]]> The field ID_CRED_PSK is used as defined in [draft-ietf-lake-edhoc-psk-06]. It may contain an identifier related to the ongoing AKA session or the long-term subscription to help the Responder manage keying material.

Key Derivation The key derivation schedule for EDHOC-AKA SHALL be identical to the one specified in Section 4 of [draft-ietf-lake-edhoc-psk-06]. The key derivation for PRK_4e3m is: PRK_4e3m = EDHOC_Extract(SALT_4e3m, PSK) For EDHOC-AKA, the PSK used in this formula is the session-specific K_AKA derived from the AKA exchange, as described in Section 3.2 of this document. All other PRKs and derived keys (e.g., PRK_out, K_3, IV_3) are computed exactly as specified in the EDHOC-PSK draft.

Message Formating and Processing Message formatting and processing SHALL follow the specifications in Section 5 of [draft-ietf-lake-edhoc-psk-06]. This section outlines the additional processing steps related to the EAD fields for the AKA exchange.

Message1 Message 1 (Initiator -> Responder) Initiator: The Initiator composes message_1 as specified in [draft-ietf-lake-edhoc-psk-06]. The METHOD selected is EDHOC-AKA (TBD1). The Initiator MUST include an EAD_1 field containing its identity (e.g., SUCI), formatted with the appropriate EAD label (see Section 6.2). Responder: The Responder processes message_1 and uses the identity from EAD_1 to request an AKA vector from the home network.

Message2 Message 2 (Responder -> Initiator) Responder: After obtaining the AKA vector, the Responder composes message_2 as specified in [draft-ietf-lake-edhoc-psk-06]. It MUST include an EAD_2 field containing the RAND and AUTN values, each formatted with the appropriate EAD label. Initiator: The Initiator decrypts message_2 to retrieve EAD_2. It passes the AUTN and RAND to its secure element to verify the network's authenticity and compute the response RES, as well as the keys CK and IK. If verification succeeds, it derives K_AKA as per Section 3.2.

Message3 Message 3 (Initiator -> Responder) Initiator: The Initiator composes message_3 as specified in Section 5.3.2 of [draft-ietf-lake-edhoc-psk-06]. It uses the derived K_AKA as the PSK for this process. It MUST include an EAD_3 field containing the computed RES, formatted with the appropriate EAD label. Responder: The Responder processes message_3 as specified in Section 5.3.3 of [draft-ietf-lake-edhoc-psk-06]. To do this, it must first derive the same K_AKA from the CK and IK it holds. A successful decryption of message_3 implicitly authenticates the Initiator. The Responder then extracts RES from EAD_3 and compares it with its expected XRES. If they match, the AKA authentication is fully successful.

Message4 Message 4 (Responder -> Initiator) As noted in [draft-ietf-lake-edhoc-psk-06], message_4 is required for mutual authentication. It proves to the Initiator that the Responder also successfully derived K_AKA and completed the protocol. The Responder MAY include an EAD_4 field to convey the final status of the authentication from the network's perspective.

IANA Considerations

EDHOC Method Type Registry IANA is requested to register the following entry in the "EDHOC Method Type" registry under the group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)". NOTE: Suggested value: TBD1 = 5. RFC Editor: Remove this note.

EDHOC EAD Label Registry IANA is requested to register the following entries in the "EDHOC EAD Label" registry. NOTE: Suggested values: TBD2-TBD6 = sequential integers. RFC Editor: Remove this note.

Security Considerations As EDHOC-AKA is a profile of EDHOC-PSK, it inherits the security properties analyzed in Section 9 of [draft-ietf-lake-edhoc-psk-06]. This section discusses considerations specific to the AKA integration. Mutual Authentication: Strong mutual authentication is achieved. The Initiator authenticates the network by validating AUTN in message_2. The network authenticates the Initiator through two mechanisms: first, by the successful decryption of message_3 (which requires the correct K_AKA), and second, by the explicit validation of RES from EAD_3. Identity Protection: The Initiator's permanent identity (SUPI) is protected by using a concealed identity (SUCI) in EAD_1, which is only sent in the first message. The rest of the exchange is protected by keys derived from the ephemeral Diffie-Hellman exchange, providing identity protection against passive attackers as per EDHOC-PSK. Forward Secrecy: The protocol provides PFS. Even if the long-term key K is compromised, past session keys remain secure because they are derived from the ephemeral DH shared secret G_XY. An attacker who compromises K can impersonate the user in future sessions but cannot decrypt past traffic. Key Binding: The final session keys (derived from PRK_out) are cryptographically bound to both the ephemeral DH secret (G_XY) and the AKA-derived session key (K_AKA). This provides strong resistance against key-compromise and misbinding attacks. AKA Vector Handling: The AKA vector components (RAND, AUTN) are transported in an encrypted portion of message_2. This protects them from passive observation, though not from an active attacker who can manipulate the first two messages. The security of the AKA mechanism itself relies on the integrity of AUTN, which is handled by the Initiator's secure element.