Lightweight Authenticated Key Exchange (LAKE) - IETF 111
Date: Thursday, July 29th, 2021 -- 19:00-20:00 UTC
- Mališa Vučinić
- Stephen Farrell
- Administrivia and Agenda Bash -- chairs, 5 mins
- Interop Overview -- Marco Tiloca, 10 mins
- EDHOC Status -- Göran Selander, 20 mins
- Overview of EDHOC Open Issues and Next Steps -- John Mattsson & Göran Selander, up to 20 mins
- Next Steps and Planning -- chairs, 5 mins
- Marco Tiloca
- Robin Wilton
(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):
- 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?
- Rikard Höglund: For awareness: "Key update for OSCORE" draft in CORE
(Meeting ends at 20:02 UTC)