Lightweight Authenticated Key Exchange (LAKE) - IETF 123

Time

• 22 July 2025 -- 09:30-11:00 UTC (11:30-13:00 Madrid time)

Chairs

• Mališa Vučinić
• Renzo Navas

Notetakers

• Marco Tiloca
• Geovane Fedrecheski
• Rikard Höglund

Useful Links

• Charter
• Mailing list
• Instant Messaging
• Minutes
• Remote participation

Agenda

• Administrivia
  -- chairs, 3 mins
• draft-ietf-lake-ra-02
  -- Yuxuan Song, 10 mins
• draft-ietf-lake-edhoc-psk-04
  -- Elsa López, 10 mins
• draft-ietf-lake-authz-04
  -- Geovane Fedrecheski, 10 mins
• draft-ietf-lake-edhoc-impl-cons-04
  -- Marco Tiloca, 7 minutes
• draft-ietf-lake-app-profiles-02
  -- Marco Tiloca, 8 minutes
• draft-tiloca-lake-exporter-output-length-00
  -- Marco Tiloca, 5 minutes
• draft-spm-lake-pqsuites-00
  -- Göran Selander / John Preuß Mattsson, 10 mins
• KEM-based Authentication for EDHOC
  -- Lidia Pocero Fraile, 10 mins
  -- draft-pocero-authkem-edhoc
  -- draft-pocero-authkem-ikr-edhoc
• draft-uri-lake-pquake-00
  -- Uri Blumenthal, 10 mins
• Discussion on PQ EDHOC
  -- all, 7 mins
• AOB

Minutes

Administrivia (chairs, 3 mins)

RN doing introductions

draft-ietf-lake-ra (YS, 10 mins)

YS presenting

• p2 recap, support both background check and passport models, and
  have unidirection and mutual attestation
• p3: changes from ietf122
• p4: added new section for Verifier, addressing Usama's comments, now
  Verifier role is more precise
• p5: deleted error handling section -> when attestation fails it's
  not an error, it's merely an "attestation result" (as described in
  EAT draft). now instead define certain EAD items as critical
• p6: clarifications and editorial updates. explanation of
  instantiations and ead_label value settings.
• p7: Revised nesting of sections in the ToC; possible to use the
  nonce also in the Result_request to enable freshness achievement

MV: Will you present this at the RATS session on Friday?
YS: Yes, I will present in RATS on Friday afternoon
MV: Please review and provide comments on the mailing list.

draft-ietf-lake-edhoc-psk (ELP, 10 mins)

ELP presenting

• p2: status of draft. changes to mitigate reflection attacks and
  enable resumption. updates to terminology
• p3: Current bundle (CRED_PSK, PSK, ID_CRED_PSK) can be leveraged
  to mount a selfie attack, and it's not clear what should be used in
  which part of the key schedule (e.g., just the raw PSK or
  CRED_PSK).
• p4: Proposal is to define 2 credentials, CRED_I and CRED_R. These
  contain the same symmetric key and has the same identifier
  (ID_CRED_PSK), but differ as to identity information of the two
  peers (e.g., per the "sub" claim).
• p5: Current proposal on using PSK in the derivation of PRK_4e3m,
  but instead using the pair (CRED_I, CRED_R) for other key
  derivations and in the external_aad. That builds on having both
  CRED_I and CRED_R involved.
• p6: Question: should key value be included or not in the credential?
  if yes, specify not to send the actual key in the cred.
• p7: Resumption issue. currently no need to specify a new format. The
  CRED_I and CRED_R used for resumption are the same ones that were
  used in the first session of the series (irrespective of that
  session being based on PSK or not).
• p8: need to update the implementation with new test vectors
• p9: next steps. update draft and implementations. then ready for
  formal analysis.

JPM: With these changes I think we're ready for formal verification.
(after merging and then looking through the security claims.) Let's
start planning for formal verification
MV: For the next IETF meeting, we can aim triggering the formal
verification?
JPM: No need to wait. We still have to merge this and submit a new
version of the draft, but that will take less time.
MV: So as soon as we have consensus from all co-authors, we can start
the formal verification process.
JPM: Yes, and also ask the group if we're ready to trigger starting the
formal verification

