Session Date/Time: 21 Mar 2024 05:30

lake

Summary

The LAKE working group meeting at IETF 119 covered several topics, including updates on Lightweight Authorization using Ad-hoc (Giovanni), Application Profiles for Ad-hoc (Marco), Remote Attestation of Ad-hoc (Sushan), and PSK-based authentication and rekeying/resumption for Ad-hoc (John). There was also an "if time permits" presentation on a prototype implementation of the disco protocol (Johan). The working group adoption draft implementation considerations, needed a mail to the list saying yes or against.

Key Discussion Points

Lightweight Authorization using Ad-hoc (Giovanni):
- The voucher can now carry data encrypted between U (device) and W (enrollment server) using an opaque info field.
- A new Ad-hoc error code, "access denied," was defined, along with a reject info field for actionable error information.
- Enrollment hints (UHINT, VHINT) were discussed to speed up enrollment with multiple gateways.
- Privacy aspects of collecting information about gateways (V1, V2, V3) were raised, requiring further consideration. Need to answer the question: What exactly are we communicating?
- Open issues include explaining errors in the V-W interaction (VRS protocol), inverting Ad-hoc roles, and making the opaque info less opaque.
Application Profiles for Ad-hoc (Marco):
- Discussion of hybrid exception where a profile identifier can be used, but with additional EAD items. Question of trial and error or needing to specify in the profile.
- Consideration of including maximum message size in profiles, and having that be separate for different edit messages.
- Consideration of a registry for data and port identifier types, unless one already exists that can be exported for this purpose.
- Discussion of transport protocols for Ad-hoc. May need a registry for identifiers.
- Presentation of win-on profiles, providing minimal examples.
Remote Attestation of Ad-hoc (Sushan):
- Remote attestation procedure using EAD fields in Ad-hoc was defined.
- Clarification was sought for the criticality of EADs, specifically regarding the attestation proposal (EAD1) vs. attestation request (EAD2) and evidence (EAD3).
- Mohammad raised concerns about the out-of-scope nature of the verifier and how the attestation process would complete without it. The response was the current intent is to define how to transfer the messages in ad hoc to complete a remote attestation.
- Discussion of an order of preference for attestation methods and when the order mattered.
- Motivation for focusing on the background check model.
Ad-hoc with PSK Authentication (John):
- Discussion of adding a new method with PSK authentication and a new border label to derive a resumption PSK.
- Privacy concerns with PSK authentication, including using external long-term PSK identifiers which potentially enable device tracking.
- Requiring ephemeral Diffie-Hellman during the initial handshake.
- Discussion of deriving a new resumption PSK for each resumption for added privacy.
- Christam questioned how KID in the first message differed from key ID for asymmetric cases
disco protocol (Johan):
- Showcased the disco protocol and the implementation on a constrained device.
- The disco implementation was shown to have a fairly small footprint and good performance characteristics.
- Suggestion of looking at ASCOM and it's quantum security levels.

Decisions and Action Items

ACTION: Participants to send a mail to the list saying yes or against working group adoption draft implementation considerations.
ACTION: Consider the privacy implications of collecting gateway identifiers in the Lightweight Authorization using Ad-hoc draft and define more precisely what information is being communicated.
ACTION: Revise application profiles draft and proceed to working group adoption call.
ACTION: Continue developing remote attestation draft with consideration of the verifier role and its specification.
ACTION: Start drafting a new method with PSK authentication and a new border label to derive a resumption PSK.

Next Steps

Continue discussion on the mailing list for open issues.
Incorporate feedback into draft revisions.
Address action items identified during the meeting.