Minutes IETF111: lake
minutes-111-lake-00

Meeting Minutes Lightweight Authenticated Key Exchange (lake) WG
Date and time 2021-07-29 19:00
Title Minutes IETF111: lake
State Active
Other versions markdown
Last updated 2021-07-30

minutes-111-lake-00

Lightweight Authenticated Key Exchange (LAKE) - IETF 111

Date: Thursday, July 29th, 2021 -- 19:00-20:00 UTC

Chairs

  • Mališa Vučinić
  • Stephen Farrell

Agenda

  1. Administrivia and Agenda Bash -- chairs, 5 mins
  2. Interop Overview -- Marco Tiloca, 10 mins
  3. EDHOC Status -- Göran Selander, 20 mins
  4. Overview of EDHOC Open Issues and Next Steps -- John Mattsson & Göran Selander, up to 20 mins
  5. Next Steps and Planning -- chairs, 5 mins
  6. AOB

Notetakers

  • Marco Tiloca
  • Robin Wilton

Minutes

(Meeting starts at 19:01 UTC)

Administrivia and Agenda Bash -- chairs, 5 mins

Interop Overview -- Marco Tiloca, 10 mins

EDHOC Status -- Göran Selander, 20 mins

  • Slides: https://datatracker.ietf.org/meeting/111/materials/slides-111-lake-edhoc-consolidated-03
  • Draft has progressed from -05 to -08 since IETF 110. Some more added to the Editor's copy; then GH issues.

  • Changes from -05 to -08 listed in Slide 5 of the deck:

    • Removed correlation from the actual EDHOC protocol; now up to the transport, defined for CoAP
    • Removed the 'bstr_identifier' encoding; now connection identifiers are CBOR int or CBOR bstr. Replaced with a mapping from EDHOC ID to OSCORE ID.
    • Related to the previous point, now defined COSE Header Parameter 'kid2' for transporting CRED_X for raw public keys (also CBOR int or CBOR bstr), a COSE Header Parameters for CWT or unprotected CWT claim set as format for raw public keys.
    • removed connection identifier from the actual EDHOC protocol for the sake of message correlation; "auxiliary data" renamed to "external authorization data".
    • Improved error messages and their subtypes; updates to computing TH_2/TH_3 and to the Exporter interface.
    • Details of compact representation of ephemeral public key added
    • New cipher suites based on Chacha20/Poly1305
    • Section 5 now contains a message processing outline
    • Use with OSCORE and Transfer over CoAP moved from Section 7 to Appendix
    • Message_4 now presented together with other messages.
    • More normative directions on sending error messages.

  • Further changes from -05 to -08 (Slide 6 of the deck):

    • Terminology
    • Clarifications
    • New appendices
    • IANA registrations
    • Updated references
    • Additional security considerations

  • Ben Kaduk: Connection IDs moved from the messages; are they included in the crypto binding?

  • Göran Selander: No, the identifiers are negotiated but they don't have a security function in EDHOC, they have to comply with the sec reqs of the later security protocol.
  • Ben Kaduk: So it's up to later verification by the application.
  • John Mattsson: It matters also how you use them to identify a connection. We did think about it, but concluded that they didn't need to be protected in this way.

  • Mališa Vučinić: Had this question before. There are still mandatory-to-include identifiers for negotiation, and those are cryptographically covered. The ones not covered are the ones possibly prepended to EDHOC messages if the transport requires for message binding. C_I and C_R parameters are still included in the protected part of the message (see slide 3 for highlighted fields)

  • Post -08 matters

    • How to handle RPK-by-value, and format of CRED_x

      • On advice from Carsten, now using Unprotected CMS Claims Set (UCCS) as possible format for raw public keys as identity keys - See https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/
      • Section 3.5 refactored: reviews are solicited, to confirm clsoure of issues #125, #115, #88

    • John Mattsson has written a short doc about security levels and design goals of EDHOC: https://github.com/lake-wg/edhoc/tree/master/Security%20Level

    • Comments solicited, especially from Karthik Bhargavan, who requested the input. Mališa to reach out to Karthik.
    • Mališa suggests that this may be suitable for publication, so it can be used and referred to by those working on formal verification of EDHOC.
    • Göran Selander: Preference to not have this text in a draft, but rather in another way. Comments/contributions are welcome, if possible.
    • Mališa Vučinić: Completely open, especially for people from the WG. We can form a design team and carry this on at the interim meetings.

  • Discussion on open issues

  • Göran Selander has classified them into minor/straightforward (green), independent from spec (blue), and pending LAKE WG decision (black) - see Slide 9 of the deck.

  • Resulting breakdown of open issues is as follows:

    • Green: 8, 64, 73, 81, 88, 99, 100, 115, 125, 133, 134
    • Blue: 47, 50, 78, 84
    • Black: 22, 103, 121

  • 121 (simplified MAC calculation)

    • Use a HMAC construction rather than AEAD encryption
    • Mališa seeks group's opinion on the change.
    • John Mattsson: Practically this doesn't make a difference, but improves message size, leaving a little more margin for flexibility. The motivation wasn't a security problem with the previous design.
    • Stephen Farrell: Change seems good to me.
    • Christian Amsüss: Has a mild preference for Candidate 1 in which the KDF is a sequence, rather than an array (meaning one less number to keep around).
    • Göran Selander: The related PR can be merged soon to be considered for implementations.

  • 103 (optimization of message size)

  • What's the appropriate trade-off between encoding complexity and message size
  • Target message sizes derived from NB-IoT, 6TiSCH and LoRaWAN benchmarks
  • Current messages comply with LAKE requirements except message_2, which exceeds by 1 byte - and this is fixable by concatenating G_Y and CIPHERTEXT2 into one CBOR bstr

  • Göran Selander: should we do it? No impact on NB-IoT or LoRAWAN, this came from 6TiSCH for a network with multiple hops where a fragmentation would happen.

    • Mališa Vučinić comments on 6TiSCH use-case: 6TiSCH numbers are use-case specific. Message_2 is currently 1 byte too large in case where the EDHOC initiator is the 6TiSCH node that's trying to join.
    • Göran Selander: If we don't have a particular new agreement, we fall back for the pre-agreed requirements.
    • Mališa Vučinić: At the interim meeting we agreed to park this question until just before the WGLC, at which point the message sizes will have been fixed.

  • 22 Mandatory To Implement cipher suite

  • kid2: input is solicited (Slide 13 describes the background and 3 solutions)

  • Please let the authors know if you have a view; they will report conclusions to COSE
    • Ben Kaduk: If this new header turns out to be similar to an existing COSE one, we should discuss with the COSE group
    • Göran Seladner: Sure, just want check with LAKE first.
    • Ben Kaduk: Makes sense.

Overview of EDHOC Open Issues and Next Steps -- John Mattsson & Göran Selander, up to 20 mins

(see above for the Open Issues, as a combined slot)

Next Steps and Planning -- chairs, 5 mins

  • Close Issue #121 (Simplify MAC)
  • Resolve the kid2 issue above
  • Submit Version -09 so it can form the next implementation version
    • Göran Selander: Aiming for August 9th
    • Marco Tiloca: Suggest to start already implementing some things from v -08, especially the EDHOC identifiers as int or bstr; probably a next interop is doable in october
  • Update test vector
    • Help welcome on issues #47 and #78 test-vector-related issues.
  • Target date for the next round of interop tests: "soon after the summer break"
  • Next interim meeting:
    • End of September/beginning of October?

AOB

(Meeting ends at 20:02 UTC)