MV: Elsa could you comment on the interop tests done during the
hackathon?
ELP: Did interop testing. Had 2 implementations, one in Rust from Inria
and one in C from University of Murcia. Managed to run in both
directions (initiator/responder). Worked for current draft version. Once
draft/implementation is updated, need a new interop event.
MV: All these interop events with results are documented and archived in
the Confluence page of LAKE. (lakewg.org)

draft-ietf-lake-authz (GF, 10 mins)

GF presenting

• p2: Many editorial updates done (merged PRs). One is about
  interoperability of V, now enforcing the regular flow and having the
  reverse flow as optional. Add example for stateless V.
• p3: More PRs were made and merged for the IANA considerations.
• p4: Open issue #26. Use case is identity protection service.
  Scenarios where voucher is not needed. Proposal is to make it
  optional.
• p5: Open issue #53. Allowing keys for W and V to be the same. Issue
  is re-use of salt in EDHOC_Extract(salt, IKM). Still TBD but want
  to make sure the salt is not empty and not re-used.
• p6: Open issue #71. Ongoing discussion on adding support for PQ
  cipher suites (partly covered in a later presentation today). There
  is a proposal for Göran that could be good enough for ELA.
• p7: Implementation status: We have it implemented for v-01 and
  evaluated. Plan to update implementation when things stabilize.
  Looking forward to other implementations to do interops. Let me know
• p8: Next steps are closing the still open issues; calling for
  reviews and interop tests; hoping for WGLC at the next IETF meeting.

RN: Want to do WGLC for next IETF? Need more reviews?
GF: Yes, after merging further PRs...

CA (on chat): Feel free to poke me for a review.

draft-ietf-lake-edhoc-impl-cons (MT, 7 mins)

MT presenting

• p2: Recap: Covering side-topics related to implementing EDHOC.
  Currently covering a range of topics related to implementations.
  Also covering the EDHOC & OSCORE profile of ACE, and ELA.
• p3: Updates done include rephrasing when discussing the
  authentication credentials. Also clarifications and re-ordering
  content about NO-LEARNING trust policy.

CA (in chat): minor remark (chat-only): With the new change of having a
CRED_I and a CRED_R in PSK, the change of "credentials associated
with" might not be so relevant any more.

• p4: Added short note on processing m1 and generalizing. Considering
  credentials transported in EAD items.
• p5: Added Security Consideration section, inspiration from related
  documents. For section 6.1 "assessing correctness", mentioned tools
  that can help in finding implementation issues.
• p6: v-04 includes all the authors could think to add. Want more
  feedback from other implementors. Also implementors of solutions
  building on EDHOC. If nothing more comes, ready for WGLC.

