Lightweight Authenticated Key Exchange (LAKE) - IETF 121

Time

• 4 November 2024 -- 17:30-19:00 UTC

Chairs

• Mališa Vučinić
• Stephen Farrell

Notetakers

• Geovane Fedrecheski
• Marco Tiloca
• Christian Amsüss

Useful Links

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

Agenda

Administrivia
-- chairs, 5 mins
draft-ietf-lake-authz
-- Geovane Fedrecheski (GF), 15 mins
draft-ietf-lake-edhoc-impl-cons
-- Marco Tiloca (MT), 10 mins
draft-song-lake-ra
-- Yuxuan Song (YS), 15 mins
draft-amsuess-core-edhoc-grease
-- Christian Amsüss (CA), 10 mins
draft-lopez-lake-edhoc-psk
-- Elsa López Pérez (ELP), 10 mins
draft-tiloca-lake-app-profiles
-- Marco Tiloca (MT), 10 mins
draft-serafin-lake-ta-hint
-- Göran Selander (GS), 10 mins
AOB

Minutes

Administrivia

• (MV doing introductions.)

draft-ietf-lake-authz

Presented slides (later version available but not shown)

• (GF presenting.)
• GF (p3): What's new.
• GF (p4): Recap. U and V run EDHOC.
• GF (p5): Now named "ELA"
• GF (p6): Flow considerations, leading to (p7)
• GF (p7): Two options to support the EDHOC reverse message flow.
  Described in a new appendix.
• GF (p8): "What happens if many gateways are in a device's radio
  range?"
• GF (p9): Two strategies are defined: i) U broadcasts EDHOC
  message_1; 2) V advertises support for ELA. The second method is
  more about advertising, and has in turn a number of variants.
• GF (p10): Strategies depend on what works on the radio.
• GF (no slide -- newer slide set): Next steps. All the example
  advertisement strategies apply to ELA used for onboarding, but main
  idea of ELA is authorization. Want to separate it, have core
  authorization part, and another part using it for onboarding. Also,
  will update to enable both flows.
• GF (p11-12): We implemented ELA and evaluated it. Platforms are
  nRF52833 and nRF5340.
• GF (p13-14): Also compared with EAP-EDHOC.
• GF (p15): Comparison results. Small size difference (10%) is that
  EAP sends more small messages. On duty cycled network, there is more
  waiting to send, resulting in double the time in EAP.
• GF (p16): Diagram for ELA on DotBots.
• GF (p17): Results for message size and memory occupancy. EDHOC
  message_2 is unavoidably quite large, since ID_CRED_R conveys
  CRED_R by value (the authentication credential of V), in line with
  the zero-touch goal.
• GF (p18): Results for energy consumption
• Kathleen Moriarty (on chat): Thank you for the statistics and
  implementation details, great to see!
• RML: Interesting. About EAP-EDHOC comparison, what is purpose of
  that? Why is that a reference?
• GF: Simply want to understand how similar protocols compare.
• RML: Thinking about EAP, was thinking .1X, or something that uses
  EAP; in some places you can not use anything but EAP. EAP is
  authentication but not authorization unless AAA server is in
  backend. But do understand that comment.
• YD: For more key support?
• GF: We can use the cipher suites defined in RFC 9528, based on
  elliptic curve.
• YD: Do you support X.509 certificates?
• GF: We can support it, but also support more efficient ones.
• YD: Will come back to attestation.
• RN: On 2nd test, why not compared to other alternatives? In first,
  comparison was interesting. Planned?
• GF: We measured what we had

draft-ietf-lake-edhoc-impl-cons

Presented slides

• (MT presenting.)
• MT (p2): Recap. EDHOC focused on the document and did not cover
  aspects, eg. material becoming invalid, or combinations, or trust
  models; in particular, when to evaluate EAD items and credential.
  Recently, also CoAP block-wise interactions.
• MT (p3): Alignment with the EDHOC and OSCORE profile of ACE. How do
  new security contexts get paired to existing tokens?
• MT (p4): Improved trust models (learning, no-learning). No-Learning
  rules out previously mentioned application cases. Rather than
  opening for 3rd option again (used to be 3, now 2), considering to
  allow more in NO-LEARNING, as controlled and context-specific
  exceptions.
