[Lake] Re: LAKE-EDHOC-PSK Potential Issue

[John Mattsson <[e-mail]>]

Thanks Francisco,

That seems correct. We will fix that in the next version.

Cheers,
John

From: FRANCISCO LOPEZ GOMEZ <[e-mail]>
Date: Tuesday, 18 February 2025 at 15:09
To: [e-mail] <[e-mail]>
Subject: [Lake] LAKE-EDHOC-PSK Potential Issue
Hi all,
I have identified a potential issue in the EDHOC-PSK draft specification (draft-ietf-lake-edhoc-psk-02).
The issue is in the calculation of Transcript Hash 3 (TH_3), which is defined as follows:
TH_3 = H( TH_2, PLAINTEXT_2, CRED_PSK )
TH_3 is then used to generate KEYSTREAM_3:
KEYSTREAM_3 = EDHOC_KDF( PRK_3e2m, TBD, TH_3, ID_CRED_PSK length )
KEYSTREAM_3 is used by the Initiator to encrypt ID_CRED_PSK before sending it in message_3. Consequently, the Responder needs to derive the same KEYSTREAM_3 to decrypt ID_CRED_PSK when processing message_3.
The issue is that TH_3 already includes CRED_PSK. However, the Responder requires KEYSTREAM_3 to decrypt ID_CRED_PSK and determine which PSK should be used. This creates a circular dependency:

  1.  To derive KEYSTREAM_3, the Responder must first compute TH_3.
  2.  Computing TH_3 requires CRED_PSK, which depends on knowing the correct PSK.

  1.  However, the Responder can only determine the correct PSK after decrypting ID_CRED_PSK using KEYSTREAM_3.
Best regards,
Francisco.