Minutes IETF108: ace

Meeting Minutes Authentication and Authorization for Constrained Environments (ace) WG
Title Minutes IETF108: ace
State Active
Other versions markdown
Last updated 2020-07-29

Meeting Minutes

# ACE WG IETF 108, Wed July 29, 2020 11:00 UTC - 04:00 PDT (1.5 hours)

Meetecho: http://www.meetecho.com/ietf108/ace/
Jabber: xmpp:ace@jabber.ietf.org?join (this is part of the MeetEcho interface)
Etherpad: https://codimd.ietf.org/notes-ietf-108-ace (This is where you are)

## Agenda

### Administrivia
* Note Well and agenda bashing, Chairs, 5min
* Document status update, Chairs, 5min
* Document status update, Area Director, 5min

### Current Working Group Documents

Cigdem Sengul, 10 min *
Francesca, 10min *
Marco, 10 min

### Other Non-Working Group Documents

Carsten, 10 min *
Marco, 10 min *
Mohit, 10 min *
Marco 10 min *
Marco, 10 min

### AOB

* AOB, 10 min

# Minutes

## Document Stat Updates - 0:00

### OSCORE profile (FP)
FP: Small comments from the IETF last call.  Need to deal with some IANA issues
still. Issues have been put into the [tracker on

### DTLS Profile
JS:  Same situtation with the DTLS profile.  It needs a new draft and then the
AD can move all four documents to the IESG. GS:  Have not looked at the issues.
 Will ping Olaf for updates.

### MQTT - Cigddem Sengul - 0:07

* Session Continuation Discussion
    * CS: Underlying problem in MQTT: Client-IDs might be reused by a different
    identity * BK: Still need to get up-to-date on MQTT.  Can you have
    authorization w/ fresh session if the token has changed. * CS: If server
    does not match cached and current tokens, server would reject.  Still need
    some changes because clients may try to do the continuation anyway and the
    server needs to deal with it. * DM: If clients do not behave properly that
    is their problem * CS: Still a problem.  This is a QoS issue not a security
      If no changes then the client can provide a new token and whatever
      session state is associated with the session ID.
    * JS: Force disconnect by the server.  Client 2 comes in with the same
    session ID as client 1 - Server tosses client 1 and gives the session to
    client 2 * CS: Checked the language of the standard - MQTT says the server
    accepts new client.  Has to validate the new client.  Validation options
    could also come in to the process. * JS: We are not adding any new problems
    to MQTT with not doing this. * CS: Right - might be able to get rid of the
    problem.  This new state would potentially resolve this. * JS: I don't
    think it is worth adding the multiple token processing to solve the
    problem. * FP: nods * CS: I would be happy with that solution.
      I think this needs to be resolved outside of the protocol and not in the
    * BK:  Should only get in trouble if two clients are at war over a client
    ID. * CS: Will leave it as MAY. * DM: Should add some text describing the
    problem. * CS: Yes - also add pointers to MQTT processing.
* Reauthentication
    * CS: Require some ordering: Client-sent AUTH *after* Server-sent CONNACK.
       This was done in response to comments from JS.
* Questions - register thumbprints for CWT?
    * CS: Is this going to be done elsewhere if not done here?
    * JS: Not to worried if this document does not do the registration. 
    Somebody else is going to need this soon and they will do the registration.
    * MJ: Are there additional ones needed. * JS: Thumbprints of certificates
    and perhaps raw certificates of some type.
* Question - CBOR shortcut value.
    * FP: Ask for a value in the range and IANA will assign a value for it.

* CS: Ask for guidence on what needs to be done for the document.
    *  DM: THink that the next version should be ready for WGLC
    *  JS: Need to read the updates and check.

### Group Comm Francesca Palobini

* Remove default URIs and allow application profiles to define their own.
    * CB: Use of IF vs RT is a judgment call. More likely already knows that it
    is an OSCORE group so think that registering different resource types may
    work better.  RTs are cheap.
      Still define an IF for a generic group comm thing.
    * MT: Also support option #3 - this is what we are doing already.
    * JS: Could place the rt on both /group-root as well as /group-root/group1
    while /group-root/group2 could use a different groupcomm resource type to
    say that a different profile is being used. * DM: What profiles do we have?
    * FP: the OSCORE group and the pub-sub profiles (CoAP and MQTT)
      -> agreement for option 3 (rt per profile)
* Comment on renaming slide that the names may want to be more distinct to
remove clarification even more (BK, et. al.) * Add the PUT handler
    * CB: Parallel arrays are a bit FORTRAN to me, but yes this works
    * JS: Should really be FETCH not PUT
* Individual Keying Material
    * JS: Need to see it written down, but seems to be a reasonable way to go.

### OSCORE Group Comm - Marco - 5:03

* Request from the chairs to get people to review

### CoAP Transport for CMP - Mohit Sahni - 5:11

JS: This is here for possible adoption, but the WG is not not expected to have
expertise in the CMP protocol, but just looking at how the CoAP work is done.
DM: Objections to doing this work? No objections registered. DM: Need to
re-charter and then adopt. JS: Recharter does not stop us from doing reviews.
GS: Reading table of contents - multicast and proxy support MS: Don't use
multicast for this.  Only used for service discovery. Need to have proxy
support to get additional security for servers. GS: This is just a transport
draft? MS: Yes.

### AIF Authorization Info - Carsten - 5:21

DM: Is there a registry for the methods of AIF-REST?
CB: Yes - variants need to specify the permissions.  For this used the CoAP
method numbers

CB: Has it been adopted?
JS: Chairs need to get together to make final decision.  Should be today or
tomorrow. BK: Who tracks the resources for dynamic permissions? CB: It is the
resource server, this is not generally communicated off the RS. BK: Just asking
about what else is similar due to the broader scope that this might be. CB:
When started, looked for other ways and not really found.  Static resources on
a server and somebody else telling the RS who has access seems to be a fairly
new concept.

### Group Admin - Marco - 5:31

JS: On the use of different names for management and joining nodes:  Don't know
if there is an advantage, but that is what the pub-sub document in CoRE was
doing so they may have ideas.

* Who selects the name
    CS: server may have more constraints

MT: Adoption call result?
DM: We'll let you know.

Adjourned - 5:43

*[JS]: Jim Schaad
*[DM]: Daniel Migault
*[FP]: Francesca Palombini
*[MT]: Marco Tiloca
*[CB]: Carsten Bormann
*[MS]: Mohit Sahni
*[CS]: Cigdem Sengul
*[GS]: Göran Selander
*[MJ]: Mike Jones
*[BK]: Ben Kudak