Minutes interim-2020-ace-05: Wed 07:00
Authentication and Authorization for Constrained Environments
||Minutes interim-2020-ace-05: Wed 07:00
ACE IETF 107 Interim Replacement Meeting
15 April 2020
* Support Staff
* Agenda Bashing
ACE Documents stuck with the AD
* DTLS Profile
* Authors responded with mail yesterday
* Have a github version dealing with issues.
Olaf: Waiting for response from AD and then will send new draft.
* The rest
* OSCORE profile - almost all review comments answered
* Text to justify 64 bit nonce from each side.
* Jim was supposed to propose some text and has failed to do so.
* Next version should be done
Working Group Documents
* MQTT-TLS profile of ACE (Cigden Sengul)
* Client Auth matrix - is the recommended OK with the group?
** Slide 3
CS: Any of the options are OK, just a question of should the document
recommend on of the options for usage.
DM: Is there anyone opposed?
DM: Any advantage to do auth at the MQTT layer
CS: Difference between the shared secret and the RPK cases
BK: Uniformity of work flow and possible privacy benefits.
DM: Hearing that doing the MQTT is good option
JS: My preferred option.
CS: And in the overauthicated case (both TLS and MQTT)
If the tokens are different, then keep the last one and do not merge them
Is this acceptable?
JS: I think the group has generally said don't merge tokens
BK: Make it clear what the behavior is and agrees that merging is hard
GS: Is there a question of order here? Client provides tokens out of order
CS: If older token is used the second time, then it might lead to loss of
This is going to return back to the client as an error during
publication or subscription updates
BK: Don't worry about clients doing silly things
** Slide 4
CS: Always use exporter in the user name authentication
The question is when using the AUTH messages
For re-authentication using AUTH messages should the channel binding be
BK: I think it makes the reasoning easier for security analysis.
CS: Don't allow re-auth for the first column, but allows for the second
column and add the channel binding DM: Why would no security be included
BK: If both sides are sending nonces then already have strong agreement
that the parties are correct.
Adding in the exporter gives a slightly stronger statement that a proxy
does not exist in the middle.
DM: Which nonces?
CS: MQTT profile nonces
CS: Any issues with the sizes?
BK: Proceed on the assumption of the 8 bytes are fine
** Slide 5
CS: Looking at how interopable things are for old clients (v3.1)
V5 servers can implement the v3.1 overload of the user name/password
fields V3.1 clients might drop messages when linked with a v5 library
JS: Thinks should say don't do that - re-write your client to use v5 rather
than just link to v3.1 CS: the V3.1 client might use the JS: Think I am
coming down on the side of v5 servers should not support the user
initial connect message includes version to talk
BK: Then the dual stack should deal with things correctly, but it has the
BK: Are there benefits to not always doing the clean session. Makes
thinking about things easier JS: Yes, client can disconnect and re-connect
later and get the QoS messages BK: Not sure that I can get a happy answer
CS: Need to include information in the session on the slide. BK: Could this
document keep the MUST but have a later document negotiate this? CS: Makes
policy suggestions in the base MQTT document. No negotiation phase JS:
Token itself sets a limit on how long the session state can be kept. CS:
What about long lived tokens? Would still be able to have a token outlive
the sessions. DM: As long as it is a policy thing, keep things JS: Not
making things worse than the base spec DM: Hard to make things better. JS:
My preference would be to drop to a SHOULD CS: Warming to this as well -
deals better with clients with efficiently concerns
Broker vs Server
CS: Broker is the most common term
FP: Agrees with broker
CS: Hannes pointed out that the base documents use server not broker
FP: as long as in the terminology should be fine.
* Key Provisioning for Group Communications using ACE (FP)
FP: What is the state of the framework document at the AD
JS: Instructions given to AD where that I thought all of the documents
should go forward at the same time
as the framework w/o a profile might be difficult to understand.
JS: Clarity - on page 6 - if the client uses the same nonce would the
signature be the same? FP: Yes that would be correct FP: kdcnonce is being
used multiple times BK: Reuse is less worrisome if some of the attributes
of the request are also included. DM: Why is OSCORE doing it differently?
MT: Interpreted the nonce as really being only use once FP: Valid point -
should this be aligned? FP: Hearing keep as same and include the gid in the
signature computation DM: Need some randomness FP: Has a client nonce as
well which is different for each join
FP: Needs clarification on this issue.
JS: Wants to associate signing keys with the token rather than join itself.
FP: Will give it a shot.
JS: Client has pubkey 1, publishes update to pubkey 2, should it be able to
send message using pubkey 1 FP: Now I understand what happens and what the
Assumed client was not going to use pub key 1 anymore
FP: Why would a client do this.
BK: Key might have been compromised
JS: Assume all clients are evil.
BK: Client might send a signal that the new key is setup.
FP: Not sure what solution is
MT: How does that fix the problem
JS: All sorts of things on the public key updates might be needed for this.
DM: What if a client is doing constant pub key rollovers
JS: Will through you out of the group
BK: KDC would need to be able to deal with this
JS: Yes I think this covers the issue
CB: Ask for clarification on what the meaning of an empty array
FP: If array is empty then means don't ask about
JS: Seems complicated, but it would solve the issue that I asked for and I
did not try to solve
JS: I am totally happy to say that this can be punted
CB: This might make it better for doing key roll over
FP: Already talking about nodes using key material for delay use and this
goes into this as well. CB: Similar issue with some compression contexts in
a different RFC
JS: If I am doing this in MQTT then want to be able to do in JSON as well.
CB: Would hate to go in the opposite direction of TEEP where they removed
JSON FP: This is not difficult CB: All interop testing needed to be done
twice and people decided that this was not needed.
Adding choice makes sense if a benefit exists
FP: If this is used by MQTT, then
JS: At one point we agreed with the IESG that we would support both JSON
and CBOR, can we break that contract? FP: This is something new so might
not be needed CB: Prefer not to create choices if there is no need for one
BK: Willing to send to the IESG w/o JSON. No guarantees on the response.
JS: That is probably fine - will review
FP: Ask for review on any issues that are marked.
* Key Management for OSCORE Groups in ACE (MT)
JS: Please clarify why a monitor needs to use a message
MT: Use of this for direct one to one.
JS: If it is going to respond, make it a responder not a monitor
MT: Need new policy to say that it is supported
JS: Yes have to
Use of NONCE
JS: Agree that nonce means one use, but don't like the difference
MT: Any preference on the way to use
JS: Willing to to just rename, so it could be anything.
MT: What about the specific methods
JS: Worried about the re-use of the challenge being re-used, is there a
leak. Need to do a new challenge response to be fully right FP: Will
rename the field
The following documents were not discussed as the meeting ran out of time.
* Pub-Sub Profile for ACE (No presentation)
Non-Working Group Documents
The following documents were not discussed as the meeting ran out of time.
* Group OSCORE Profile for ACE
* Admin Interface for OSCORE Group Manager
* Notification of Revoked Access Tokens in ACE
* Next interim meeting
* doodle Monday May 18, 10:00 - 11:30 / June 22, 10:00- 11:30 NY TZ
** BLUE SHEETS
Francesca Palombini, Ericsson
Jim Schaad, August Cellars
Marco Tiloca, RISE
Olaf Bergmann, Uni Bremen TZI
Peter Yee, AKAYLA
Rikard Höglund, RISE
Ben Kaduk, Akamai
Ivaylo Petrov, Acklio
Cigdem Sengul, Brunel University
Michael Richardson, Sandelman Software Works
Carsten Bormann, Uni Bremen TZI
Klaus Hartke, Ericsson
Martina Brachmann, Ericsson
Valentin Tudor, Ericsson
Elena Palombini, Politecnico di Milano
Göran Selander, Ericsson
Stefanie Gerdes, Uni Bremen TZI
Amelia Andersdotter, ????
Jim Reid, rtfm llp
Kazunori Fujiwara, JPRS
Nico Peterson, ????
Peter Yee, ????
Renzo Navas, IMT Atlantique
Daniel Migault, Ericsson
Michael Breuer, ilSF