Minutes interim-2020-ace-05: Wed 07:00
minutes-interim-2020-ace-05-202004150700-00

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