Minutes interim-2021-ace-07: Tue 10:00
minutes-interim-2021-ace-07-202104131000-00

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