Minutes interim-2020-ace-06: Mon 10:00
minutes-interim-2020-ace-06-202005181000-00

DATE: 2020-05-18 ACE WG virtual interim meeting 06

WEB EX: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee
Etherpad:
https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-ace-06-ace?useMonospaceFont=true
Jabber: host: jabber.ietf.org room: ace

Administrivia (5 min)
ACE Documents stuck with the AD
  - DTLS document (2 min?)

    Olaf:  Addressed the latest comments and uploaded a version
      Only the update of access rights left
      Some SAAG info from IETF 104 still to be addressed
    Ben: Saw the updates came in - still needs to look at them.

  - OSCORE document (15 min ?)
    - Update of access rights - Francesca Palombini
      document: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
      EMail discussions:
      https://mailarchive.ietf.org/arch/msg/ace/dLkW-MYHXfZqmtY7AP7ZBDJpxOw/
      Slides: 
      https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-oscore-profile-update-of-access-rights

    GS: Question to Ben's point about collision of KIDs. As the AS should
    provide unique KID values and the links should be associated with a single
    secure channel. JS: Could have situation where you are posting using option
    1 not option 1b Ben: Also fact that KID values may not be unique.  Even
    same AS could issue duplicate KID values for different keys for different
    context. GS: need to verify token comes from AS with key. Ludwig: Find 1b
    to be needlessly complicated.  Creating new endpoint w/ logic.  At rest
    level should be able to process internally. FP: Make sense for DTLS
    profile, but for OSCORE  profile need to know if resource is protected or
    unprotected.
       the /auth-info point is unprotected.  If token received then do the
       derivations.  If update of token, request needs to be sent protected
      First have to check if update of access rights, then need to make sure it
      was sent protected. need to go back in stack.
    Rikard - At the resource can check if it was already protected.
    FP:  Easier to allow if protected or unprotected.
    JS: Need to decode the OSCORE before the resource can do any processing.
    FP: Thinking in terms of doing filtering based on the presence of the
    OSCORE option to the message. GS: One benefit of is knowing when you want
    to clear vs re-use of context.
       could it be an example of this
    FP: No, either needs to be defined or not.  Profile should not have example
    of additional resources. FP: Since both implementers are saying not doing
    1b is not a problem we can skip that. JS: One advantage is that you are not
    doing the second security context derivation. FP: Yes - detect and do an
    update and just update access rights rather than new context.
       Complicated because different processing is being done.  Difference in
       behavior of logic
    RH: Need information in the resource if you are doing the update.
    FP: Need to return different payload on update.
    RH: Should be able to parse in the resource and do the different processing.
    FP: Do you need to update framework to make the statement on how updates
    are needed - need to use secure channel. LS: Not comfortable w/ that. GS:
    Should not need to be in framework. FP: Feels like it is more of a patch as
    a new profile might think it does not need to do the update of access
    rights over secure channel.
       Discussion on question of needing to update the framework and what the
       process steps are that would be required if needed.
    Cigdem: The MQTT profile treats this differently as it can do the re-auth
    for a new token in the protocol w/o doing the post to /auth-info
       Does not need any framework change for this point
    FP: The DTLS token does something similar w/ post over the DTLS channel
    Cigdem: Not a continuation on a reconnect.
    FP: Could post a new token over unsecured channel and not have it tied to
    token1 - i.e. not an update of existing token. GS: How does resource server
    know it is most recent token? JS: Should not be a problem as long as token
    is still valid GS: Stating that new token does not revoke the old token.
    LS: No current revocation in OAuth that is the same type of thing. FP: If
    done over a secure channel then don't need the identifiers from Jim's last
    mail.

- MQTT document is intentionally not on the schedule.
  document: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/

Group Keying Documents
- Framework -  Francesca Palombini
  document: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
  slides:
  https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-ace-key-groupcomm

  Harmonize the scope format:
      LS: Like the AIF format - suggest that it be used but not required.
      FP: No format specified currently in the document
      JS: Problem is that the AS needs to be modified to change the format for
      new ones JS: Just recommend a format to use and I don't care which one.
      DM: Which one? FP: If use the AIF then is an informational reference. DM:
      MQTT format has lots of experience with it? CS: The scope is not widely
      used just MQTT. CB: Format will not cover all of the RESTful issues
      because names for all resources are needed.
          Dynamic creation would indicate a application format to be used.
          Being open to application specific method is necessary.
     LS: Should provide a starting point just as needed to help.
     FP: Does this need to be an information or normative reference?
     JS: Informational is fine with me.

  How does one enforce the MUST NOT for the resource name?
     FP: Read slide
     Ben: I think I messed this - ask for clarification
     FP: Providing a default name
     Ben: How does this relate to BCP on who owns resource naming.
     FP: Yes that is why this is using default names, but saying name must not
     be used for something else.  How do you do a testable way? Ben: Don't know
     how to test for it. JS: Also worried about testing.  Since it needs to be
     configurable then defaults may be not used and things are going to be
     pointed elsewhere

  Add node insertion in the path
    JS: Clarifies that the question is dealing with collisions with other
    pre-defined resources under nodes FP: Now I understand and it makes sense.

  Issue on getting previous material to decrypt messages for which it missed
    FP: Could this not be thought of as just having the message lost rather
    than a don't decrypt JS: Yes it could be treated in that manner. FP: OK -
    don't think this needs to be done.

 When does a KDC need to roll the keys over?
    FP: No considerations of what happens when a KDC crashes and restarts.
       Not sure what needs to be mandated as opposed to just a security
       considerations.
    JS: Happy with SC doing a recommendation and not a mandate.
    FP: Not necessary that all of the notifications come from observe so may
    not always be here.

  Congestion control needs to be included
    JS: Issue that I had was that observe need to not send notifications more
    than every so often Discussion on what are the conditions that might lead
    to congestion Does this need to get an early TSVR review? What issues need
    to be done. FP: For this document needs to add some type of considerations
    added. CB: Suggested that perhaps Klaus could be a resource to ask on this

   Keeping the same KID
       JS: I think existing text is sufficient to deal with this.

*** Meeting ends as time has expired. ***

- OSCORE -  Marco Tiloca (15 min)
  document:
  https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ slides:
  https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-20200518-ace-key-groupcomm-oscore

- PubSub document has not been updated so is omitted
  document: https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/

As time Permits:

- Admin Interface - draft-tiloca-ace-oscore-gm-admin - Marco Tiloca (10 min)
  document: https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin/
  slides:
  https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-20200518-ace-oscore-gm-admin

- Revoked Access Tokens -  Marco Tiloca (10 min)
  document:
  https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-token-notification/
  slides:
  https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-20200518-ace-revoked-token-notification

- Group OSCORE Profle - Marco Tiloca (15 min)
  document:
  https://datatracker.ietf.org/doc/draft-tiloca-ace-group-oscore-profile/
  slides:
  https://datatracker.ietf.org/meeting/interim-2020-ace-06/materials/slides-interim-2020-ace-06-sessa-20200518-ace-group-oscore-profile