Markdown Version | Session Recording

Session Date/Time: 26 May 2025 14:00

LAKE

Summary

The LAKE Working Group held an interim meeting to review progress on adopted drafts and discuss future work. Updates were presented for the draft-ietf-lake-edhoc-application-profiles, draft-ietf-lake-remote-attestation, draft-ietf-lake-psk-authentication, and draft-ietf-lake-third-party-authorization documents. Key discussions included refining error handling, addressing attestation freshness, resolving authentication vulnerabilities, and modularizing authorization flows. The working group reviewed and proposed updates to its milestones, and initiated a discussion on potential post-quantum cryptography (PQC) related work.

Key Discussion Points

draft-ietf-lake-edhoc-application-profiles (Marco Tiloca)

• Document Purpose: Helps EDHOC peers align on parameters and application profiles (identified by integer ID) for successful EDHOC sessions, using in-band (new EAD item or error message) or out-of-band mechanisms.
• Error Handling Updates:
  • EAD item in Message 3 or 4 (where not expected) should be safely and silently ignored.
  • Multiple EAD instances in Message 1 or 2 should abort the session for safety.
  • Malformed elements in a CBOR sequence within EAD or error messages should be silently ignored.
• EDOCF_INFO CDDL Definition: A bug was found in the EDOCF_INFO CDDL definition; a naked CBOR sequence is not allowed, it must be wrapped in CBOR bytestring. This ensures compliance and consistency with EAD value encoding.
• Parameter Namespace Simplification: The related ACE document defines a shared parameter namespace. This draft will inherit an improved, simplified namespace, trimming parameters not pertinent to EDHOC application profiles or misaligned with EDHOC concepts.
• Inconsistent Profile Advertisement Prevention:
  • To prevent inconsistent or contradicting information when advertising multiple EDHOC application profiles, parameters will be split into two subsets.
  • This enables producers to avoid creating inconsistent profiles and consumers to perform minimal sanity checks.
• EAD Item Semantics: The EAD item should be used in a critical way (negative sign label) because it influences the session continuation. This ensures peers are on the same page regarding supported capabilities.
• Trust Anchors in Profile Object:
  • The SAUR object (canonical profile representation) has an optional trust_anchors parameter.
  • It was proposed to remove trust_anchors from this object instance because trust anchors have expiration times or can be revoked, which would prematurely invalidate the entire profile and its integer ID.
  • This does not prevent an EDHOC message sender from indicating trust anchors via the EAD value through other means.
• DNS Advertisement: Proposed to define an SRV parameter key for DNS to advertise EDHOC support and features/profiles, using the same semantics as EAD or error messages. An empty sequence can indicate basic EDHOC support.
• New EAD Item for Message 1: A simple, boolean-like EAD item only for Message 1 was proposed, allowing the initiator to request responder information or indicate it knows everything.
• Next Steps: Update the document for the Madrid meeting, incorporating these points, and seek further reviews.

draft-ietf-lake-remote-attestation (Yang Song)

• Document Hierarchy: Flattened the document hierarchy to make EAD items (attestation proposal, request) directly accessible from the table of contents.
• CR Removal & Nonce Use:
  • Removed CR (Commitment Reference) from figures, as it was deemed unnecessary and risky for the verifier to derive session state from ad hoc session parameters.
  • The verifier now uses a nonce (n) to identify session state. The verifier generates a nonce upon receiving an attestation proposal, stores it locally, and verifies received evidence against it.
• Nonce Support in Passport Model:
  • Added n as an optional parameter to the result_request in the passport model.
  • This allows low-power or time-unsynchronized relying parties to send a nonce, enabling the verifier to include it in the attestation result for freshness verification.
• Clarifications and Editorials:
  • Need to explain the rationale for identical EAD labels in background check and passport models.
  • Will clarify all eight possible instantiations of the remote attestation protocol in section 6.
• Open Issues (Not Yet Solved):
  • Add a dedicated section for verifier operations (background check and passport models).
  • Discuss combining LAKE and LAKE-OAUTH (from last hackathon).
  • Correct the section for error handling.
• Rats WG Review: No feedback received from the Rats WG yet.
• Next Steps: Solve remaining open issues and update the draft for the next IETF.

draft-ietf-lake-psk-authentication (Elsa Dufrasne)