• MT (p5): Example exceptions to no-learning: presence of EAD items,
  e.g. EAD item in lake-authz carrying the voucher. (Skip Section
  4.4.1; when reading, was found to be moot)
• MT (p6): Guidelines for EDHOC with CoAP and Block-wise. Made Section
  5 more general and fixed an error.
• MT (p7): GF provided input; in discussion, turned out this has
  become obsolete (prefer to not restate mandatory things from EDHOC).
• MT (p8): Next steps. Clarify exception to no-learning in case of
  lake-authz; remove moot section; add consistency checks of
  credentials in ID_CRED_X and EAD items; security considerations;
  would like appendices with example credential (especially
  certificates). Please provide implementation feedback and lessons
  learned, not only for EDHOC itself but also from -authz and -ra!

draft-song-lake-ra

Presented slides

• (YS presenting.)
• YS (p2): Restructured draft. New added sections to overview the
  alternative models, the entity involved, and the roles taken by the
  EDHOC peers also based on the used message flow.
• YS (p3): Two new EAD items: Trigger_BG for background-check and
  Trigger_PP for Passport
• YS (p4): New instantiation where device first triggers PP and result
  proposal comes on EAD_2
• YS (p5): Updated mutual authentication (IoT item in background beck
  model, network in passport model)
• YS (p6): Evidence/token example updated. Used to be shown in PSA,
  now CoSWID.
• YS (p7): Concrete example. Update is that between RP and V, proposal
  is carried with C_R so that verifier can generate nonce and
  associate it with connection identifier -- verifier can now process
  multiple in parallel.
• YS (p8): Evaluation of remote attestation using EDHOC, as to message
  size and memory footprint. All authentication credential are
  transported by reference, but EDHOC message_3 is unavoidably large
  due to the transport of the attestation item.
• YS (p9): Current consumption benchmark. Crypto operations are
  software. As expected, the toll is on preparing EAD_3, mostly due
  to cryptographic operations.
• YS (p10): Summary. We plan to define/implement also mutual
  attestation. Ready for WG adoption?
• GF: Clarifying: Here and in my reference, RAM is always static RAM,
  not runtime.
• Muhammad Sardar: Sending evidence or reference to evidence? p8. What
  is 'reference' here?
• YS: This is not related to evidence. Evidence is in green. EDHOC
  transports credential by reference here (unrelated to attestation).
• Muhammad Sardar: On p9, is it correct that most of the delay comes
  from signing .... is that for evidence?
• YS: Our evidence is an attestation token, and that token is signed.
  It's not an EDHOC signature.
• Wei Pan: On the trust assumptions between the devices and the
  verifier. Do you assume that there is only one verifier? Which one
  should be trusted by the device or network service? Does relying
  party tell the other which verifier it trusts? (And in the opposite
  way in background check model)
• YS: We have now only one verifier -- single point-to-point
  attestation. If attester indicates desired verifier for evidence
  evaluation … don't specify that in draft, b/c relying party consumes
  and thus has to choose.
• WP: But attester may not know which verifier is trusted by RP.
• YS: For passport model, that's why there is ?-proposal/request.
• WP: So that information is contained in EAD? It's empty.
• YS: Only for the trigger.
• YD: What made you select CoSWID?
• YS: We're following entity attestation token draft, there they
  specified you can use CoSWID. Also, more lightweight than PSA.
• YD: Will discuss that offline. How does verifier know about
  reference values and result format?
• SF: Who read it?
• (About 6 people have read the draft, +1 remote)

draft-amsuess-core-edhoc-grease

Presented slides

• (CA presenting.)
• CA (p2): Context about previous discussion in London. "be selective
  on what to add to the protocol"
• CA (p3): Listen to RFC 9170: use extension points also if not really
  needed yet, to prevent ossification. That's what this draft is
  about.
• CA (p4): The greasing vectors are well-known, sentinel EAD items and
  cipher suites. Not useful to rely also on EDHOC methods and COSE
  headers for that.
• CA (p5): Individual draft considered done. Up to the WG to decide if
  taking this.
• MV: how many people read the draft?
• (3 people. GS: "well written and complete")

draft-lopez-lake-edhoc-psk

Presented slides

• (EL presenting.)
• EL (p2): Will be brief – not many updates since last interim 2
  months ago (where we selected a variant)
