[Lake] Re: WG Last Call: draft-ietf-lake-edhoc-psk-08 (Ends 2026-07-15)

[Erik Anderlind <[e-mail]>]

Hi all,

I support the publication of this document.

Please find below some comments on this latest version.

Cheers
  Erik

Section 3.1.1:

* Suggest add a reference to RFC8152 section 3.1 that defines a key identifier and it’s properties
   kid:  This parameter identifies one piece of data that can be used as
         input to find the needed cryptographic key.  The value of this
         parameter can be matched against the 'kid' member in a COSE_Key
         structure.  Other methods of key distribution can define an
         equivalent field to be matched.  Applications MUST NOT assume that
        'kid' values are unique.  There may be more than one key with the
        same 'kid' value, so all of the keys associated with this 'kid'
        may need to be checked.  The internal structure of 'kid' values is
        not defined and cannot be relied on by applications.  Key
        identifier values are hints about which key to use.  This is not a
        security-critical field.  For this reason, it can be placed in the
        unprotected headers bucket.
OLD>  
ID_CRED_PSK is a COSE header map containing header parameters that can identify a pre-shared key.

NEW>
ID_CRED_PSK is a key identifier (RFC8152 section 3.1) formatted as a COSE header map containing header parameters that can identify a pre-shared key.

OLD>
The same PSK can be identified by different ID_CRED_PSK values in different sessions, in particular when initiated by the other party.

NEW>
There may be more than one key with the same ID_CRED_PSK value, so all of the keys associated with this value may need to be checked.

* The ID_CRED_PSK is used to retrieve more than just a key. Might it be useful to state it retrieves one or several candidate key context(s), each consisting of {key value, ID_CRED_I, ID_CRED_R, EDHOC Hash algorithm}? 
(In both of the above text proposals, would then suggest replace ‘key’ with ‘key context’, perform similar substitutions elsewhere in 3.1.1
and add a definition of key context.)

* The last paragraph in section 3.1.1 is recommending ID_CRED_PSK be either unique or stochastically generated. The required processing of message 3 differs according to the chosen approach. I suggest spec should adhere to the above COSE definition of a non-unique key identifier and describe steps that need to be repeated for each candidate key context. The paragraph starting with “It is RECOMMENDED that ID_CRED_PSK …” would need to be adjusted accordingly.

* Currently the text in 3.1.1 mentions the ‘kid’ but doesn’t require it to be present. Might it be useful to state somewhere that the application profile defines the COSE header map format(s) that must be supported?

Section 3.1.3:

* Suggest remove third bullet, as it is an external system constraint that can’t be guaranteed by an implementation:

OLD>
 * ID_CRED_PSK SHOULD uniquely identify the corresponding PSK to avoid ambiguity. When ID_CRED_PSK contains a key identifier, care must be taken to ensure that 'kid' is unique for the PSK.
NEW>
_


Section 5.3.3:

* Assuming the restructuring proposal from Marco is accepted, suggest further clarify where reprocessing for each candidate key context is necessary.  I am unsure whether EDHOC key hash algorithm should be mentioned as a possible criteria to whittle down the set of candidate keys.

MARCO>
>  * Use ID_CRED_PSK to identify the authentication credentials and retrieve PSK, CRED_I, and CRED_R.
>   >
>   > * Derive K_3 and IV_3 as defined in Section 4.
>   >
>   > * AEAD-decrypt …


NEW>
* Use ID_CRED_PSK to identify candidate authentication credentials and retrieve corresponding PSK, CRED_I and CRED_R

* Select first candidate

* Derive K_3 and IV_3 as defined in Section 4.

* AEAD-decrypt CIPHERTEXT_3B using:
  (keep all the sub bullets as are)

If AEAD verification fails, retry with a new candidate. If all candidate authentication credential sets fail, this indicates a processing problem or that the message was tampered with. If verification succeeds with a candidate set, the Responder concludes ….


Section 6:

