[Lake] Re: welcome your comments on EDHOC-AKA based on EDHOC-PSK

[[e-mail]]

Hello Meiling,

Thank you for your email and for reaching out. I went thorugh your draft and I have some questions regarding the motivation and integrtion aspects, which I hope you could clarify.

First, regarding the architectural integration: in the draft you mention that "the Initiator (e.g., a mobile device) and a Repsonder (e.g., a service network) execute an AKA challenge-repsonse exchange". However, 5G-AKA (or EAP-AKA, also used as an authentication mechanism in cellular networks) is not a two party protocol, but involves multiple network functions. Given that EDHOC is inherently a two party protocol, I am curious how do you envision EDHOC-AKA fitting into the 5G architecture.

Second, on the motivation (and potential redunancy): from the draft, it seems like EDHOC-AKA combines an AKA-based authentication (to derive k_AKA) with a subsequent EDHOC-PSK handshake. From my perspective, this seems like a double authentication, and I am unsure of what the benefits are compared to, for example, using existing 5G key derivation/export mechanisms.

Lastly, the approach you use is to carry the AKA values inside the EAD fields, but this seems close to the already defined EAP methods. Could you elaborate on the specific benefits of this approach compared to directly using EAP? There is already a draft specifying EAP-EDHOC (https://datatracker.ietf.org/doc/draft-ietf-emu-eap-edhoc/) and EAP-AKA' is also defined on TS 33.501 version 15.9.0. 

Finally, it would be great to understand the deployment scenario.

I hope these questions are helpful, and I am looking forward to hearing from you!

Best regards,

Elsa


On 4/23/26 1:24 PM, Meiling Chen <[e-mail]> wrote:
> Dear Elsa, Göran, John, Rafael, and Francisco,
> 
> I hope this email finds you well. I have been closely following the 
> development of |draft-ietf-lake-edhoc-psk|. It provides a very clear and 
> solid foundation for pre-shared key authentication, which has been 
> instrumental for our own work.
> 
> I'm writing to you today as the author of a new Internet-Draft, |draft- 
> chen-lake-edhoc-aka|, which specifies an Authentication and Key 
> Agreement (AKA) method for EDHOC.
> 
> The main reason for this email is to introduce you that EDHOC-AKA is 
> designed as a specific profile of your EDHOC-PSK method, not as a 
> separate or competing authentication mechanism. Our approach leverages 
> the entire protocol flow and key derivation logic that you have 
> carefully defined.
> 
> The core idea is to use the 3GPP AKA protocol to dynamically generate a 
> session-specific Pre-Shared Key (which we call |K_AKA|). This AKA 
> challenge-response exchange is carried entirely within the External 
> Authorization Data (EAD) fields of the EDHOC messages.
> 
> Crucially, this means the message flow (message_1 through message_4) 
> remains identical to EDHOC-PSK. Proposing a standardized way to populate 
> the EAD fields to handle the AKA-specific parameters (like SUCI, RAND, 
> AUTN, and RES). Once the AKA exchange is complete (by message_3), the 
> derived |K_AKA| serves as the PSK for the remainder of the EDHOC-PSK 
> protocol, exactly as you have specified.
> 
> Given your deep expertise in this area, and since our work is directly 
> based on yours, it would be extremely grateful for any feedback, 
> comments, or suggestions you might have on our approach. In particular, 
> I would appreciate your thoughts on:
> 
>  1. Does this profiling approach seem reasonable to you?
>  2. Do you foresee any potential security or implementation issues with
>     using the EAD fields for this purpose within the EDHOC-PSK framework?
> 
> I believe this approach showcases a powerful use case for EDHOC-PSK, 
> especially for integrating constrained devices into mobile network 
> environments, and we want to ensure our work is well-aligned with your 
> specification.
> 
> We look forward to your valuable insights.
> 
> Best regards,
> 
> Meiling Chen
> 
> ------------------------------------------------------------------------
> [e-mail]
>