# Lightweight Authenticated Key Exchange (LAKE) - IETF 118   {#lightweight-authenticated-key-exchange-lake---ietf-118}

## Time   {#time}

*   6 November 2023 -- 16:30-17:30 UTC

## [Chairs](mailto:lake-chairs@ietf.org)   {#chairs}

*   Mališa Vučinić
*   Stephen Farrell

## Notetakers   {#notetakers}

*   Marco Tiloca
*   Geovane Fedrecheski

## Useful Links   {#useful-links}

*   [Charter][1]
*   [Mailing list][2]
*   [Instant Messaging][3]
*   [Minutes][4]
*   [Remote participation][5]

## Agenda   {#agenda}

*   Administrivia  
    -- chairs, 5 mins
*   draft-ietf-lake-edhoc & draft-ietf-lake-traces  
    -- John Preuß Mattsson & Göran Selander, 15 mins
*   draft-ietf-lake-authz implementer feedback  
    -- Geovane Fedrecheski, 10 mins
*   draft-tiloca-lake-edhoc-implem-cons  
    -- Marco Tiloca, 10 mins
*   draft-tiloca-lake-app-profiles  
    -- Marco Tiloca, 15 mins
*   draft-amsuess-core-edhoc-grease  
    -- Christian Amsüss, 5 mins
*   AOB

## Initials   {#initials}

## Minutes   {#minutes}

(meeting starts at 17:30)

### Administrivia (chairs, 5 mins)   {#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)

### draft-ietf-lake-edhoc & draft-ietf-lake-traces (John Preuß Mattsson & Göran Selander, 15 mins)   {#draft-ietf-lake-edhoc--draft-ietf-lake-traces-john-preuß-mattsson--göran-selander-15-mins}

(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)   {#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.

### draft-tiloca-lake-edhoc-implem-cons (Marco Tiloca, 10 mins)   {#draft-tiloca-lake-edhoc-implem-cons-marco-tiloca-10-mins}

(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:
    1.  only trust in pre-stored credentials. called Pre-Knowledge Only
        (PKO)
    2.  fine learning something learned on the fly, but need e.g. the
        hash of the cred to validate it (LOFU)
    3.  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.

### draft-tiloca-lake-app-profiles (Marco Tiloca, 15 mins)   {#draft-tiloca-lake-app-profiles-marco-tiloca-15-mins}

(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.

### draft-amsuess-core-edhoc-grease (Christian Amsüss, 5 mins)   {#draft-amsuess-core-edhoc-grease-christian-amsüss-5-mins}

(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   {#aob}

SF: We'll continue these discussions on the mailing list. We may set
interim meetings before IETF 119.

(meeting ends at 18:30)

* * *



[1]: https://datatracker.ietf.org/group/lake/about
[2]: https://www.ietf.org/mailman/listinfo/Lake
[3]: https://zulip.ietf.org/#narrow/stream/lake
[4]: https://notes.ietf.org/notes-ietf-118-lake
[5]: https://meetings.conf.meetecho.com/ietf118/?session=31723
*[MT]: Marco Tiloca


*[MV]: Mališa Vučinić


*[GS]: Göran Selander


*[GF]: Geovane Fedrecheski


*[CA]: Christian Amsüss


*[SF]: Stephen Farrell


*[JPM]: John Preuß Mattsson


*[MJ]: Michael Jones