Lightweight Authenticated Key Exchange (LAKE) - IETF 119

Chairs

• Mališa Vučinić
• Stephen Farrell

Useful Links

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

Agenda

• Administrivia
  -- chairs, 5 mins
• draft-ietf-lake-authz
  -- Geovane Fedrecheski, 10 mins
• draft-tiloca-lake-app-profiles
  -- Marco Tiloca, 10 mins
• draft-song-lake-ra
  -- Yuxuan Song, 10 mins
• Recap on EDHOC with PSK-based Authentication
  -- John Preuß Mattsson, 10 mins
• AOB

Notetakers

• Christian Amsüss
• Marco Tiloca

Initials

• SF: Stephen Farrell
• MV: Mališa Vučinić
• JPM: John Preuß Mattsson
• MT: Marco Tiloca
• YS: Yuxuan Song
• GF: Geovane Fedrecheski
• JG: Johann Großschädl
• MCR: Michael Richardson
• MG: Matthew Gillmore
• MS: Muhammad Sardar
• CA: Christian Amsüss

Minutes

(meeting starts at 15:30 local time)

Administrivia -- chairs, 5 mins

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-lake-chairs-slides-01

• SF: Introduction, announcing RFC 9528 and 9529
• SF: draft-tiloca-lake-edhoc-implem-cons was under consideration for
  adoption. No feedback received. Please send a mail to the list if
  you support, or of course react now if you oppose.
• SF (p6): Presented chair slides are outdated, see above
• SF: Agenda: If time permits, last-minute presentation from Johann
  Großschädel (IoTDisco)
• GF: Might need extra 5' discussion after my slides.
• MT: Same.
• SF: OK.
• GF: Demo in AOB?
• SF: If time permits.

draft-ietf-lake-authz -- Geovane Fedrecheski, 10 mins

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-lake-lightweight-authorization-using-edhoc-00

(GF presenting)

• GF (p3): using terms "authz", "zero touch" for protocol. Introducing
  actors.
• GF (P4): updates on the implementation. Version -00 is implemented,
  and there is a demo in HW.
• GF (p6): Changes – voucher may carry data.
• GF (p7): Use of OPAQUE_INFO. Between U and W (on other available
  gateways, or for actionable error handling).
• GF (p8): New error code that may carry actionable information about
  the rejection, with concrete use in authz (?)

• GF (p9): The error code returned to U can assist in scenarios where
  multiple V are available and V does not know which should be
  selected. Hints are optional.

• GS: Question about use case – why does gateway matter?

• GF: Building may have access points form multiple stakeholders.
• GS: Makes sense.
• GS: On slide 8, we didn't define such an error in EDHOC because it's
  extensible and codes can be added. We're using this for something
  specific because it's actionable. What makes it actionable is the
  relation between U and W so you can pass trustworthy info around.
• GS: On slide 9, what's the privacy aspects about U obtaining
  information about the gateways? How do we handle it?
• SF: If a device collects nearby identifiers, that is indeed privacy
  sensitive.
• MCR: U is listening to radio; agree that it is sensitive if W makes
  it public. But U can try them and then each of them will contact W,
  anyone there could collect that. As long as on-path entities can not
  view it, I don't think it's interesting. So the information is
  sensitive, but who are we disclosing it to?
• SF: For now, it's sufficient to know that there is a question that
  needs an answer.
• MCR: Maybe the information can also be reduced to a subset such that
  it doesn't matter anymore.

• MCR: The goal here is to be efficient, to trimming shouldn't be a
  problem. We might even find this not useful altogether.

