# ACE WG IETF 105, Thursday July 25, 2019 17:40-19:10 (1.5 hours) Note takers: Christian, Jim Schaad ### Intro Daniel Migault: presenting agenda JS (Jim Schaad): Working group document review. Turned over all of the documents and waiting for AD review from Ben CB (Carsten Bormann): Priority indicated? JS: PoP, EST, the four OAuth documents CB: We really need PoP JS: PoP is in AD's "I'm trying to review it" state ### Current Working Group Documents * draft-ietf-ace-key-groupcomm, Francesca, 15min Francesca presenting -02 https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-key-groupcomm-00 Recap of the mechanism. Jim's review processed and signed off, going through changes. CB: Have you considered RESTifying that? This is a set of verbs. In REST, we usually do this over resources (create, delete, observe). FP (Francesca Palombini): Haven't considered that. If you have suggestions on better terms... . This is for new field (type), here we define what values mean. Can discuss that. Robin Wilton: When operation "leave" causes KDC to rekey, is there a MAY/SHOULD/MUST tell the group members that rekeying is happening? FP: It's a MUST. This document does not specify how rekey happens, Marco may tell more. Robin: If KDC MUST update keys for a group, are the members told that rekey is happening? FP: Depends on how rekeying is happening, depends on what is set up. This draft is general. Marco Tiloca: Left to the application depending on whether you need PFS. Francesca continuing with right column of page 3 Open points with -02 Scope (p4), proposed solution (p5) PvdS (Peter van der Stok): Technical detail to avoid confusion: Why not define scope in the two documents, one for group membership and one for pubsub, and leave it open in this draft? FP: Some things need to be specific to two documents (values of roles, ...), but this can be the same in both. Format of the scope can be same. Reason not to have same format? Daniel: So you want the scope [defined] in two different places in [...]? FP: No just in one place PvdS: Understand that scope is 2-array. But with several entries, it is used differently[?], that's confusing. FP: Take this offline. I take this as "think is confusing but not creating a problem"? PvdS: Implementer will take longer, that's all. Francesca continuing with open points (p6): nonce2, (requesting OAuth feedback on) registering new parameters in AS creation hints (but where else?) Mike Jones: Agree with Jim. Francesca continuing on open points: format of keys Further open points on rekeying (p7) CB: This is the point where I need to repeat my RESTify request. JS: One possible reason why this is better than REST here: Server can get confirmation that client got it. CB: Can do that with observe too. You don't get a response that the receiver liked it, but... FP: That's listed as one of the options. CB: Alternatives are bad. FP: Profile needs to specify which alternatives. CB: But why open a box of many alternatives? All need to be implemented, interop-tested. [...] Until a profile comes along that really needs this, why do it. Francesca continuing on multicast message rekeying (last item on p7). Will go ahead and implement this proposal. Daniel: "implement"? FP: Update the document. Daniel: Curious about RESTification. What's the impact? CB: Probably "some text changes"; can't answer in more detail before checking. Francesca on difference to ace-key-groupcomm (https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-coap-pubsub-profile-00 p2) ace-key-groupcomm provides for general group communication. pubsub-profile is specific content for CoAP pubsub and COSE ace-key-groupcomm-oscore is specific to CoAP groupcomm and OSCORE security PvdS: (Like few minutes ago) Have to go back and forth, parse few lines at a time. FP: First came here w/ CoAP pubsub profile in a single document. Then was told "wait that's group communication, can reduce this". Then I did that. Then was told to structured differently. Have to decide whether we want one document with all profiles, or separate ones. Can improve for sure on duplicate and repeating text, but need to decide a direction. I think this is the better direction compared to a huge document where you jump from one section to the other. * draft-ietf-ace-groupcomm-oscore, Marco, 15 min Presenting https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-draft-ace-key-groupcomm-oscore-01 Updates after Jim's and Ludwig's review Keep all three approaches? Benjamin Kaduk: Surprised CB is not coming up with "choices are bad". CB (getting up): choices are bad. CB: Haven't done work to decide which of these we need, don't know answer yet but work should be done. FP as co-author: Think it's good to have all of them and let application decide. CB: From the look of it would guess it is, but let's do the work. Marco continuing on p6 FP: Please say anything on your mind here, we need help on this. CB: X.509 and RFC7250 RPKs are potential candidates. There should be a way to register them once they're needed. Policy is probably more on the conservative side... JS from floor: don't think registry is needed, should key confirmation registry that's part of PoP document, that's there for all to use and can be registered to as needed. Marco continuing on p7, p8 JS "from the floor": should be a MUST. If not doing it, devices need to retrieve all of the public keys from the KDC again? Marco: Happy to make it a MUST. Ludwig Seitz (via Jabber): why would the GM shuffle around Sender IDs? Marco: If a single group member's sequence number wraps, GM can rekey the whole group (big impact on performance) or to just assign new sender ID, and all can resume. Other members derive a new security context, but on the wire it's efficient. Marco continuing on p9 on implementation, p10 on summary. Hope to go for full interop in Singapore. ### Other Non-Working Group Documents * draft-tiloca-ace-group-oscore-profile, Marco, 10min Marco presenting https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-draft-tiloca-ace-group-oscore-profile-01 about access control for resources at group members so far, any member can perform any operation on any other member's resources if a member of the group PvdS ad p7: Every time you make a new group...? Possibly there is a subset [...] it would be more stable. Marco: Yes, thanks. Marco continuing to summary JS from floor: Do we have real-world use case for this, or is that speculation? Marco: Can come up with example JS: That's speculation. Marco: Unaware of real-world use case right now. (off topic) Ludwig (remote): For those not following side discussion on Jabber, there are a number of ACE and CoRE documents dealing with communication security now. For new participant, a wiki page or informational RFC that explains how those documents interlink would be helpful. If someone volunteers, that helps. Francesca has example in one draft , but having it in one document is not very helpful. FP: I volunteer. * draft-palombini-ace-coap-pubsub-profile, Francesca, 15min Francesca presenting https://datatracker.ietf.org/meeting/105/materials/slides-105-ace-coap-pubsub-profile-00 (p2) Case made, hoping to keep the current structure. (p3) history / status update. CoRE pubsub is close to be done. MQTT pubsub profile adopted in here. (p4) Current plans, posing questions to WG. on bullet 1. More general? Example? JS: More general, no example. If you have an example, you have to document it, and I think it's not worth it (registration and so on and so forth). FP: Wouldn't be complicated to have as it's in current document. Daniel: Can we understand the document w/o the example? FP: Yes. Francesca continuing at bullet 2 Hannes Tschofenig: (FP proactively: You don't need OSCORE to do this). Who provided the feedback for this? FP: Jim, and more reviews from earlier versions Hannes: So multiple people suggested this? FP: Those come from the last review Francesca continuing at bullet 3, and p5 Would like adoption soon so it can move forward together with MQTT pubsub, as they are interested in protection of publication content. Daniel: Who read? (1 hand) Christian Amsüss: Latest or any? Daniel: any? ca. 4 hands. (Someone): And some more not in the room Daniel: Would be good if MQTT people reviewed as well FP: They have ### Any Other Business * AOB, 20 min JS: Had CoRAL side meeting this week. Need to define CoRAL vocabulary that can be published with CoRAL document so people can locate things like authentication, key servers and whatnot. Need to find people to do that. There was a document in CoRE this morning that defines link format attributes that do the same thing. Suggesting this should be migrated here as it's mostly focused on advertising ACE features. Expect both things on the list next month or so. JS: Ben, do you want to say you're reviewing documents? Ben: Had busy 2-3 months; only reviewed for ?, not for my working groups, things piled up. Things have calmed down, cleared backlog, doing it FIFO. If reason to prioritize, happy to move around. Right now in the middle of PoP, some more on ACE in next couple weeks. JS: Before end of August? Ben: Yes