* Last paragraph before section 6.1 doesn’t reflect need to retain CRED_X needed for key derivation. If a credential associated with a resumption key expires, should retry either with external PSK or a different METHOD.

OLD>
     When resumption PSKs are in use, implementations MAY retain 
     the credentials used for the original non-resumption authentication 
     (e.g., the external PSK, static DH keys, or certificates) alongside
     the current resumption PSK to allow fallback if resumption fails. If
     fallback authentication uses an external PSK, the Initiator selects
     which PSK to present via ID_CRED_PSK. How long the original
     authentication credentials are retained is determined by the
    application profile or by the expiration time of the credential
   (e.g., the exp claim in a CWT). Key lifetime and retention policy
   are determined by the application profile.

NEW>
When resumption PSKs are in use, implementations MUST retain 
the ID_CRED_I, ID_CRED_R and EDHOC hash algorithm used for the original
non-resumption authentication (e.g., the static DH public keys, or certificates) 
and associate them with the current resumption PSK.
Implementations MAY retain the external ID_CRED_PSK and associated PSK to allow 
fallback if resumption fails. If fallback authentication uses an external PSK, the Initiator 
selects which PSK to present via ID_CRED_PSK.  If a credential associated with a 
resumption key expires, implementations SHOULD retry either with external PSK 
or a different METHOD. How long the original authentication 
credentials are retained is determined by the application profile or by the expiration time 
of the credential (e.g., the exp claim in a CWT). Key lifetime, retention, and retry policy are 
determined by the application profile. 

Section 7:

* The text mentions EAP-EDHOC and EAP-EDHOC-PSK. Are these the same thing, or might the 2nd case better be expressed
  as "EAP-EDHOC with an external PSK”?

* EAP-TLS [RFC9190] describes use of PSK for resumption. Unclear what the intent is of the last sentence in section 7. 
  If EAP-EDHOC is a different EAP method than EAP-PSK and EAP-TLS, isn’t it already clear they are not substitutions?


