| Internet-Draft | EDHOC PSK AKA | October 2026 |
| Chen, et al. | Expires 13 April 2027 | [Page] |
This document defines an Authentication and Key Agreement (AKA) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. This method, named EDHOC-AKA, is designed as a specific profile of the EDHOC Pre-Shared Key (PSK) authentication method defined in [I-D.ietf-lake-edhoc-psk].¶
EDHOC-AKA enables a resource-constrained device (Initiator), which has a mobile network subscription (e.g., a SIM/UICC), to establish a secure, forward-secret session with an application server (Responder). It achieves this by embedding a 3GPP AKA challenge-response exchange within the standard EDHOC message flow using External Authorization Data (EAD) fields. The EDHOC Responder acts as a proxy, relaying AKA messages to the mobile core network.¶
Upon successful AKA authentication, a session-specific key is derived and used as the Pre-Shared Key for the EDHOC-PSK protocol. This approach provides efficient, end-to-end authenticated session establishment for scenarios like Non-Terrestrial Networks (NTN) or massive IoT, while inheriting the security properties of EDHOC-PSK, including mutual authentication, identity protection, and strong forward secrecy. It offers a highly integrated and byte-efficient alternative to more generic frameworks like EAP.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC5448] [RFC9048]. 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 [RFC9528] 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 [I-D.ietf-lake-edhoc-psk].¶
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.¶
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:¶
Initiator Responder Mobile Core
(EDHOC Client) (Application Server) (e.g., 5G-Core)
| | |
1. EDHOC msg_1(SUCI) | |
+----------------->| |
| 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.¶
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 [RFC9528] and EDHOC-PSK [I-D.ietf-lake-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.¶
EDHOC-AKA is a profile of EDHOC-PSK and follow the protocol flow, key derivation logic, and message formatting specified in [I-D.ietf-lake-edhoc-psk]. 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 [RFC9528].¶
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.¶
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.¶
Initiator Responder
| |
| METHOD, SUITES_I, G_X, C_I, EAD_1({SUCI}) |
+------------------------------------------> | 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.¶
The key derivation schedule for EDHOC-AKA SHALL be identical to the one specified in Section 4 of [I-D.ietf-lake-edhoc-psk].¶
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 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.¶
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.¶
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.¶
Message 3 (Initiator -> Responder) Initiator: The Initiator composes message_3 as specified in Section 5.3.2 of [I-D.ietf-lake-edhoc-psk]. 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 [I-D.ietf-lake-edhoc-psk]. 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.¶
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 is requested to register the following entry in the "EDHOC Method Type" registry under the group name "Ephemeral Diffie-Hellman Over COSE (EDHOC)".¶
+-------+----------------------------+----------------------------+
| Value |Initiator Authentication Key|Responder Authentication Key|
+-------+----------------------------+----------------------------+
| TBD1 | EDHOC-AKA | EDHOC-AKA |
+-------+---------------------- -----+----------------------------+
Table 1: Addition to the EDHOC Method Type Registry.
¶
NOTE: Suggested value: TBD1 = 5. RFC Editor: Remove this note.¶
IANA is requested to register the following entries in the "EDHOC EAD Label" registry.¶
+-------+--------------------+----------------------------+
| Label |Description |Reference |
+-------+--------------------+----------------------------+
| TBD2 |AKA SUCI | this document |
+-------+--------------------+----------------------------+
| TBD3 |AKA RAND | this document |
+-------+--------------------+----------------------------+
| TBD4 |AKA AUTN | this document |
+-------+--------------------+----------------------------+
| TBD5 |AKA RES | this document |
+-------+--------------------+----------------------------+
| TBD6 |AKA Auth-Result | this document |
+-------+--------------------+----------------------------+
Figure 3: EAD labels
¶
NOTE: Suggested values: TBD2-TBD6 = sequential integers. RFC Editor: Remove this note.¶
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.¶
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.¶