• CA (chat only): As we're agreeing it is a privacy question and don't
  need to go into all details, I'll leave this remark to the chat: It
  probably doesn't matter too much b/c U is effectively under control
  of W and W should not publish. It is not true that all V would
  contact W anyway, there could just as well be some Vn around that W
  would get no other knowledge of (U may try and Vn would reject them
  b/c it's not partnered with W).

• GF (p11): continuing to open issues

• GF (p12): Yet to define parts in V-W
• GF (p13): Inversion? (Slide is just quick sketch). Don't think there
  is anything fundamentally preventing it. Is it needed? Is there a
  use case that anyone has in mind?

• GF (p14): Exploring ideas for enhanced interoperability. How much do
  we want to be open, how much to be specific? (Not going into
  details)

• MG (chat): +1 on being more granular vs. opaque times

• GF(p15): Further issues to be discussed on tracker

• GF(p16): Summarizing.

• GS (on chat): Slide 12: Could we just copy paste REJECT_INFO (new
  field in VRES) into OPAQUE_INFO?

• GS (on chat): Slide 13: Can we run mutual authorization using EAD_2
  and EAD_3 in one EDHOC run?
• SF: If no time, bring it to the list.

draft-tiloca-lake-app-profiles -- Marco Tiloca, 10 mins

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-lake-draft-tiloca-lake-app-profiles-01

(MT presenting)

• MT(p2): recap.
• MT(p3): scope.
• MT(p4): pieces of information.
• MT(p5): CBOR map to canonically describe an EDHOC application
  profile.
• MT(p6): Support from Brian Sipos on the list, see
  https://mailarchive.ietf.org/arch/msg/lake/GQmnLrn1R29o5u3Xy8CVEQT7KYo/
• MT(p6): Change log for v -01. Some parameters that were moved to
  draft-ietf-ace-edhoc-oscore-profile. Thinking also of missing ones.
• MT(p7): open points: just-identifier-vs-all-parameters strictly
  separated or both allowed? Whatever the outcome, needs to match ACE
  document.
• GS: You said EAD items could be allowed even in the hybrid version,
  so some profiles can include them, and they can be added.
• CA: Do EAD items need to be negotiated in the first place? They
  already have their critical/optional.
• GS: CA has a point, but you can use both -- negotiate them, or allow
  them to be specified.
• GF: An implementation may want to make it specific to state it
  supports some item.
• ?: ... trial and error

• CS (chat): No need to go into more detail here, but it is
  specifically not trial and error, it's
  trial-and-graceful-degradation.

• MT(p8): More parameters were missing for a profile description: max
  message size, peer identifier type, used transport. Possibly, it
  requires new registries (please tell if such a registry exists,
  especially for the peer identifier type!), the values can likely be
  integers. Transport details: let's take those step by step, but
  expected different parameters for Initiator/Responder/Both, and the
  value can point to a transport together with transport-specific
  information.

• MT(p9): (meaning of) well-known profiles and early examples. Shown a
  first set of tentative well-known profiles, with different
  amount/extent of supported EDHOC features. Please provide feedback,
  this is starting point we'll consider for the next version.

• MCR (chat): I assume profiles are encoded into a small integer, but
  I'm unclear if it's within message_1, or outside in the CoAP part?

• GS (chat): Michael: My understanding is that this is for negotiation
  / information before EDHOC

• MT (chat): Like Göran says.

• SF: So Marco, I guess your plan is to revise this and eventually go
  for a WG adoption call?

• MT: Yes.

draft-song-lake-ra -- Yuxuan Song, 10 mins

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-lake-remote-attestation-over-edhoc-00

(YS presenting.)

• YS(p2): actors.
• YS(p3): See RATS; models; focusing on background check model (RP
  talks to verifier).
• YS(p4): -00, explaining how to do using EDHOC. Assumption is that RP
  has knowledge of attester (??).
• YS(p5): Roles matching attester and relying party. Verifier is out
  of scope. Which criticality do the EADs have?
• YS(p6..8): Details of EADs.
• YS(p8): Only carry relevant claims. Verifier produces result.
• YS(p9): Wrap-up, now focusing on the background-check model.

• YS(p10): next steps. Size example for EAD_3 is 453 byte (2 software
  measurements). Will start a preliminary implementation. Comments are
  welcome.

• MS: On p5, mentioning role mapping. Clarify: Verifier role is out of
  scope, right? (YS: Yes). But then, how does attestation happen?
  Verifier is most important part, how complete the protocol? If there
  is no appraisal policy, no verifier role... one alternative could be
  verifier colocated with relying party. Would make more sense than
  saying out of scope. Otherwise, doesn't make sense to me how the
  protocol can complete.

• YS: Current proposal is about how to transfer the messages for
  EDHOC, and these are the EDHOC roles and the fields to transport
  data in. EDHOC is between attester and RP. Impl is still incomplete
  -- yes, RP needs to know how to talk to the verifier. Right now
  focusing on data transport. May think about that in the future.
• MS: Not related to the implementation, more to the specification,
  which seems incomplete about this. Who is going to verify the
  evidence and provide the Responder with the result about that?
• GS (on chat): I suppose "out of scope" just means the focus of the
  specification, not that there is no Verifier.
• CA (on chat): AIU, it will still have a verifier, it's just not
  EDHOC that's being talked to them. That may also be an unconstrained
  link.

• YS: Current focus is on extending EDHOC. But yes, there must be a
  verifier, just not started to specify that.

• JPM: Seems very promising. Need to figure out precise mappings, and
  whether the verifier is also in EDHOC or out of band.

• SF (chat): I also wonder about the privacy properties here but those
  can be considered later too.

• GS: All been said. Verifier needs to be in the model, and relevant
  what kind of evidence is being made use of.

• GS: Another question -- mentioned order of preference (p6). Why does
  that matter, isn't it the preferences of the RP that is relevant?
• YS: By default, RP will just select first.

• GS: Maybe what matters more is what is supported by the device,
  because RP has preferences for what it wants to verify. Don't see
  how device can have a preference. But great it's supported. Take it
  offline.

• MS: On p3, focusing on background check model. Motivation for that?

• YS: As you mentioned, there is a gateway. That will be the RP.
  Manufacturer will be verifier. Device connects to gateway, which is
  connected to the manufacturer. Gateway communicates with both.

Recap on EDHOC with PSK-based Authentication -- John Preuß Mattsson, 10 mins

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-lake-edhoc-with-psk-based-authentication-00

(JPM presenting.)

• JPM(p1): About PSK, or about rekeying. Was discussed long in past,
  but no draft yet.
• JPM(p2): EMU adopting EAP-EDHOC, commercial interest in deploying
  that, requested lightweight resumption. Plan from older LAKE
  discussion was new exporter label and new method. Typical issues
  esp. with external long-term identifiers, forward security.

• GS (on chat): The application of EAP-EDHOC John mentioned is to key
  MACsec for automotive deployment.

• JPM(p3): Plan to start draft. Differentiate btwn "initial handshake"
  (in TLS terms) and "resumption". Use ephemeral DH for initial
  handshake. What are requirements for resumption? Doing it w/o DH has
  worse properties, but how often do you require DH? Privacy easy --
  new for each resumption. If it doesn't work, retry but eventually do
  new handshake. Biggest problem: privacy in initial handshake using
  external PSK and PSK identifier. Whom to put requiremenst on? Maybe
  trial decryption.

• CA: on privacy, for initial handshake, still talking about R being
  protected against passive attackers, how is PSK ID worse than KID in
  terms of privacy?

• JPM: In this case it would identify the initiator as well.
• CA: Can't PSK ID be in msg_2 as it is in EDHOC so far?
• JPM: Yes, but then you have to change roles. You're supposed to have
  the Initiator providing/indicating the PSK.

• JPM: In general, just protecting PSK ID with DH in later messages
  gets worse privacy for initiator. Need to think about what we want
  to have.

• GS: On privacy topic. Is proposal that when using resumption, we
  derive new pseudonyms for each resumption?

• JPM: Yes.
• SF: So like TLS1.3 session ticket, single use.

• JPM: Yes.

• SF: You're on this. Looking for collaborators? Happy to go ahead?

• JPM: If someone wants to help. We'll have the new draft at some
  point.

IoTDisco: Strong yet Lightweight End-to-End Security for the Internet of Constrained Things -- Johann Großschädl

Slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-lake-iotdisco-00

(JG presenting.)

• JG(p1): working on lightweight crypto for IoT. Announced this on
  list: Prototype of Disco protocol. Prototyped on 16bit UC with 8KiB
  RAM, 100KiB flash.
• JG(p2): What is Disco -- framework for custom protocols. Goal:
  Simplicity. Requires only 2 low-level crypto primitives.
• JG(p3): LoC are excluding crypto.
• JG(p4): No branches after initial simple negotiation.
• JG(p5): Noise does authenticated key exchange. Early payload
  supported.
• JG(p6): example of noise.
• JG(p7): during- and after-handshake properties of strobe for
  encryption, transcripts, …, and also after handshake.
• JG(p8): implemented on very constrained (class 1) device
• JG(p9): setup of experimental evaluation. No message sent, just
  protocol.
• JG(p10-11): experimental results (execution time, code size, RAM
  footprint)
• JG(p12): comparison with alternatives including uEDHOC and HIP DEX.
  Can't tell about the efficiency of the low-level crypto.

• JG(p13): working on the full implementation, with interest on a
  post-quantum version based on PQNoise (Noise using KEM instead of
  DH). More resources linked in the slide.

• CA (chat in order to leave time for GF): How does this compare to
  EDHOC if limited to SS method and just one (comparable!) cipher
  suite and one choce of say CWT style? (EDHOC impls can and do
  hardcode one single suite and one role; didn't see many branches eg.
  in LAKERS if no extensions are implemented and error handling is
  OK). Sounds very similar, eg. early-payload=EAD, LoC similar range
  if choosing no exts.

• JPM: Would be interesting to use ASCON once it is standardized by
  NIST.

• GF: Strobe initially uses keccak, which is not friendly for
  constrained devices due to its large state. Also not friendly for
  small messages. Xoodoo because faster than ASCON. Understand that
  there is interest due to standardization. ASCON gets 80bits PQ, so
  will need bigger permutation anyway.

• SF: Please take it to the list.

GF: Demo: Zero-touch onboarding of DotBot

(Recorded demo available at https://www.youtube.com/watch?v=0kAtbMMcVRg)

• GF: Demo of what I presented before. Gateway controls DotBot robots.
• GF: Bots are U (round bots). Communication over BLE (physical
  layer). W is Dotbot manager, which has ACL allowing bot 1 to join
  domain, and has log.
• GF: Broadcast only makes one device move.
• GF: Implementation is lakers, DotBot manager also public.

AOB