GF: I can do a review of the draft, especially focusing on ELA.
RN: Want 1 more round and then WGLC.
MT: Yes 1 more round (since there's feedback coming)

CA (in chat): I'd like to review this too, but can do that in a WGLC
too.

GF: I'd like to make comments after the draft is updated, cause I need
to update the implementation

draft-ietf-lake-app-profiles (MT, 8 mins)

MT presenting

• p2: Recap. Two EDHOC peers supposed to agree on parameters.
  Facilitate use of EDHOC application profiles. Either a la carte
  (specific individual params) or set menu (application profiles).
  Supports multiple venues to transfer this information.
• p3: Updates since v -01. Reorganize section ordering based on
  Michael suggestions. Revised error handling, specify when to abort
  or ignore.
• p4: Aligned content with other documents. This draft uses another
  item defined in the EDHOC and OSCORE ACE profile draft (shared
  namespace). Split parameters into prescriptive and non-prescriptive.
• p5: Revised use of "app_prof" parameter. If parameter present in an
  instance of ACE-Object certain restrictions are enforced.
• p6: Revised EAD item to be critical. Also specified restrictions and
  special rules for its use.
• p7: Have a way to discover EDHOC support via DNS resolution --
  coordinating with SVCB Resource Records (RR).
• p8: Next steps. Coordination with SVCB, more examples, security
  cons, possible new EAD_1.

RN: Questions?
CA (chat): I agree it should work with an existing EAD item.

MV: We concluded adopted WG drafts, now going with individual
submissions.

draft-tiloca-lake-exporter-output-length (MT, 5 mins)

MT presenting

• p2: Motivation: After EDHOC is finished peers can use the
  EDHOC_Exporter. Important outputs are the OSCORE Master
  Secret/Salt, EDHOC-PSK resumption key and its identifier. Peers need
  to agree on the output lengths. There are default values, but there
  may be reasons to deviate.
• p3: Contribution: in-band means for 2 EDHOC peers to agree on a
  particular output length. critical EAD item, not repeatable.
  Initiator/Responder can or cannot use in m1/m2. There is no counter
  offer.
• p4: Why not do this in -app-profiles? See slides for the details.
  Main points were pertinance and effectiveness. Had good discussion
  with MV. He felt there that pertinence and the efficiency issue (see
  slide) is not a big deal and that we could do this in -app-profiles
  instead.
• p5: Summary and next steps. Possibly moving it into
  draft-ietf-lake-app-profiles

MV: Main question is whether to register a new EAD item or to merge this
into the -app-profiles draft.
(3 raised hands)

CA (on chat): Skimmed, not sure if that counts.

MV: Propose we continue discussing this and depending on the comments
decide on next steps

draft-spm-lake-pqsuites (GS/JPM, 10 mins )

JPM presenting

• p1: About registering new quantum resistant cipher suites
• p2: Replacing ECC with PQC. PQC signatures and PQC KEMs are drop-in
  replacements (for ECDSA and ECDH).
• p3: Straightforward to support PQC in methods 0 and 5, just need to
  register new cipher suites. Draft specifies how EDHOC can become PQ
  resistant, and register new cipher suites.
• p4: The ephemeral KEM public key goes in G_X, while the
  encapsulation KEM ciphertext goes in G_Y.
• p5: Performance and overhead table. More signature algorithms and
  variants will come from NIST. The signature-based setting is likely
  the most promising PQC setting for EDHOC.
• p6: IANA considerations for registering the new cipher suites, and
  for marking the requirement of DH/NIKE

UB: A lot to discuss. I respectfully disagree that you cannot
authenticate with KEM as there are serveral drafts submitted
JPM: I'm only saying it requires new methods, you can't do it with the
current methods.
UB: There are options for KEM authentication which would be digital
signature sizes. As for which of those would, if at all, be standardized
by NIST or other bodies is a question. ML-DSA and FN-DSA exist now. One
has huge signatures and the other has problem with difficulty of
validating implementations.
JPM: Agree; we should look at having KEM-based authentication methods
for EDHOC. They are very orthogonal.
UB: Fully agree

QD: My guess would be that TBD1 has a tag of 128 bits?
JPM: Idea was to only go with 128 bit tags. It's aligned with the format
used in COSE, since EDHOC uses COSE.
QD: Same question about number on another line
JPM: That's 64 bit tags. This is related to JOSE/COSE naming for the
algorithms.
QD: Looks like we're doing level 1. What is motivation for using
SHAKE256?
JPM: It was already used here

FP (in chat):
https://www.iana.org/assignments/cose/cose.xhtml#algorithms
FP (in chat): example: AES-CCM-16-64-128 means AES-CCM mode 128-bit key,
64-bit tag, 13-byte nonce

KEM-based Authentication for EDHOC (LPF, 10 mins)

-- draft-pocero-authkem-edhoc
-- draft-pocero-authkem-ikr-edhoc

LPF presenting

• p2: The first draft is already implemented. Overall, we're proposing
  EDHOC methods with KEM-based authentication.
• p3: Want same security as static DH EDHOC. So use Noise XX pattern.
  Drawback is needing more EDHOC messages.
• p4-7: Showing message flow for the 5 message EDHOC and overview of
  KEM-based authentication for initiator/responder.
• p8: Showing overview of the key schedule.
• p9: Two additional messages are needed to still have,
  proof-o-possession, key confirmation and mutual authentication, on
  top of using key-based authentication.
• p10: Security considerations
• p11: Drawback: Key confirmation only proves authentication up to
  message 3.
• p12: Showing overview of scenario where the initiator knows the
  responder (IKR).
• p13: Detailed considerations for the IKR scenario

CA (on chat): Going to to 5-message EDHOC, I think we can do it, but
we'll need to generalize how downstreams use EDHOC (eg. have methods
describe whether message 4 can be implicit, and starting from which
message, payload can be sent). EDHOC-CoAP can certainly be generalized
in that sense.
CA (on chat): (Possibly also things like "you can use exported keys in
message X/Y but with caveats (such as no PFS)")

GS (on chat): Can you combine the protocol with OSCORE, like in RFC9668,
to reduce the total number of round trips for the first application
message?
MT (on chat): as a gut feeling, yes, with the combined request
transporting message_5 instead of message_3 like in RFC 9668
CA (on chat): seems to me from the first glance that we could have the
same, just 1RTT later.

DH: You're trying to map to the static and ephemeral way things were
done, so doing a lot of KEMs. Even if using the same static key, it's
not like static-static DH. No need to add ephemeral component right?
LPF: So ephemeral KEM is not needed? Then we have no forward secrecy?
DH: ML-KEM encap generates a random number for each encap. So not gonna
have the static-static problem of DH.

JPM (on chat): I support work on KEM-based authentication.
I think adding roundtrips and keeping the strong security properties is
the right approach. In addition to a KEM-KEM method, two things that
should be discussed: KEM mixed with SIG? (Suggested by Thom Wiggers at
IETF 122); Methods where Initiotor has pre-knowledge of R's key, similar
to Noise IK?
RML (on chat): I also support working with KEM-based authentication

MV: Propose we continue on the mailing list

draft-uri-lake-pquake-00 (UB, 10 mins)

UB presenting

• p1: Proposing post-quantum authenticated key exchange
• p2: Overview of purpose, properties and applications.
• p3: First you run ephemeral KEM to establish the secure channel.
  Then, in the channel, you run static KEMs for authenticating the
  peers.
• p4: Finally you achieve key confirmation. Use non-malleable
  encryption which allows for aborting
• p5: For EDHOC we want to add one more METHOD and new cipher suites.
• p6: Show EAP-PQUAKE
• p7: Performance analysis; using certain NIST building blocks would
  results in slightly worse performance.
• p8: Summary

GS (on chat): It would be good to have a detailed comparison between the
difference between Lidia's and Uri's proposal. For the final result to
be meaningful to LAKE, it need so be both an EDHOC method, preferably
building on the existing methods, and (at least eventually) formally
verified.

Discussion on PQ EDHOC (all, 7 mins)

MV: I checked with Paul (AD). If we do work on these PQ items, we need
to recharter.

Show-of-hands poll: "Raise your hand if you believe the group should
work on PQ-resistant EDHOC"

• Yes: 22
• No: 0
• No option: 3

MV: Consensus is that the WG should work on this.
MV: Next, question is what scope the WG should have. Input?
UB: Can you clarify?
MV: Either or both

JPM: If the charter does not allow to register new cipher suites, that's
strange and we should recharter at least to allow that.
QD: For the charter it would be nice to include general language that
allows looking into post-quantum designs that can do key exchange,
signatures, and see how people react to that.

JPM: COSE is now discussing to work on ASCON, which we may want to cover
in new EDHOC cipher suites to be registered in the future.
MV: We chairs will open a new thread on the mailing list about the
charter text.
CA (on chat): If we can't register even ASCON based suites, that'd sound
more like an editorial bug in the charter (can't imagine tha the
intention of the charter is that this won't work).

MV: We're in the lightweight authenticated key exchange WG, also need to
be thinking about intelligent solution to avoid transport of keys and
ciphertext to stick to being lightweight
UB: Fortunately the answer is pretty simple. In the use cases which
allow pre-loading public keys instead of exchanging over the wire,
protocols can exchange references to the keys.
JPM: It's already supported by means of credential by references.

LPF: The best way seems to allowing both signature and signature free
approaches. Also, methods can be generalized to allow for reducing
overhead

AOB

UB: There are two very similar drafts. I don't think it makes sense to
have both. Do we keep one only? Do we merge them?
MV: First need to re-charter and agree on the scope. Then future
meetings can discuss the different solutions.