> On Jul 9, 2026, at 3:14 PM, Marco Tiloca <marco.tiloca=[e-mail]> wrote:
> 
> Hi all,
> 
> I support the publication of this document.
> 
> Please find below some comments on this latest version.
> 
> Best,
> /Marco
> 
> 
> 
> [Section 1]
> 
> * It says:
> 
>   > The PSK method retains mutual authentication, ephemeral asymmetric key exchange, and identity protection properties of [RFC9528].
> 
>   Like clarified already in the next paragraph, the identity protection is against passive attackers. With respect to the Initiator, that's a difference from RFC 9528.
> 
>   You can have a phrasing more aligned to that used in the abstract, like:
> 
>   > The PSK method provides mutual authentication, ephemeral asymmetric key exchange, and identity protection.
> 
> 
> [Section 2]
> 
> * Expand "CBOR", "COSE", "CWT", and "CCS". Then there's no need to expand "CWT" and "CCS" in the later Section 3.1.2.
> 
> 
> [Section 3.1.3]
> 
> * It says:
> 
>   > ... These optimizations MUST NOT be applied in COSE header parameters or in other contexts where the full map structure is required. For example:
>   >
>   > - { 4 : h'0f' } encoded as h'0f' (CBOR byte string)
>   >
>   > - { 4 : 21 } encoded as 0x15 (CBOR integer)
> 
>   The COSE header parameter 'kid' can only have bstr as value type, so the second case in the example is not valid.
> 
>   Also, the example is indeed showing to keep the value of kid as-is, but also to use that value alone instead of the whole map.
> 
>   To give examples for when the optimizations are not used, and based on what is defined in Sections 3.5.3.2 and 3.3.2 of RFC 9528, shouldn't the text say the following?
> 
>   > - { 4 : h'0f' } is encoded as 0xa104410f, instead of 0x410f (CBOR encoding of the CBOR byte string h'0f')
>   >
>   > - { 4 : h'15' } is encoded as 0xa1044115, instead of 0x15 (CBOR encoding of the CBOR integer 21)
> 
> 
> [Section 3.2]
> 
> * It says:
> 
>   > If the Diffie-Hellman procedure is replaced by a KEM, then G_X and G_Y are encapsulation key and ciphertext, respectively, and the shared secret G_XY is derived by the KEM, see [I-D.spm-lake-pqsuites].
> 
>   I suggest to rephrase as:
> 
>   > If the Diffie-Hellman procedure is replaced by a KEM (e.g., see [I-D.spm-lake-pqsuites]), then G_X and G_Y are encapsulation key and ciphertext, respectively, and the shared secret G_XY is derived by the KEM.
> 
>   This should make it possible to have [I-D.spm-lake-pqsuites] as an informative reference, instead of normative (anyway to be replaced with a reference to draft-ietf-lake-pqsuites)
> 
> 
> [Section 5.3.1]
> 
> * Aligned with the wording in Section 5.2.1:
> 
>   OLD
>   Message 3 is formatted as specified in Section 5.4.1 of [RFC9528].
> 
>   NEW
>   Message 3 is formatted as specified in Section 5.4.1 of [RFC9528], except that CIPHERTEXT_3 is replaced by CIPHERTEXT_3A.
> 
> 
> [Section 5.3.3]
> 
> * The first bullet point is:
> 
>   > Derive K_3 and IV_3 as defined in Section 4.
> 
>   However, it can't really be performed at first, since that requires PRK_4e3m, which requires PRK, which the Responder can't retrieve right from the start.
> 
>   Suggested reordering/rephrasing of steps:
> 
>   OLD
>   > * Derive K_3 and IV_3 as defined in Section 4.
>   >
>   > * Parse the structure of message_3, which consists of a stream-cipher encrypted structure, CIPHERTEXT_3A = PLAINTEXT_3A XOR KEYSTREAM_3A, where PLAINTEXT_3A = ( ID_CRED_PSK, CIPHERTEXT_3B ) and CIPHERTEXT_3B is the inner AEAD-encrypted object.
>   >
>   > * Generate KEYSTREAM_3A with the same method the Initiator used.
>   >
>   > * Decrypt CIPHERTEXT_3A using binary XOR with KEYSTREAM_3A to recover PLAINTEXT_3A.
>   >
>   > * Use ID_CRED_PSK to identify the authentication credentials and retrieve PSK, CRED_I, and CRED_R.
>   >
>   > * AEAD-decrypt ...
> 
>   NEW
>   > * Generate KEYSTREAM_3A with the same method the Initiator used.
>   >
>   > * Decrypt CIPHERTEXT_3A using binary XOR with KEYSTREAM_3A to recover PLAINTEXT_3A.
>   > * Parse the structure of PLAINTEXT_3A = ( ID_CRED_PSK, CIPHERTEXT_3B ), where CIPHERTEXT_3B is the inner AEAD-encrypted object.
>   >
>   > * Use ID_CRED_PSK to identify the authentication credentials and retrieve PSK, CRED_I, and CRED_R.
>   >
>   > * Derive K_3 and IV_3 as defined in Section 4.
>   >
>   > * AEAD-decrypt ...
> 
> * It says:
> 
>   > AEAD algorithm from cipher suite
> 
>   Like in Section 5.3.2, it can better say:
> 
>   > EDHOC AEAD algorithm of the selected cipher suite
> 
> 
> [Section 6]
> 
> * It says:
> 
>   > * hash_length is the output size of the EDHOC hash algorithm associated with the PSK.
> 
>   To fully understand this, one has to get to the later text in Section 9.5.
> 
>   In this section, I suggest to extend the quoted text as below:
> 
>   > * hash_length is the output size of the EDHOC hash algorithm associated with the PSK, i.e, the EDHOC hash algorithm of the selected cipher suite used in the EDHOC session in which the resumption PSK is established.
> 
> * The paragraph "A peer that has successfully ..." says that a resumption key MAY be generated.
> 
>   Later on, it is said:
> 
>   > The Initiator MAY delete rPSK_i after successfully verifying the fourth message. At that point, the Initiator can be certain that the Responder already has derived the next resumption key, rPSK_(i+1).
> 
>   However, the Initiator doesn't have such strong certainties. Isn't it as below instead?
> 
>   > The Initiator MAY delete rPSK_i after successfully verifying the fourth message. At that point, the Initiator can be certain that the Responder is able to derive the next resumption key rPSK_(i+1), if the Responder wants to.
> 
>   Similarly, the next paragraph (currently swapping "Initiator" and "Responder" in its last sentence) should say:
> 
>   > ... At that point, the Responder can be certain that the Initiator is able to derive the next resumption key rPSK_(i+1), if the Initiator wants to.
> 
> * It says:
> 
>   > Support for resumption MAY be indicated using means defined in [I-D.ietf-lake-app-profiles].
> 
>   I suggest to rephrase as:
> 
>   > Support for resumption can be indicated, for example, by using means defined in [I-D.ietf-lake-app-profiles].
> 
>   This should make it possible to have [I-D.ietf-lake-app-profiles] as an informative reference, instead of a (mutually!) normative one as it is the case now.
> 
> 
> 
> [Section 8]
> 
> * It says:
> 
>   > ... but key confirmation of the Responder can instead be provided by a subsequent OSCORE response to the Initiator.
> 
>   I think it's better to say:
> 
>   > ... but key confirmation of the Responder is provided by a subsequent OSCORE response to the Initiator.
> 
>   See the MUST in https://www.rfc-editor.org/info/rfc9668/#section-3.3.1-3
> 
> * It says:
> 
>   > In EDHOC-PSK, authentication of the Responder is provided by message_4. Nonetheless, the combined delivery, described in Section 3 of [RFC9668], can still be applied to EDHOC-PSK.
> 
>   Based on Sections 3.2 and 5.4, I think you mean:
> 
>   > In EDHOC-PSK, authentication of the Responder is provided by EDHOC message_4 or another fourth message. Hence, the combined delivery described in Section 3 of [RFC9668] can be applied to EDHOC-PSK.
> 
> 
> [Section 9.5]
> 
> * It says:
> 
>   > If a PSK is combined with a different hash algorithm, the Responder MUST reject the ongoing EDHOC session.
> 
>   I guess you mean "different" from that in the selected cipher suite of the ongoing session.
> 
>   Suggested rephrasing:
> 
>   > The Responder MUST abort the ongoing EDHOC session, if the PSK retrieved through ID_CRED_PSK is combined with a hash algorithm different from the one in the selected cipher suite used in the session.
> 
> 
> [Section 9.10]
> 
> * It says:
> 
>   > Other implementations may replace message_4 with a protected application message. In this case, the following requirement applies: The Initiator SHALL NOT persistently store PRK_out or derived application keys until it has successfully verified message_4 or a message protected with an exported application key (e.g., an OSCORE message).
> 
>   "In this case" seems to point to the previous sentence where message_4 is replaced by something else. However, what follows defines the requirement in general terms. What about:
> 
>   OLD
>   In this case, the following requirement applies:
> 
>   NEW
>   In general, the following requirement applies:
> 
> 
> [Section 9.11]
> 
> * As per a previous comment about about Section 3.2, rephrasing text there should allow to have the reference [I-D.spm-lake-pqsuites] simply informative (also to be replaced with a reference to draft-ietf-lake-pqsuites)
> 
> * As per a previous comment about about Section 5.4, rephrasing text there should allow to have the reference [I-D.ietf-lake-app-profiles] simply informative.
> 
> 
> [Nits]
> 
> * Section 3.1.1
> --- s/facilitate retrieval/facilitate the retrieval
> --- Make a hyperlink for "Section 3.5.3.2 of [RFC9528]"
> 
> * Section 5
> --- s/that if any/that, if any
> 
> * Section 5.2.1
> --- Make a hyperlink for "Section 5.3.1 of [RFC9528]"
> 
> * Section 5.2.2
> --- s/C_R, EAD_2 are/C_R and EAD_2 are
> 
> * Section 5.3.2
> --- s/of COSE_Encrypt0 object/of the COSE_Encrypt0 object
> --- s/[RFC9528], with the EDHOC AEAD/[RFC9528], computed with the EDHOC AEAD
> 
> * Section 9.5
> --- s/entropy, and MUST/entropy and MUST
> --- s/the cipher suite selected in/the selected cipher suite used in
> 
> * Section 9.11
> --- Make a hyperlink for "Section 9.2"
> 
> 
> From: Mališa Vučinić via Datatracker <[e-mail] <mailto:[e-mail]>>
> Sent: Wednesday, July 1, 2026 5:32 PM
> To: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Subject: [Lake] WG Last Call: draft-ietf-lake-edhoc-psk-08 (Ends 2026-07-15)
>  
> This message starts a WG Last Call for:
> draft-ietf-lake-edhoc-psk-08
> 
> This Working Group Last Call ends on 2026-07-15
> 
> Abstract:
>    This document specifies a Pre-Shared Key (PSK) authentication method
>    for the Ephemeral Diffie-Hellman Over COSE (EDHOC) Lightweight
>    Authenticated Key Exchange (LAKE) protocol.  The PSK method provides
>    mutual authentication, ephemeral key exchange, identity protection,
>    and quantum resistance while incurring lower computational costs than
>    the public-key authentication methods specified for EDHOC.  It is
>    suited for systems where nodes share a PSK provided out-of-band
>    (external PSK) and enables efficient session resumption with less
>    computational overhead when the PSK is provided from a previous EDHOC
>    session (resumption PSK).  This document details the PSK message
>    flow, key derivation changes, message formatting, processing, and
>    security considerations.
> 
> File can be retrieved from:
> 
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping [e-mail] <mailto:[e-mail]>
> in copy. Objections should be explained and suggestions to resolve them are
> highly appreciated.
> 
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> Appropriate IPR disclosures required for full conformance with the provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
> 
> Thank you.
> 
> [1] https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp78%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452226195%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P5y%2BRlx6oza8PwAHKl4n%2F33bMcx48mbQ9101bO8qAO4%3D&reserved=0 <https://datatracker.ietf.org/doc/bcp78/>
> [2] https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp79%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452253807%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pDyDwlH2mecnv9a0oTqbD6sbEgBQ%2F7x9s4F8yNGKD%2Bo%3D&reserved=0 <https://datatracker.ietf.org/doc/bcp79/>
> [3] https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc6701%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452271336%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=arlEqlDhTIntKyT4iuUdhB4bjefczXnYQ%2F6mWHQx6SM%3D&reserved=0 <https://datatracker.ietf.org/doc/rfc6701/>
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lake-edhoc-psk%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452288781%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3XRUM4aGtCV9MOT4ow6ryc0%2FA4IhdDXNbAj5Qgif0gQ%3D&reserved=0 <https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-psk/>
> 
> There is also an HTML version available at:
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-lake-edhoc-psk-08.html&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452305382%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Lo6wljdeFgcJY62hqhP1csw1wqqR8ecpHK6cEW5xhIU%3D&reserved=0 <https://www.ietf.org/archive/id/draft-ietf-lake-edhoc-psk-08.html>
> 
> A diff from the previous version is available at:
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-lake-edhoc-psk-08&data=05%7C02%7Cmarco.tiloca%40ri.se%7Cf2683847d11d4139c21908ded7862b2a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639185168452321873%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AnqRE2P%2BK1g94EZIx2Z1mV7I8WCPwraG1yYKL%2FLazDM%3D&reserved=0 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-lake-edhoc-psk-08>
> 
> -- 
> Lake mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> -- 
> Lake mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>