• Test Vectors: Added test vectors, following the structure of RFC 9529 traces of EDHOC.
• Acknowledgements: Added acknowledgements to the document.
• Reflection and Selfie Attacks: A solution was implemented to prevent these attacks for preset key authentication without identities: adding an identity to the field of the Quick PSK, which is included in transcript hashes but not sent in messages.
• Document Structure: The document remains a delta-document (containing differences) with respect to the core EDHOC RFC 9528. This approach is preferred to avoid repetition.
• Next Steps:
  • Call for formal analysis of the document once the draft is frozen.
  • Plan for interop testing, especially given interest from industry implementations.
• Yoran provided information about another industry implementation, which could facilitate interop testing.
• Rafa indicated Yumo has a recent implementation of EDHOC PSK.

draft-ietf-lake-third-party-authorization (Giovanni Campagna)

• Document Consolidation: The draft is now a more general lightweight authorization mechanism, applicable to zero-touch enrollment, supporting two modes: device as initiator and device as responder (L-reverse flow).
• Current Status: Protocol supports error handling, includes optimizations (in appendix), implementation is validated.
• Closed Issues:
  • Reverse flow merged (version 4).
  • Error message fields: kept as-is.
• Ongoing Discussion (Issue 26 - Christian Amsüss):
  • If it makes sense to support not having a voucher.
  • If it makes sense to support having more vouchers.
  • Discussion around identity protection services and modularizing the three-party scenario (W has private key) from specific applications like ZOE.
  • Michael and Christian discussed the need to potentially separate "initiator confidentiality on identity" into a new document or modify ELA to be more generally applicable by not breaking the protocol if a voucher response is absent.
• EA Review: Simple fixes needed for section 7 (considerations) and to define EAD labels.
• Implementation: ELA is implemented in Rust within the lakers open-source implementation, running on nrf52840/nrf5340 (device), and Rust/Python for gateway and enrollment server. Michael indicated interest in implementing the W (enrollment server) side.
• Next Steps: Solve remaining issues for IETF 123 in Madrid, aiming for a final version.

Decisions and Action Items

• WG Session for IETF 123: The Chairs will request a 1 hour 30 minute session for the LAKE WG at IETF 123 in Madrid. (No objections heard.)
• Milestones Update:
  • Decision: Remove the "verification of ad hoc authentication credentials submitted to ISG as proposed standard" milestone from the data tracker, as no draft was ever adopted for this. (No objections heard.)
  • Action Item (Chairs): Remove the aforementioned milestone.
  • Action Item (Yusuan): Target end of 2025 for working group last call for draft-ietf-lake-remote-attestation, aiming for ISG submission by March 2026.
  • Action Item (Elsa, Yoran, Rafa): Target Summer 2026 for ISG submission for draft-ietf-lake-psk-authentication, allowing for formal analysis and interop testing.
  • Action Item (Giovanni): Target end of 2025 for ISG submission for draft-ietf-lake-third-party-authorization.
  • Action Item (Marco): Target Summer 2026 for ISG submission for draft-ietf-lake-edhoc-implementation-considerations, allowing for input from other draft implementations.
• draft-ietf-lake-psk-authentication Interop Testing:
  • Action Item (Yoran, Elsa): Coordinate with the industry implementation mentioned by Yoran.
  • Action Item (Elsa, Yoran, Rafa): Plan for an interop testing event for EDHOC PSK at the Madrid hackathon (IETF 123). Chairs will publicize this on mailing lists.
• draft-ietf-lake-third-party-authorization Issue 26:
  • Action Item (Giovanni, Michael, Christian, and co-authors): Convene a design team meeting (offline from this interim) to discuss the complexities of Issue 26 (voucher presence/absence, identity protection, modularization of three-party scenarios). Report conclusions to the mailing list.
• PQC Discussion:
  • Decision: Plan for a substantial discussion (e.g., 15 minutes) during the IETF 123 Madrid meeting on post-quantum cryptography related to EDHOC, including draft-matsunaga-lake-pquake and the general working group position on PQC threats.

Next Steps

• Authors to address open issues and prepare new versions of their drafts for IETF 123 in Madrid.
• The chairs will request a 1.5-hour session for LAKE at IETF 123.
• The working group will proceed with updated milestone targets.
• Implementers of adopted drafts are encouraged to contribute input to the draft-ietf-lake-edhoc-implementation-considerations document.
• Formal analysis for draft-ietf-lake-psk-authentication will be initiated once the draft is stable.
• Coordination and planning for interop testing events (EDHOC PSK) at the Madrid hackathon.
• A dedicated discussion on Post-Quantum Cryptography and its relevance to LAKE will be held at IETF 123. The chairs emphasized focusing on current milestones while keeping an open mind for future PQC work.