Lightweight Authenticated Key Exchange (LAKE) - IETF 119
Chairs
- Mališa Vučinić
- Stephen Farrell
Useful Links
Agenda
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.
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.
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.
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