Minutes IETF108: ace
minutes-108-ace-01

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

minutes-108-ace-01

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

Other Non-Working Group Documents

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 GitHub.

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 issue.
      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 standard.
    • 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