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