# Joint LAKE / ACE session - IETF 116 {#joint-lake--ace-session---ietf-116} ## Time {#time} * LAKE: Thursday, 30 March 2023 -- 00:30-01:30 UTC * ACE: Thursday, 30 March 2023 -- 01:30-02:30 UTC ## Useful Links {#useful-links} * [Charter][1] * [Mailing list][2] * [Instant Messaging][3] * [Minutes][4] * [Remote participation][5] ## LAKE Notetakers {#lake-notetakers} * Marco Tiloca * Christan Amsüss ## LAKE Agenda {#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 {#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 {#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 {#ace-notetakers} * Christian Amsüss * Rikard Höglund ## ACE Minutes {#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.) [1]: https://datatracker.ietf.org/group/lake/about [2]: https://www.ietf.org/mailman/listinfo/Lake [3]: https://zulip.ietf.org/#narrow/stream/11-lake [4]: https://notes.ietf.org/notes-ietf-116-lake [5]: https://meetings.conf.meetecho.com/ietf116/?group=lake&short=lake&item=1