Joint LAKE / ACE session - IETF 116

Time

• LAKE: Thursday, 30 March 2023 -- 00:30-01:30 UTC
• ACE: Thursday, 30 March 2023 -- 01:30-02:30 UTC

Useful Links

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

LAKE Notetakers

• Marco Tiloca
• Christan Amsüss

LAKE Agenda

• Administrivia
  -- chairs, 5 mins
• EDHOC & Traces, updates & open issues
  -- John Preuß Mattsson & Göran Selander, 15 mins
• EDHOC rekeying
  -- John Preuß Mattsson , 15 mins
• Simplifying deployment of draft-selander-lake-authz
  -- Göran Selander, 10 mins
• New LAKE charter open discussion
  -- chairs, 15 mins
• AOB

LAKE Minutes

• Administrivia (chairs, 5 mins)

  • SF and MV doing introduction. First hour for LAKE, second one
    for ACE.
  • MV: RealWorldCrypto happened in Tokyo; Marc Ilunga presented his
    work on security analysis of EDHOC, praised the working group
    for welcoming the analysis.
  • SF: I'm co-chairing a new group on formal analysis of protocols.
    See https://datatracker.ietf.org/rg/ufmrg/
  • MV: Any agenda bashing?
  • GS: We can skip the discussion on -lake-authz to give more time
    for discussing rekeying and rechartering.
  • SF: Sounds good.
  • GS: Can John talk about rekeying a bit later?
  • MV: So, first EDHOC, then rechartering, then rekeying?
  • GS: Yes.
  • MV: Ok.

