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 a user's secure element (e.g., a SIM card) and their home network. Many resource-constrained Internet of Things (IoT) devices, especially those deployed in scenarios like Non-Terrestrial Networks (NTN) or industrial settings, are equipped with SIMs for cellular connectivity. These devices need to establish secure end-to-end sessions with application-layer services, not just connect to the mobile network. The Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol is a lightweight key exchange designed for such constrained environments. This document defines EDHOC-AKA, a method that leverages a device's existing mobile network subscription to secure an EDHOC session. The primary innovation is its tight integration: it does not define a new standalone protocol but instead profiles the EDHOC Pre-Shared Key (PSK) method . The core concept is as follows: 1. An AKA challenge-response exchange is tunneled within the External Authorization Data (EAD) fields of the standard EDHOC message flow. 2. Upon successful AKA completion, both parties derive a shared, session-specific key, K_AKA. 3. This K_AKA is used as the PSK to complete the EDHOC-PSK handshake. This approach allows EDHOC-AKA to inherit the computational efficiency and security properties of EDHOC-PSK, such as identity protection and Perfect Forward Secrecy (PFS), while integrating seamlessly with established mobile network authentication infrastructure.

Architectural Model It is important to clarify the roles within the EDHOC-AKA exchange, as 5G-AKA is a multi-party protocol, while EDHOC is a two-party protocol. In this model: * The Initiator is the end device (e.g., IoT sensor, UE) with a SIM/UICC. * The Responder is an application-layer entity (e.g., an IoT platform, an application server) with which the Initiator wants to establish a secure session. * The Mobile Core Network (e.g., 5G Core with AMF, AUSF, UDM) is the authentication authority that holds the long-term subscription keys. The EDHOC Responder is not part of the trusted mobile core network. Instead, it acts as a proxy for the AKA authentication. The interaction is as follows: | | | 2. Request Auth Vector(SUCI)| | +--------------------->| | | | | | 3. Auth Vector(RAND,AUTN,...) | |<---------------------+ | | | 4. EDHOC msg_2(RAND,AUTN)| | |<-----------------+ | | | | 5. EDHOC msg_3(RES) | | +----------------->| | | 6. Verify RES | | | | | | | Figure 1: Architectural Flow of EDHOC-AKA ]]> This model separates application-layer session establishment from network access. The Responder leverages the mobile network as a trusted third party to verify the Initiator's identity without needing access to long-term subscription secrets.

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 .

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 . 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 . 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 . 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 . 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.

Layered Authentication and Forward Secrecy At first glance, performing an AKA exchange followed by an EDHOC-PSK handshake might seem like "double authentication". However, these two steps serve distinct purposes: AKA Exchange: Authenticates the long-term subscription identity of the Initiator to the mobile network. It proves that the device possesses the correct secret K. The derived keys CK and IK (and thus K_AKA) act as a short-lived, session-specific authorization token. EDHOC-PSK Handshake: Uses the K_AKA token to establish a mutually authenticated, forward-secret application session between the Initiator and the Responder. The key benefit is the addition of Perfect Forward Secrecy (PFS). While 5G systems can export keys for use by external applications, these exported keys may not inherently be combined with an ephemeral key exchange. By feeding the AKA-derived key into EDHOC's ephemeral Diffie-Hellman exchange, the resulting session keys are protected even if the long-term key K or the AKA session keys (CK, IK) are later compromised.