# Lightweight Authenticated Key Exchange (LAKE) - Interim {#lightweight-authenticated-key-exchange-lake---interim} ## Wednesday, 7 February 2023 -- 17:00-18:00 UTC {#wednesday-7-february-2023--1700-1800-utc} ### [Chairs](mailto:lake-chairs@ietf.org): {#chairs} * Mališa Vučinić * Stephen Farrell ### Useful Links: {#useful-links} * [Charter][1] * [Mailing list][2] * [Instant Messaging][3] * [Minutes][4] * [Remote participation][5] ### Agenda: {#agenda} * Administrivia -- chairs, 5 mins * Status of EDHOC -- John Preuß Mattsson & Goran Selander, 10 mins * EDHOC rekeying -- Rafa Marin-Lopez & John Preuß Mattsson, 15 mins * Guidelines for EDHOC implementations -- Marco Tiloca, 15 mins * EDHOC EAD items -- Mališa Vučinić, 5 mins * Open discussion on rechartering -- chairs, 10 mins * AOB ### Minutes: {#minutes} * Administrivia (chairs, 5 mins) * MV doing introductions * Status of EDHOC (Goran Selander, 10 mins) * GS presenting * GS: v -18 addressed WGLC comments; the latest v -19 addressed directorate reviews, plus comments/reviews from MV and SF. * GS: overview of changes in v -18. Padding done through EAD items; semantics of EAD in general; encoding of identifiers; what is handled to the application; relation between EDHOC and OSCORE identifiers; ... * GS: overview of changes in v -19 (no changes on the wire). Several clarifications on the crypto, transport properties and message correlation; terminology; ... * GS: New appendix with an example of state machine for both Initiator and Responder. * GS: Appendix A now says what is normative when EDHOC is transported in CoAP, and gives a name to the Client- and Server-initiated workflow. * GS: Revised IANA considerations on Methods, Error Codes, EAD labels and Cipher suites. * GS: Waiting for the AD review. We also plan to resubmit the -trace draft. * CB: On the state machines, they look very linear. We tend to think of single protocol runs. Is there any possible forking in these state machines? E.g., receiving a same message twice. * GS: The replica would not be accepted and processed. * CB: So the first packet wins. * GS: Yes. * JPM: Whichever packet wins is processed. * MCR (on chat): But you don't abort if the crypto fails right? * GS: You abort if anything fails. * CB: What does it mean if one DoS this? * JPM: Aborting increases the security properties. * MT (on chat): My understanding is that the only failure that might not result in aborting is the failed processing of non-critical EAD items * SF: This state machine is not changing the behavior of the protocol. Please continue the discussion on the mailing list. * MV: Any timeline about getting the AD review? * PW: I hope to finish this week, so it should be ready next week or the week after. * EDHOC rekeying (Rafa Marin-Lopez & John Preuß Mattsson, 15 mins) * RML and JPM presenting * RML: We're defining an EAP method using EDHOC for authentication. There we need resumption capabilities, trying to avoid asymmetric operations. If EDHOC has a rekeying mechanism, that could be useful to use in the EAP method. * RML: We discussed four options on the mailing list: 1) re-run EDHOC; 2) PSK with ECDHE; 3) PSK with random values but no ECDHE; 4) new PSK derivation without new randomness. We don't want (4). * JPM: (2) and (3) eliminate all external things. (2) provides better security than (3), which might though be fine for a short time. An EDHOC method for rekeying can be specified as similar to TLS resumption. Does PSK-based authentication make sense in EDHOC other than for key update? * JPM: It feels better if a method for rekeying with EDHOC is defined in LAKE. This can start by registering alternative (2) above as a new EDHOC Method 4, together with labels for deriving the new keyign material. * Guidelines for EDHOC implementations (Marco Tiloca, 15 mins) * MT presenting, was covered in London before briefly * Idea is guidelines for implementers would be useful * slide 3: guidance on when EDHOC sessions or derived application keying material become invalid, and what to do then in terms of update * slide 4: handling new authentication credentials, guidance on various "trust models" * slide 5: guidance on implementation structures, considering that the processing of an incoming EDHOC message has to temporarily "give control" to the application in order to process authentication credentials and consume/produce EAD items. * The proposal is to consider an Informational draft with such guidance. * GS: wondering about TOFU bullet on slide 4, upshot is it'd be clarified if this work goes ahead. * MT: You still need to validate the credential under that trust model, but if it is valid (and it can specifically mean many things) you always trust it. * EDHOC EAD items (Mališa Vučinić, 5 mins) * MV: Clarifying about this topic raised at IETF 115. * MV: Some applications are using EAD items. One is in LAKE about third-party authorization for a device to join a network, based on BRSKI concepts. * MV: Other examples are remote attestation, and OCSP stapling done through EAD items. * MV: If we recharter, I'd propose a sentence mentioning work on new EAD items. * GS: On the stapling case, Youssef plans a draft before the cut-off. * SF: If we enter into working on EAD items, when would we be finished? * MV: We can be very specific and mention in the new charter only the three EAD items that we already have in mind today. * GS: We can say that these are items we believe are important and only work on them for now. * SF: We just can't be too open-ended. * Open discussion on rechartering (chairs, 10 mins) * MCR (on chat): I support these charter changes. * MV: Shall we move the discussion to IEF 116? * SF: Or we have the discussion on the list. * MV: Should we prepare a first version of the new charter? * SF: Who is interested in working out the new proposed charter? I'm assuming today's presenters are supportive? * MT (on chat): Assumption confirmed :-) I support and will help * RML (on chat): same here * SF: We can request the slot for IETF 116. To go ahead with the rechartering we need to see people invested in it. * AOB * SF: CB, you have a few comments in the chat. * CB: I collect them and can come back about them on the list. * GS: to abort the protocol, a peer has to get in the "Persist" state to not abort from then on. * CB: a TLS connection can be broken by breaking the TCP connection. It's way harder to break a DTLS connection. I'm interested in this part. * SF: Please go ahead on the mailing list. * SF: Who will be in Yokohama? * MT: I will be. * JPM: I will be. * GS: I plan to be there. [1]: https://datatracker.ietf.org/group/lake/about [2]: https://www.ietf.org/mailman/listinfo/Lake [3]: https://zulip.ietf.org/#narrow/stream/11-lake [4]: https://notes.ietf.org/notes-ietf-interim-2023-lake-01-lake [5]: https://meetings.conf.meetecho.com/interim/?short=9b7aa543-b18e-4fae-a6f4-271a9fb4f134