ACE Interim Meeting 2021-04-13 14:00 - 15:00 UTC --- ## Attendees 1. Francesca Palombini, Ericsson 2. Rikard Höglund, RISE 3. Marco Tiloca, RISE 4. Cigdem Sengul, Brunel University 5. Dan Garcia-Carrillo, University of Oviedo 6. Mohit Sahni, Palo Alto Networks 7. Daniel Migault (Ericsson) 8. Logan Velvindron 9. Rafa MArin Lopez 10. Carsten Bormann # Minutes * [Note Well](https://docs.google.com/presentation/d/1YuUzfZMbMijvpJJkBoOkppOaec4u2S_TMBowo1EqQVY/edit#slide=id.g9edff33b62_0_0), agenda bashing * minute taker, blue sheet * Agenda Bashing * draft-ietf-ace-cmpv2-coap-transport Mohit presenting the slides: received comments, and need to add the new version of cmp (stop referring version numbers, new section on service discovery and ? A new draft is planned covering all comments). Getting ready for last call. Daniel: Asking for feedback for starting the last call with the new version. * draft-ietf-ace-wg-coap-eap Dan presenting the slides: feedback received from Cristian for ordering guarantee.Need to introduce a new sequence number to be independent of CoAP. Brainstorming ideas in slides e.g., can we use a token for this? Echo option is a clean alternative for ordered delivery compared to URI-Query, Location-Path/Location Query. Daniel: Any one with a strong opinion? Carsten: Why inventing new options for sequence numbers (e.g., message ids)? Anyone looked into doing this over REST? Dan: There are other proposals over HTTP Carsten: We may want to see how they solved that problem? Looks similar how REST solved similar problem. One problem: cannot look at problem in isolation; several concurrent executions - need to look at how executions should be kept separate of each other. Dan: So, should we consider every state of the SM to signal the current step? Carsten: State as seq. numbers is problematic. Several executions of protocol running at the same time. Dan: Constrained device, so one authentication process at a time. Server returns a resource id signaling client the state. Dan: Showing exchange between EAP authenticator and client. Not shown in the figure the AAA server. IoT device triggers the first message to initiate the process, controller takes over being the CoAP client. Carsten: When you do a post to a resource with name; controller needs to know the resource exists.Controller does a post to this resource. Dan: The first post should not have b/5, that is assigned Carsten: How does a controller know which resource? Dan: Explained service discovery Carsten: There is no connection between Non Post/Post - it is important to separate two controllers coming to the device. The sequence number can live in location number in the responses, and URI path in the requests. Dan asked about naming. Carsten: It is the decision of the IoT device. Dan: that simplifies the process. It is clear now without using complex options. Carsten: These resources go away after the protocol is run, so 2.01 is the right response. Dan: Towards CoAP we can be just creating new resources. There is no problem there. Great. Rafa: OK, that solves the seq. number, it's still confusing that there is a new resource at each EAP packet. You are changing the resource - that resource is processing a couple of messages, which are related to previous and next messages. Carsten: Helps to think not seq. number and application states. The device destroys an old state, and creates a new state; so 2.01 is appropriate. States are encoded in the URI. Rafa: In my mind, all this conversation will be kept in one resource. Carsten: That's how SOAP works, we've gone away from that. Rafa: Yes, creating a new resource solves the problem. Loganaden: Why don't we continue in the mailing list. * draft-ietf-ace-pubsub-profile Cigdem: Work on GitHub repo to include the MQTT; the architectural changes will be implemented and will be in the next version. Discussed with Marco how to support MQTT security groups better (when topics are wildcards) and found a clear path for implementation. * draft-ietf-ace-key-groupcomm-oscore Marco, presenting slides: Few updates from IETF meeting in slides e.g., group-id recycling, removing redundancies about key type capabilities. Omitting details, they are in the draft; changes implemented and tested in codebase. New appendix with generalised format parameters to be future-proof, in case of new algorithms with more COSE capabilities than the key type. All consistent except ace-key-groupcomm already defines sign_info_entry. Needs to be fixed - option 1: ace-key-groupcomm keeps things as is, but allows profiles to deviate; option 2: move the new general format for sign_info_entry to an appendix of ace-key-groupcomm already. Feedback? Loganaden: We would welcome more reviews. Daniel: Ask in the mailing list, and also for more reviews. Marco: Should I implement the option 2 to have sth. more concrete. Cigdem: Does option 2 break anything? Marco: No. I prefer option 2 since it doesn't create grey areas and require only a forward pointer in the document body. But I will bring it to the list. # WG Status: In IESG: * draft-ietf-ace-coap-est (RFC Ed) * draft-ietf-ace-oauth-params (Approved) * draft-ietf-ace-dtls-authorize (Revised I-D Needed) * draft-ietf-ace-oauth-authz (AD followup) * draft-ietf-ace-oscore-profile (Revised I-D Needed) In WGLC * draft-ietf-ace-key-groupcomm * draft-ietf-ace-aif AD evaluation: * draft-ietf-ace-mqtt-tls-profile