ACE IETF 107 Interim Replacement Meeting 15 April 2020 Agenda webex: https://ietf.webex.com/ietf/j.php?MTID=mb5f50b1e50b7e9ad04f89d67ea2e4caf jabber: ace@jabber.ietf.org etherpad: https://etherpad.ietf.org/p/notes-ietf-interim-2020-ace-05?useMonospaceFont=true Administrivia * 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? Crickets 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 authorization 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 included. 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 name/password overload initial connect message includes version to talk BK: Then the dual stack should deal with things correctly, but it has the needed Clean session 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 ISSUE #60 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. ISSUE #83 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 issue is. 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 ISSUE: #88 JS: Yes I think this covers the issue ISSUE #77 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 ISSUE #84 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 ISSUE #90 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. ISSUE #91 JS: That is probably fine - will review Group Action 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 Closing * Next interim meeting * doodle Monday May 18, 10:00 - 11:30 / June 22, 10:00- 11:30 NY TZ * AOB **************************************************************** ** 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