Lightweight Authenticated Key Exchange (LAKE) - IETF 118
Time
- 6 November 2023 -- 16:30-17:30 UTC
- Mališa Vučinić
- Stephen Farrell
Notetakers
- Marco Tiloca
- Geovane Fedrecheski
Useful Links
Agenda
Initials
Minutes
(meeting starts at 17:30)
Administrivia (chairs, 5 mins)
- MV doing introductions
- MV: -lake-edhoc and -lake-traces have been approved for publication
and are in the RFC Editor's Queue.
- MV: Adopted -lake-authz as WG document; implementor feedback will
come in this meeting
- MV: We have three -00 submissions (one originally targeting the CoRE
WG)
- (no agenda bashing)
(GS presenting)
Presented slides:
https://datatracker.ietf.org/meeting/118/materials/slides-118-lake-ietf118-lake-status-of-edhoc-and-traces-00.pdf
- GS: since IETF 117, -lake-edhoc addressed IESG comments and some
more minor points; it then went back and forth between RFC Editor
and IESG due to now resolved IANA discussions.
- GS: -lake-traces also addressed IESG comments and went to RFC
Editor.
- GS (p4): summary of changes in the latest versions of -lake-edhoc:
certificates chains rather bags, English in error messages, text on
used transport, security considerations, text shuffling across
sections
- GS (p5): just for information, what happened in IANA that moved the
-lake-edhoc back from RFC Editor to IESG, due to another work in
COSE and related IANA registrations. The issue at hand was an
alleged semantics overlapping in the registration of COSE Header
Parameters from -lake-edhoc (kccs, kcwt) and from
-cose-cwt-claims-in-headers. The resolution was that no changes were
needed in -lake-edhoc.
- MJ: That was a good discussion with CB as second Designated Expert.
His feedback improved the COSE draft without affecting -lake-edhoc.
I'm fine with this outcome.
- SF: There was no objection, Paul also suggested to do as we did.
Thanks all for handling this well.
- GS (p6-7-8): -lake-traces was aligned with the latest -lake-edhoc;
test vectors had to be updated and were verified again by two
independent implentors; by having added also MV as author, all the
implementors involved in the traces are also authors. Besides that,
minor clarifications, editorial improvements, and added examples of
invalid messages that have to result in aborting the EDHOC session.
Also removed on trace related to a message not using deterministic
CBOR, hence admitting EDHOC peers that can live with that
(ultimately, not using deterministic CBOR is not a security issue).
draft-ietf-lake-authz implementer feedback (Geovane Fedrecheski, 10 mins)
(GF presenting)
Presented slides:
https://datatracker.ietf.org/meeting/118/materials/slides-118-lake-implementer-feedback-lightweight-authorization-using-edhoc-01.pdf
- GF (p2): recap of the -lake-authz architecture with U, V, and W.
- GF (p3): recap of the message exchange
- GF (p4) ongoing work on a Rust implementation (no_std, no heap,
inline CBOR encoding), with a related ongoing work on formal
verification
- GF (p5): current status: achieved preparation of EAD_1, EAD_2,
Voucher_Request, and Voucher_Response. This is validated against
the test vectors. V sends CRED_V by value in EDHOC message_2
- GF (p6): first experience with providing CRED_X by value in
ID_CRED_X. On the receiving peer, CRED_X might be already stored,
or instead not and learned on-the-fly. Having CRED_X transported by
value is consistent with the "zero-touch" network join. Good to say
this should be the case, and that it results in greater overhead
than transporting CRED_X by reference.
- GF (p7): the initiator validates the Voucher from EAD_2, by
recomputing the MAC of CRED_V (i.e., CRED_R) conveyed in EAD_2.
The positive outcome practically consists in validating CRED_V.
This equivalence can be stated explicitly in the interest of
clarity.
- GF (p8): editorial suggestion to improve the text for avoiding
ambiguity of interpretation for the word "length".
- GF (p9): Should we also have EAD_3 to process, as a side processing
step? On the processing of ID_CRED_I, this is practically using a
Trust On First Use (TOFU) model, since validating the credential is
sufficient for also accepting it and storing it. The Voucher is
however not bound to CRED_U. Is this a problem?
- GF (p10): More comments as food for thought; we plan to build a demo
and interop.
- GS: Thanks for this. The clarifications make sense.
- GS: Only EAD_1 and EAD_2 are used so far. EADs are possible to
define such that they can be used in any message. It makes sense to
consider using EAD_3.
- GS: On the binding with CRED_U, we have discussed it and we don't
have a solution yet. It'll be in the issue tracker and get back to
it.
- CA: On EAD_3, it should be fine to pass it around with the
application, which will know by the time it processes message_3.
This does not look completely like TOFU. It's also about checking a
matching of the Voucher with the used ephemeral key.
- SF: Do you use annotated code?
- GF: No, now we are writing more regular Rust.
- SF: Please send a mail to the mailing list summarizing the status.
- SF: For the authors, what's the plan for progressing the work?
- GS: It started long ago. We need to receive good questions as a sign
that we haven't thought about something. We need one iteration more.
- SF: That means 2-3 iterations more? Thanks.
(MT presenting)
Presentes slides:
https://datatracker.ietf.org/meeting/118/materials/slides-118-lake-draft-tiloca-lake-edhoc-implem-cons-00.pdf
- MT: many non-trivial things came up while implementing EDHOC
- MT: discussed a potential informational document in previous
meetings
- MT: -impl has 3 main topics: handling sessions or keys that are
invalid; different trust models and learning new creds on the fly;
side processing of EDHOC messages (validating creds and EAD
processing)
- MT: topic 1: easiest thing that can happen is session be invalid
- MT: 2: app keys become invalid (e.g. expiration)
- MT: 3: app keys or access right become invalid (similar to 2 but
trigger could be access token becoming invalid)
-
MT: topic 2: trust model for creds. peer has to decide what to do
when receiving a new credential. three trust models:
- only trust in pre-stored credentials. called Pre-Knowledge Only
(PKO)
- fine learning something learned on the fly, but need e.g. the
hash of the cred to validate it (LOFU)
- Trust On First Use (TOFU) always trust an unknown CRED_X
-
GS: The case faced in -lake-authz feels more like for LOFU than for
TOFU.
- MT: Why? The peer does not know anything of the credential.
- GS: But it knowns the credential of a trusted party that can be used
to validate the first credential.
- MT: With the current terminology, that would still be TOFU. We can
present it as LOFU, if we extend its definition to be about having
pre-stored not simply an identifier of the credential, but
alternatively the credential of a trusted party usable to validate
the credential in question.
- JPM: I dont see how 1 and 2 would be different kinds of trust levels
- MT: so you mean to merge 1 and 2?
- JPM: I dont know exactly what you want to say
- MT: It's all about what a peer should do when learning a
never-seen-before credential during an execution of EDHOC. The first
policy is strict: never learn anything on-the-fly, only use already
stored credentials, if any.
- JPM: They have different security properties.
-
SF: we can track this in further discussion on the mailing list. A
lot of this seems to be about terminology.
-
MT: side processing of messages: message_2 and message_3 is not
linear. a big part is not part of EDHOC processing, e.g. EAD items,
credential validation. the figure is not in the draft, there is also
another one that is offline, I will provide ascii art versions in
the draft.
- SF: Do you think is ready for an adoption call?
(4 people in the room have checked/read the draft)
- MT: I was planning some additions in the next version, but I don't
have further major topics/context to add to what is in v -00.
- SF: Then you can produce a next version also based on feedback and
we can consider an adoption call.
- MV: (chair hat off) We used the considerations in the draft during
the Hackathon coding sprint to refactor message processing. Very
useful.
- SF: It shouldn't be controversial.
(MT presenting)
Presented slides:
https://datatracker.ietf.org/meeting/118/materials/slides-118-lake-draft-tiloca-lake-app-profiles-00.pdf
- MT: EDHOC requires certain parameters that peers must agree. how to
facilitate and coordinate them? application profiles?
-
MT: contribution is:
- definition of integer ids for application profiles
- identification of app profiles by their ids
- caninocal description in CBOR
- definition of well-known EDHOC app. profiles
-
MT: new IANA registry
- MT: assuming the registry exists, thought of a few examples. one can
query /.well-known/core and get edhoc parameters, such as cipher
suite.
- MT: we wanted to have thing simple -- don't mix approaches A and B.
have one or the other. avoid explosion of number of supported EAD
items.
- MT: another example is an EDHOC_Information (draft exists:
ace-edhoc-oscore profile). this doc defines new parameters:
cred_types, eads, initiator, responder, app_prof
- MT: third topic, having a canonical representation. extend the
existing ace profile and have the items defined as a CBOR Sequence
of CBOR maps. some fields MUST and others MUST NOT be present.
- question: what should application profiles specify? e.g. different
transports, types of endpoint identifiers.
- MT: well-known application profile. I don't know for sure what it
means, but I know what it DOES NOT mean. expect input on what is
should say.
- MT: summary and next steps, asking for input in several items.
(CA presenting.)
Presented slides:
https://datatracker.ietf.org/meeting/118/materials/slides-118-lake-applying-generate-random-extensions-and-sustain-extensibility-grease-to-edhoc-extensibility-00.pdf
- CA: maybe EDHOC will grow and "become TLS" -- lets at least pick
what we want.
- CA: There are many extension points; if they get unused, problems
can arise. So take advantage of GREASE practices.
- CA: GREASE means vectors that one can use are dedicated EAD items
and their labels, as well as cipher suites that are not to be
supported and picked up as selected. Might be worth considering also
methods and credential identifiers.
- CA: add where message sizes are not that critical. could be added as
an EAD item.
- CA: next steps: check against RFC 9170, draft edm-protocol-greasing.
anyway should be an easy document. question: is LAKE the right place
to do this?
AOB
SF: We'll continue these discussions on the mailing list. We may set
interim meetings before IETF 119.
(meeting ends at 18:30)