• EL (p3): Message flow in the selected variant. ID is sent encrypted
  in message 3. Message 2 has no MAC compared to other EDHOC modes.
  EDHOC message_4 is now mandatory for the sake of mutual
  authentication.
• EL (p4): Key schedule unmodified.
• EL (p5): Measurements, comparing with PSK1 variant (discarded in the
  interim)
• EL (p6): Handhsake duration, energy consumption, memory usage. PSK2
  slightly faster, uses a bit more memory.
• EL (p7): Charts showing energy and duration.
• EL (p8): Asking for WG adoption; integration in the Lakers Rust
  implementation.
• MV: Who read the draft?
• (3 in room, 1 remote)

draft-tiloca-lake-app-profiles

Presented slides

• (MT presenting.)
• MT (p2): Why do we do that? Some things negotiable during EDHOC,
  some have to be known in advance, therefore the EDHOC application
  profiles. Like before, started in EDHOC, was split out for delayed
  work, and is now in agenda.
• MT (p3): Reorganization. Now identifying profiles by registered
  integers. Parameters are concepts from EDHOC that are detailed here
  (?), with CBOR representation.
• MT (p4): More details on the profile format. Venues for sending
  data: Web link, or EDHOC information object (CBOR map). To prevent
  explosion of registrations, admitting overrides in specific field
  (EAD items).
• MT (p5): About additional parameters for profiles.
• MT (p6): Updates on CBOR canonical representation of profile. Some
  parameters required, some make no sense.
• MT (p7): Suggested initial set of well-known profiles (expressed in
  CBOR objects and filed into registry); totally arbitrary, let's
  discuss. By no means de facto default
• MT (p8): Next steps. It's mostly about defining one more venue to
  exchange information on supported EDHOC application profiles and
  capabilities of EDHOC peer, that venue being the first two EDHOC
  messages with EAD items. So that's still to be done, but we got
  support and asked to accelerate at the Hackathon. Unless the WG
  really wants to see that in the draft first, then this can also be
  ready to consider for WG adoption.
• CA: EAD items are very important for choosing when to send
  credentials by value or reference. I don't care if that thing still
  to add is already in the draft or not.
• MV: Who read draft?
• (2 in room, 1 non-author on chat)

draft-serafin-lake-ta-hint

Presented slides:

• (MS still in meeting; GS jumping in as a co-author.)
• GS: Submitted -00. Basic use case is addressing things from lock
  control in MS's deployments. Strict requirements on time; much time
  can be wasted by unnecessary round-trips on credential mismatches.
• GS: Proposed adding hints to which trust anchors exists, and which
  credential types are supported (in EAD items, with CDDL).
• GS: Hackathon discussion showed that app-profiles support this. So
  we don't need to define something new, and once app-profiles are EAD
  item, can send it on.
• GS: Didn't support trust hints, but that's just another parameter
  for there.
• GS: This is both about credentials for EDHOC, but also other trust
  anchors (time sync, trust anchor for RA verification), can also fit
  in app-profile.
• GS: We think the need for this draft is obsoleted.
• CB: Putting something in a registry doesn't save you from need to
  specify it. Need to think about where documents are going to live.
  With specification-required registry, someone needs to find the
  document. IETF doc works.
• GS: So you say we should describe use case somewhere? What are we
  missing if we stop this draft and start working on app-profile?
• CB: If you put information into a registry, that registry has to
  contain complete info, or point to a spec.
• GS: Are you saying that we can describe things here, and reference
  app-profile as means of transporting that information?
• CB: Yes.

• GS: Will consider that.

• GS: Marek also wanted to talk about edhoc.me

adoption calls

• (Discussion on what to prioritize.)
• grease is short and simple.
• psk will have to be frozen for 6 months for formal analysis, and
  people working on it would like to see it adopted.
• Documents like -app-profiles are those that enable other things to
  move forward (CB and CA). Given the number of readers, the version
  number doesn't really play a role here.
• SF: Looks like a rough order is -grease, -app-profiles, -psk, -ra,
  for 2 weeks each. Their calls don't have to run strictly
  sequentially, but running in parallel risks to have few/nobody
  reading anything. We should still manage to close all the calls by
  the end of the year.
• JPM (on chat): LAKE only have 2 adopted drafts, so I think the group
  could adopt everything people think is ready. Don't need to
  prioritize.

AOB

• MV: We will schedule an interim meeting in January 2025.