• EDHOC & Traces, updates & open issues (Göran Selander, 15 mins)

  • Presented slides:
    https://datatracker.ietf.org/meeting/116/materials/slides-116-lake-edhoc-19-and-traces-05-00
  • GS: Two versions of -lake-edhoc since IETF 115. Addressing WGLC
    comments, and directorate and Shepherd reviews. -lake-traces is
    also stable.
  • GS (p4): on -lake-edhoc-18: revised EAD syntax, now used also
    for padding; then editorial improvements.
  • GS (p5-6): on -lake-edhoc-19: some more normative text on the
    use of EDHOC for OSCORE, clarification on message correlation,
    new appendix with an example of state machine
  • GS (p9): Request for new error code (see issue #400 on Github
    and proposed resolution in PR #401). The error follows an EDHOC
    message indicating an authentication credential by reference,
    and suggests to try again with a credential transported by
    value. This is consistent with registering only error codes such
    that a reaction leading to a follow-up, successful completion of
    the protocol.
  • SF: Would be good to see discussion on this.
  • GS: Please comment on the list or Github; if no objection, we
    plan to merge.
  • GS (p10): One more error code proposed by Marco (see issue #402
    on Github), on signaling which EAD item processing failed. This
    processing is out of the scope of EDHOC in itself, but it's
    useful to signal. Should we do this or let EAD applications
    register errors like any other applications?
  • CA: Based on the previously mentioned criteria, this is not
    actionable and should not be in this specification. It's up to
    the EAD applications, consistent with the intended criticality
    of the EAD items.
  • GS: Ok, also seeing nodding in the room.
  • GS(p12): Discussion happened around protecting EDHOC error
    messages once that becomes possible to do. For example, the
    Responder completes EDHOC and derives a Security Context, but
    does not want to talk to the now-authenticated Initiator. TLS
    protects such a follow-up error message. The plan is that,
    following EDHOC message_3, EDHOC error messages are not
    protected with OSCORE. This was also discussed in the CoRE WG
    and detailed in draft-ietf-core-oscore-edhoc. Plan to clarify
    here too per PR #398.
  • GS (p13): seccons for the new header parameters kccs (the
    payload of a CWT, like a raw public key) and kcwt. When using
    raw public key, you need another way to verify, or it's TOFU.
  • SF: Had a look at PR #398. What change is it proposing?
  • GS: It's not done, but it's supposed to describe how to handle
    the case "when a session is completed, what can you do with the
    key material?"
  • SF: So #398 just clarifies, but doesn't introduce new ways to
    (protect?) errors.
  • GS: These were all the current issues. Think we're done, waiting
    for Paul (AD review) and LC.

  • GS: Also have industry review.

  • MV: So lake-traces is ready for WGLC? Should we wait for the AD
    review of -lake-edhoc first, or move forward already?

  • PW: No, just do the WGLC.
  • MV: We'll start a WGLC on the mailing list.
  • GS: Marek has confirmed he looked at both traces.

• EDHOC rekeying (John Preuß Mattsson, 15 mins)

  • (MV: John is here so back to the original agenda.)
  • Presented slides:
    https://datatracker.ietf.org/meeting/116/materials/slides-116-lake-edhoc-rekeying-and-psk-authentication-00
  • JPM: PSK and resumption were in original discussion, but not
    pursued to keep things slim. PSK was also not followed when it
    turned out you could do this symmetrically.
  • JPM: Recent TLS discussions said to discourage PSK method w/o
    forward secrecy.
  • JPM: New method should provide ephemeral key exchange.
  • JPM: New method -- both parties authenticate with PSK. DH
    requires one DH operation, comapred to 3. It eliminates anything
    external (fetching keys from external DB).
  • JPM: Credentials only identified in message 1. Also added to the
    salt (now approved by CFRG). Charlie's comment prevents this
    being a NACK oracle. A PSK could in particular be the output of
    EDHOC.
  • JPM (p6): More points for discussion. This enables for
    encrypting C_I and EAD_1 in message_1. That'd stop an
    attacker from creating a new message_1, but they can still
    replay it. Tracking becomes also possible though; need to addres
    the two peers getting out-of-synch.
  • JPM (p6): A (random) key identifier can be derived here, in the
    same spirit of the TLS ticket. Explicit identifier makes it
    smaller, but that'd be in message 2 which is the most length
    critical. Also possible to check multiple identifiers: 15 MAC
    checks are still orders of magnitude cheaper than asymmetric
    checks.
  • JPM (p7): More comments that arrived. Question remains: Is this
    something the group should do?
  • GS: This is useful also in EDHOC and OSCORE profile of ACE in
    the interest of resumption.
  • Scott Fluhrer: What PSK allows is it allows post-quantum
    security given a sufficient PSK. The alternative is something
    like KYBER, which is not lightweight.

• New LAKE charter open discussion (chairs, 15 mins)

  • Proposed new text:
    https://docs.google.com/document/d/1kQSscEwxNq_ZMY8xsl1tyPE-clM4CIJFLFNb23gRfa0/edit
  • MV: Let's discuss the new proposed text; several items proposed.
  • MV: New charter is focusing on EDHOC.
  • MV: How many have read the new charter text?
  • (5 raised hands)
  • MV: Any comments or objections?
  • MV: The first paragraph describes the current status. The second
    is on the practical uses of EDHOC (e.g., keying OSCORE). The
    third is on stating that the initial goals are achieved. Then
    the new work items start, progressing beyond what were initial
    boundaries (e.g., asymmetric authentication only)
  • MV: New items would be: rekeying building on symmetric
    authentication; applications based on EDHOC (e.g., assisted
    authorization, remote attestation, status verification of
    credentials); coordination and use of application profiles,
    including definition of a well-known profile; protocol
    extensions (e.g., greasing); implementation guidance.
  • GS: Good points; want to highlight about EAD fields. WG asked
    about "will this go on forever?". I think this is not the case;
    other WGs can define fields. But some of these points here
    (being biased) need to be done here b/c they are generic
    mechanisms (like revocation) that we'd like to do efficiently.
    Also, third party ? is needed for ultra-compact zero-touch.
  • RH: Charter is in a good direction.
  • MT: I'm interested in all these items, happy to contribute.
  • CB (via chat): Sounds like LAKE would have monopoly on defining
    EAD fields.
  • MV: That was not the intention, we'll attempt to rephrase.
  • CB: Not only means we have a monopoly, also means people have to
    go through this WG.
  • MV: Taking action item to rephrase.
  • SF: Poll on "is this text heading in a good direction?" (don't
    press anything buttons if you don't care, "do not raise hand"
    will mean objection)
  • (Raise hand: 15; Do not raise hand: 0)
  • SF: Looks clear that bunch of these 14 will also work on the
    items. Next step: Take charter text, ask AD to work it into data
    tracker. Now? After EDHOC LC?
  • PW: Now is fine.
  • SF: Will do traces first, and then kick off rechartering. (PW
    nodding)

• Simplifying deployment of draft-selander-lake-authz (Göran Selander,
  10 mins)

  • (Skipped in favor of more time for charter.)

• AOB

  • JPM: Christian mailed out GREASE proposal. Some words?
  • https://datatracker.ietf.org/doc/draft-amsuess-core-edhoc-grease/
  • CA: This registers a few codepoints that can be used to check
    the compliance/flexibility/resilience of EDHOC peers. For now,
    this considers identifiers of cipher suites not to be supported,
    and non-critical EAD items.
  • MV: Is there a value on this if people implement EDHOC
    correctly?
  • CA: Correct implementations would do this right automatically on
    the recipient side. Implementations that send grease will force
    some correctness on their peers. This is also a way to check the
    resilience of middleboxes in the same spirit of TLS.
  • JPM: TLS had similar problems, with middleboxes impairing the
    deployment of TLS 1.3. People unfortunately sometimes don't
    implement from the spec but from wireshark.

ACE Agenda

• Administrivia
  -- chairs, 5 mins
• pubsub-profile
  -- Cigdem, 10 mins
• revoked-token WGLC discussion
  -- Marco, 10 mins
• oscore-gm-admin
  -- Marco, 10 mins
• follow-up activities
  -- Marco, 5-10 mins
• edhoc-oscore-profile
  -- Göran, 10 mins
• selander-ace-coap-est-oscore
  -- Mališa, 10 mins
• AOB

ACE Notetakers

• Christian Amsüss
• Rikard Höglund

ACE Minutes

• Administrivia (chairs, 5 mins)

  • DM: Could Paul have a word on progress?
  • Paul: Once the current queue is depleted, is the WG thinking of
    winding down or is new work incoming? No commitment needed now.
  • DM: Maybe EDHOC opens new horizons. GS, maybe?
  • GS: Maybe have this after AOB when we see better where we are?

• pubsub-profile (Cigdem, 10 mins)

  • CS: For -06, MT has joined the authors.
  • CS: Originally considered full support for MQTT, but that is on
    backburner.
  • CS: The document relies on application layer security profiles
    of ACE. Last presented at IETF 110, but has been covered during
    interims.
  • CS: Current focus on better alignment with key-groupcomm.
    Completing KDC communication for pubsub clients and satisfying
    keygroupcomm requirements.
  • CS: Mostly there, just cleaning up. Previously, only described
    reuirements for joining the group and protecting the
    communication.
  • CS: Now, based on changes to key-groupcomm, we add more
    operations like node removal and group rekeying.
  • CS (p3): Architecture change recap (bold indicates new items
    since last IETF update). Client will send tokens to KDC and to
    broker. Next, by performing a join request the client can get
    security keys. Once the group join has happened the pub-sub
    client will talk to the broker to establish a secure connection
    using the Token. Payloads will then be protected by the group
    symmetric key, and also be signed.
  • CS (p4): Distinction between application group and security
    group.
  • CS: Current assumption is that topic maps 1:1 to application and
    security group. Thus, key material would extend to subtopics.
    Could be added to seccons, but might discuss in WG.
  • CS: Another point is that core-coap-pubsub has been updated,
    which brings in further discussions and need for aligment.
  • CS (p5): As client knows groups it's part of, needs tokens with
    two audiences.
  • CS: Scopes are pairs of pub-sub topics and permissions. The
    permissions describe the role of the client in the group
    communication (publisher/subscriber/read/delete (and admin is
    for future work))
  • CS: Two open points: 1. Have scope encode the audience of the
    token inside pub-sub roles. 2.?
  • CS: Still weighing the two proposals.
  • CS: (slide correction: should be "join response").
  • CS (p6): Based on discussions during previous meeting: The KDC
    assigns a unique sender ID to publisher clients. The AEAD nonce
    is then built based on the method in RFC8613, using such sender
    ID and the local Sender Sequence Number used as Partial IV.
  • CS (p7): Next steps.
  • GS: Happy to see energy in both this and CoRE side of this.
    Joint implementations with CoRE authors planned?
  • CS: At the moment we have connections on the spec-level (contact
    with MT). I am following the Github and IETF submissions. There
    should be joint work at implementation level also, that is my
    wish.
  • DM: If we expect joint work, do we expect that draft to be in
    WGLC in terms of years or months?
  • CS: It depends on the progress of the pub-sub work. We need to
    wait to align well with them. Some changes in terminology (topic
    collections etc.) that need to be reflected better in the draft.
    Especially to support KDC and resource discovery. Same goes for
    application and security groups, and how prescriptive we should
    be regarding that.
  • AK: Thanks for doing this, as pubsub coauthor, sorry for the
    delays there. Now is a good base to align drafts. Happy to work
    together.
  • AK: One small thing from CoRE was that config parameters (max
    subscribers / publishers) was "should this be done on the
    security side". Could sync there.
  • CS: Definitely and I made a note regarding this.
  • CB via chat: We like to expose structure in CBOR as opposed to
    crating new custom text syntaxes
  • CS via chat: +1

• revoked-token WGLC discussion (Marco, 10 mins)

  • DM (general comment): I had a look at the status of documents,
    the groupcomm draft was moved to the IESG. We are waiting for
    Paul to move them forward. There are also 2 drafts cm2-coap and
    coap-eap waiting for reviews. These are 2 the AD can put some
    resources on.
  • MT (p2): Many changes since 115, also presented in interims. Now
    all open points addressed. WGLC passed. Got reviews from MR and
    RH.
  • MT (p3): Clarified details on handling of the Tokens on the
    parties involved. Especially regarding late posted Tokens with
    EXI claim. The security considerations have been expanded.
  • MT (p4): Examples now collected in one appendix, more examples
    were added for the diff-query mode when using the cursor
    extension. Downgraded conditional-attributes reference.
  • MT (p5): Summarizing the content of the reviews. No core
    functionality changes needed. No outstanding issues to discuss.
  • MT (p6): Next steps: work on the next version addressing the
    WGLC comments.
  • DM: Any comments. As soon as the version is ready it will be
    sent with request for publication?
  • MT: We are still waiting for one author to confirm that they
    want to stay as author. And then we need a shepherd. Hopefully,
    that can be one of the Chairs if nobody volunteers.
  • DM: We can deal with this.

• oscore-gm-admin (Marco, 10 mins)

  • MT (p2): Recap of functionality. An admin interface on the
    OSCORE Group Manager. Meaning for creating, configuring,
    deleting OSCORE groups. Adds two new resources on the GM. Using
    ACE for authentication and authorization. Administrator is C,
    OSCORE Group Manager is RS.
  • MT (p3): Discussed during interim meetings twice since IETF 115.
    Submitted version -08 before the cut-off addressing all
    outstanding open points. Plan to split document into 2 (more
    details follow).
  • MT (p4): Summarizing updates done since IETF 115. This includes
    atomicity of operations, effects of configuration change, new
    error code.
  • MT (p5): CoRAL examples revised, using CBOR diagnostic notation
    and Packed CBOR (with compression tables in an appendix).
  • MT (p6): Plan is to split the document. 1. Current content minus
    the CoRAL related parts. 2. New document with revised
    CoRAL-related content dressed-up to be self-standing. Proposed,
    discussed and confirmed during previous interim meetings and the
    mailing list.
  • MT: Think there is consensus now, could start doing it in April.
  • MT (p7): Next steps. Work on the document split (not entirely
    straight forward) and submit the new document as a WG draft -00.
    Intent is also to polish the current document, of which the next
    version -09 might be ready for WGLC.
  • DM: In my mind non-CoRAL document should be in WGLC and probably
    even IESG before next IETF meeting.
  • MT: Should be doable. I checked with the authors of the current
    document. For the new CoRAL-related document, only two authors
    stay from the current document (MT and RH).
  • DM: Much discussed in interims.
  • MT suggesting switching topic sequence, GS to continue

• edhoc-oscore-profile (Göran, 10 mins)

  • GS (p2): Since IETF 115 v-01 was submitted.
  • GS: Purpose of this presentation: Discuss flows in ACE framework
    and profiles.
  • GS (p3): Showing typical workflow for ACE-OAUTH. Bold borders
    indicate communication is protected.
  • GS: Existing profiles (9202, 9203) vary the flow: A. updating
    rights w/o re-authentication, and B. updating security context
    (eg. token inside authentication protocol).
  • GS: I want to discuss these flows in the context of the EDHOC
    OSCORE ACE profile.
  • GS (p4-5): Showing A. update of access rights without
    re-authentication. B. Provisioning of the access token.
  • GS (p6): So what should we do in EDHOC-OSCORE profile? -01 has
    default flow, and A., and B through EAD, using EDHOC_KeyUpdate
    and using KUDOS.
  • GS: Things become complicated due to these many options.
    Proposal to remove B.2 (usage of EDHOC_KeyUpdate).
  • GS: New potential work in LAKE about symmetric-key-based
    authentication in EDHOC would fit nicely here.

• follow-up activities (Marco, 5-10 mins)

  • MT: Presenting new ideas as follow-up activities.
  • MT (p2): Presentation is about possible new work items.
    Previously raised and discussed at interim meetings.
  • MT (p3): AS can upload token to RS, per a new workflow.
  • MT: Started in EDHOC profile, but is generally applicable to the
    framework, irrespective of the specific profile.
  • GS: This particular case was proposed for LwM2M, where the AS
    has contact with all RSes. Simplifies work for constrained
    client.
  • MT (p4): Introducing new parameters. token_upload in AS-Client
    response, indicating in that new workflow a confirmation that
    the AS uploaded the token to RS.
  • MT: Audience could comprise multiple servers, but rs_cnf in the
    AS-to-C response can specify only one public key. Proposal is to
    specify a new parameter like rs_cnf2 to transport more public
    keys, i.e., one per RS. But which key is of which RS? This could
    be indicated in a companion parameter, specifying identifiers of
    those RSs ordered in the same way as the public keys in
    rs_cnf2. This is applicable to profiles that support asymmetric
    authentication credentials (e.g., DTLS profile and EDHOC
    profile).
  • JPM: I am supportive of these optimizations. The original
    message flows are not all that lightweight. Having one key on
    multiple RSes (one key for many domain names) is common on the
    web.
  • MT (p5): Regarding certificates in the DTLS/TLS ACE profiles.
    The EDHOC ACE profiles uses new asymmetric credential types and
    code points for these are now available, e.g., as CWT
    confirmation methods. They can be used in the DTLS/TLS profile
    too, so it can use certificates as credentials.
  • MT: (new idea from yesterday) Additionally admitting CCS in
    there would be an alternative way to transport an RPK (besides
    the current COSE Key), which sounds like a minimal additional
    effort.
  • JPM: This is very good. 3GPP has adopted ACE DTLS and OSCORE
    profiles. A comment from them was that they need TLS and they
    like certificates. What's important for ACE is to make the basic
    profiles, and then their usage can be extended, willing to help.
  • MT (p6): Summary of the 3 new items. One document (updating the
    ACE framework) can cover the new workflow, and the new
    parameters. Another document can focus on the DTLS/TLS profile
    update for using more asymmetric authentication credentials than
    COSE Keys.
  • CS (on chat): +1 for the proposals, we introduced some field
    overloading in MQTT v3.1 token provision in MQTT-TLS profile and
    AS->RS could help resolve that.

• selander-ace-coap-est-oscore (Mališa, 10 mins)

  • MV (p2): Context -- potential new work in ACE. Need a way to
    enroll certificates for static Diffi-Hellman public keys.
  • MV: These devices have OSCORE, want to leverage that for
    enrolling EDHOC static-static certificate. RFC9148 follows EST
    design with DTLS.
  • MV (p3): First published in 2017. Follows structure of RFC9148,
    but using EDHOC and OSCORE instead of DTLS. Agreement in
    previous ACE interim meeting to work on this, but to first
    complete EST-coaps. So work is resuming now.
  • MV (p4): IMO draft is non-controversial. Follows EST-coaps very
    closely, differences and improvements on slide (can use
    untrusted proxies).
  • MV (p5): Figure with protocol layering.
  • MV (p6): Mutual authentication using EDHOC needed between
    EST-oscore client & server. Authentication using certificates.
    Allow the "Optmized request" defind in the core-oscore-edhoc
    draft.
  • MV (p7): Functions overview -- aligned with EST-coaps.
  • MV (p8): One difference from EST-coaps is the enrolment of
    static DH keys. This is the most efficient EDHOC authentication
    mode. Presenting step-by-step of the procedure. PoP of static
    keys is done using RFC6955.
  • MV (p9): Next steps. Some sections are still to be completed,
    but looking for reviews to advance it in ACE.
  • MT: Happy to see this coming back. I support this, I will
    review.
  • DM: If this got adopted, who will lead this?
  • MV: I took the action to revive it. The author list is active,
    and we're discussing privately. "We" are the co-authors.
  • DM: One thing I'd like to avoid is having one author committed
    to too many documents. If you take the lead, that'd be easier.
  • MV: Yes, taking the lead.
  • DM: Next step is call for adoption.

• AOB

  • PW: You mentioned CMPv2 CoAP transport draft. Did AD review,
    received comments in XML file ... As a general note, if you ask
    feedback from me on some text, please send old-text/new-text or
    do new draft in data tracker. It's important I can tick off
    issues quickly. Going through EMail kind of doubles the work.
    Where possible, use draft versions. They're cheap. The data
    tracker tracks data really well.
  • DM: You prefer to limit e-mail exchanges? But to rather submit
    new version of the draft.
  • PW: Short questions via email are fine.
  • DM: CMPv2 CoAP transport draft is under review by Paul. One
    other draft I'd like to not have fall into a crack is CoAP-EAP.
    It's independent, please have a look. We also have the 2
    groupcomm drafts being published.
  • PW: Look at my queue at data tracker. Top items are EDHOC and
    ACE group documents. These need to get out before new ones get
    in.

(No more AOB.)