Lightweight Authenticated Key Exchange (LAKE) - Interim

Wednesday, 7 February 2023 -- 17:00-18:00 UTC

Chairs:

• Mališa Vučinić
• Stephen Farrell

Useful Links:

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

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:

• 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.