Ace Status PagesAuthentication and Authorization for Constrained Environments (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2014-Jun-16 —Chairs:
IETF-110 ace minutes
Session 2021-03-12 1700-1900: Room 6 - ace chatroom
--- **Authentication and Authorization for Constrained Environments (ace)** IETF 110 - 2021-03-12 16:00-18:00 Friday Session III --- Daniel Migault (ericsson) Loganaden Velvindron (cyberstorm.mu) \[~~etherpad~~ codimd](https://codimd.ietf.org/notes-ietf-110-ace) \[meetecho](https://gce.conf.meetecho.com/conference/?group=ace) \[material](https://datatracker.ietf.org/meeting/110/session/ace) jabber: email@example.com --- # Agenda Minute takers: Christian, Mohit. * Agenda bashing and [note well](https://docs.google.com/presentation/d/1YuUzfZMbMijvpJJkBoOkppOaec4u2S_TMBowo1EqQVY/edit?usp=sharing) * blue sheets, jabber scribe, new co-chair presentation Daniel introducing Logan * WG status * Working Presentation * draft-ietf-ace-cmpv2-coap-transport 15 min * draft-ietf-ace-wg-coap-eap 15 min * draft-ietf-ace-aif Carsten 10 min * draft-ietf-ace-key-groupcomm Marco 15 min * draft-ietf-ace-key-groupcomm-oscore Marco 10 min * draft-ietf-ace-pubsub-profile Cigdem 5 min * draft-ietf-ace-oscore-gm-admin Marco 10 min * draft-tiloca-ace-revoked-token-notification-04 Marco 10 minutes) * draft-tiloca-ace-group-oscore-profile-05 Marco 10 min # WG status Daniel going through the document. * Publication queue * draft-ietf-ace-coap-est waiting for a reference (DTLS) * sent to the IESG telechat: * draft-ietf-ace-oauth-authz * draft-ietf-ace-oauth-params * draft-ietf-ace-oscore-profile * draft-ietf-ace-dtls-authorize * AD review * draft-ietf-ace-mqtt-tls-profile How aligned is this with updated framework text? (Not about changes, more about recommendations between C-AS and C-RS). CS: Not a problem. * WGLC * draft-ietf-ace-aif CB: Thanks Christian for the review (yesterday); not looked at yet. This is a 6w WGLC, my personal record. Still ample opportunity to provide reviews. DM: LV to be shepherd. * New adopted drafts: * draft-ietf-ace-cmpv2-coap-transport * draft-ietf-ace-wg-coap-eap * WG focus * draft-ietf-ace-key-groupcomm * draft-ietf-ace-key-groupcomm-oscore * draft-ietf-ace-cmpv2-coap-transport * draft-ietf-ace-wg-coap-eap * draft-ietf-ace-pubsub-profile [current milestones](https://datatracker.ietf.org/wg/ace/about/) DM: Not going in here, we're good. [interim meetings](https://ietf.webex.com/ietf/j.php?MTID=m4d4b02389fc6f862663a7ac103a9d9ce) relation to [oauth](https://datatracker.ietf.org/wg/oauth/documents/) / [gnap](https://datatracker.ietf.org/wg/gnap/documents/) DM: I want to make sure that we're not evolving on our own, we keep in touch with those. Who's attending them? (collecting +1 in chats). Collected: +1 on gnap (Olaf Bergmann) # Note on XMLv3 submission ## kdrfc gem install kramdown-rfc2629 pip3 install xml2rfc kdrfc -3chi draft-x.md You get: — draft-x.txt - draft-x.html - draft-x.v2v3.xml …and an idnits report. Submit the draft-x.v2v3.xml at https://datatracker.ietf.org/submit/ (Do NOT submit the .txt at the same time — that will be regenerated.) ## online tools To convert a markdown file (specifically kramdown) to v3 XML, you can use the converter available here: https://xml2rfc.tools.ietf.org/experimental.html Please select Input type: kramdown Other: convert v2 to v3 XML v3 FAQ: https://xml2rfc.tools.ietf.org/xml2rfc-doc.html (Details on what to do after converting to v3: https://www.rfc-editor.org/materials/FAQ-xml2rfcv3.html#name-after-converting-an-xml-fil) xml2rfc mailing list: https://www.ietf.org/mailman/listinfo/xml2rfc # Presentations ## CMP over CoAP Mohit presenting (see slides) CMP over CoAP already done, this sets guidelines. Please read and comment. A list of key topics is in the slides. DM: Any concerns especially w/rt the proxy? CB: When you use proxies with DTLS, then the proxy is in a position to influence the data (middleperson attack). Is this discussed? MS: Certificate of proxy should be trusted by the IoT device. RAs (or whatever is closest to an RA) can act as a proxy also. CB: So proxy needs to be in same security domain as the end server. MS: Also case for UDP sendable to everyone. RAs can mitigate and block things that are not known. (chat): "SHOULD be configured to trust the [...] proxy". Do we have concerns with that? CB: Trust has to be in the device as well. Having a signed certificate from some CA I trust does not mean the proxy itself is trustworthy. MS: Idea is that the proxy should be at the edge of the network where all the IoT devices are; before they go to the Internet the proxy can be at the GW and managed by the ... two types, either by the CA/RA[?] so devices trust it. Other case is someone has that proxy at the edge. At that point, the proxy can convert CoAPS to HTTP, and that would be managed by same admin who is running them devices. CB: It's not about trusting certificates, I trust many certificates but not the websites behind them. Not sure, maye CMPv2 doesn't need that (but then it doesn't need DTLS either). BK: Carsten, I don't know if you are aware that CMP has a dedicated extendedKeyUsage value in the certificate for the RA. So if you trust the root CA, you can trust that the entity that holds the private key of that certificate is supposed to be acting as an RA. MS: DTLS is only required for privacy, not for trust. ## CoAP EAP DGC presenting (see slides) p3: Bootstrapping service. Server chooses authentication method. p4: After EAP success, IoT device has joined the security domain and established a registration. Controller and device now share key material. CA: The usual thing to do with CoAP here is to make recommendations about ways to use CoAP, but not assume you have control, and especially not require peers to do that. DGC: We should go with an assumption that we cannot make requirements on the CoAP layer MSethi (via jabber): can we not have bullets in abstract? the iana section is incorrect. It should request IANA to assign a value for CoAP as a lower layer in the EAP registry: https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-lower-layers. I have not read the latest version of the draft but plan to send my review in the near (or far) future. would be good to investigate if some optimizations can be achieved by tighter integration between coap and eap. for example relationship between coap message-id and eap request/response-id08 DGC: Will need some research there; can use message ID if we have control over it. DM: Which is the protocol to be left unchanged, CoAP or EAP? DGC: CoAP should not be changed, should be able to use numbers in CoAP to send to EAP state machine. Try to avoid EAP state machine as much as possible. If on CoAP side we can create the state to feed to EAP, that would be good. MS / [?]: Guess neither of the implementations can be changed; unclear: implementation meaning state machine or DGC: That's why asked about control over CoAP engine. [?] Look at how much we can achieve. Worth exploring. CB: Reason to use CoAP is that it's implemented; demands not met by imlpementations don't get wins. What you can do is use properties of CoAP. Eg. you know there can be duplicate message detection. You can use the properties rather than influencing the header fields. DGC: So look at inherent characteristics without further demands. Build things by assuming we get standard CoAP. Raphael ML: Using sequence numbers is because we need to keep sequence of [?]. We abstract the application from the implementation. If you check the flow, then you wait for a particular sequence number. Also thought: If we can get rid of sequence numbers eg. using mix of message ID or token ... that's the main question. If we can from an application part say to the CoAP engine to set this ID, can we get rid of the sequence number? Just in case, we have it included. BK: The EAP state machine is sensitive. Slight modifications can cause security problems. (Came close to publishing a document w/ broken state machine). DGC: That's why I'd like to keep it out of the modifications. RML: No need to change EAP state machine. EAP standard is clear about requirements to lower layer. Wouldn't go for optimizations at state machine side. What it requires from lower layer is sequence numbering. DM: There's CoAP and EAP layer, we don't want to change them much. There could be a compression layer inbetween that could take some parameters from one and expand those to EAP, so that when the uncompressed packet hits EAP, it's not changed. DGC: That's the idea. If we can map the message ID in and make sure it does not cause alterations, that'd be the idea. DM: Looking at compression, there's SCHC, are you aware of that? DGC: [...] try CoAP-EAP on LPWAN networks. [...] take EAP even further. DM: So we can also split it (compression), not everything needs to be in same document. ## Pub-Sub CS presenting (see slides, with discussion points) DM: I hear no disagreement; any strong agreement? DM: So we'll wait for the next version with the simpler architecture. CS: So I'll move to next new version then? DM: Yes. Comments please also to the list, as it's a significant deviation from the current draft. DM: On second issue (group join request) -- unsure, any thoughts from groupcomm folks? CS: It's more an issue of whether I have the right tools to work around it. First issue is that topic filters might suggest multiple groups where client is not aware of which groups they correspond to. So it's about multiple groups joined in a single filter. Not sure how this works for CoAP. In MQTT, there's wild cards. If they are grouped differently at KDC, different resources get different keys, but client isn't aware of that. BK on Jabber: on security of topics only guarded by broker CS: Yes ... depends on how groups are managed [?]. Can solve this at application layer. Like, if there is a clear application requirement to get an exact membership.[?]. Can clarify that, it's just that it's a little bit more strict than we do in MQTT TLS profile. Marco Tiloca: Does this require any adaptation in ace-key-groupcomm? CS: Trying to avoid that by using existing APIs provided by groupcomm. Just trying to figure the best way to addres this -- either being too strict at application and making clients request exact groups, or when being flexible, how to provide that. MT: key-groupcomm-oscore works in an easier way, but you join precisely the security group. The coupling you talk about is, for us in CoRE, by defining separate security and application groups that may have up to many-to-many mappings. Approach could be useful here if you think of application groups as your topics. CS: Looks promising. one-to-many...? MT: You can use many security groups with a single application (simple and safe), ... other direction trickier but have to be careful (documented). CS: Promising. MT: See application groups and security groups in https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/ ## Summarizing WG documents DM: CMPv2 is close to be ready, looking at interim. For others, more updates? Continue progress discussion in interims. ## key-groupcomm MT presenting (see slides) MT: Btw, pubsub of before is an application profile of this. p5: MT: Need feedback, if I am not missing any combination in slide 5 DM: Look at this with a pen; MT: comments can also come in an advanced review. BK on p6: need time to ponder on whether kid=node ID can hold. BK: Part of why it's hard for me to be certain is that COSE is more a framework and less of a protocol. There's little guarantee on what goes kid. Maybe we can, as an application, assert what goes in kid, but I'm not sure. MT: Can be left to application profiles. Node identifiers are assigned by the KDC, e.g. the Group Manager of Group OSCORE. DM: Do we conclude over that? MT: The new 'peer_identifiers' parameter is an additional optional parameter to be use in future cases. DM on p7: Ensure we're not squatting code points. MT: It's a new registry. CS on p9: Also matters to pub-sub. Use AIF there too in scope. Nice to see generic way. MT: The AS should be strongly recommended to use this unless there's just one application known to run on the KDC for which the Token is issued. CB: Who are we envisioning to actually register something there? Should an application register semantics? MT: ace-key-groupcomm-oscore is registering an integer. CB: So it's specification-required with small number of specs? Or will specific applications go ahead and do something? MT: Intended to be pretty open for any possible application, not only profiles of this document. Tricky to handle is squatting of semantics, don't want two codes to be used for one purpose and then one switching to the first. BK: Actual specific is key part here. Are there any cases where you want this usable without the explicit tag? MT: That means you need to know in advance it is extended scope format. Can't think of any, can't exclude. It'd save the tag, but harder to manage. CA: if there's a risk of colliding with something else, then there's already risk of colliding with other binary types. If there is a risk, the tag is just reducing the risk that a random data sent by some other application is misinterpreted MT: Tag just tells you to parse this as a sequence of two elements. CA: if there is any danger of the other party (AS/RS) not having this, then the other party might still be using some other format? MT: Also related to Ben's. It works if you already know in advance it's always, or is never extended format. MT: Can close the issue based on this. DM: Had much discussion on those. DM on WGLC question: Presentation shows latest version? MT: Yes, the issue on the last point just left open in case there was something coming up today. DM: Think we can start WGLC next week. Expected ace-key-groupcomm-oscore and this to be sent together ... but that's next presentation. MT: Can imagine shipping them together; in WG lifetime there may be a bit of a shift. ## draft-ietf-ace-key-groupcomm-oscore MT presenting (see slides) MT on p5: to remove reduntant parameters, as already done in equivalent data structures of core-oscore-groupcomm; this is specific to this document, no changes needed in ace-key-groupcomm. DM on p5: Good to remove redundancies, move ahead MT: More updates planned to synch with ace-key-groupcomm (following its WGLC updates) and done/upcoming updates to core-oscore-groupcomm. So probably not ready for WGLC yet. ## Closing Statement DM: Don't have time to other presentations. have lot of work to do in next interim meeting. And glad to see all the work.