Minutes interim-2020-ace-06: Mon 10:00
Authentication and Authorization for Constrained Environments
||Minutes interim-2020-ace-06: Mon 10:00
DATE: 2020-05-18 ACE WG virtual interim meeting 06
WEB EX: https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee
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
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
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
- MQTT document is intentionally not on the schedule.
Group Keying Documents
- Framework - Francesca Palombini
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
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
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)
- PubSub document has not been updated so is omitted
As time Permits:
- Admin Interface - draft-tiloca-ace-oscore-gm-admin - Marco Tiloca (10 min)
- Revoked Access Tokens - Marco Tiloca (10 min)
- Group OSCORE Profle - Marco Tiloca (15 min)