ACE WG Interim Meeting - Monday 2020-06-22 14:00 UTC
Remote instructions:
WEBEX: https://ietf.webex.com/ietf/j.php?MTID=mf10e2f04280cf225c5d2374973df48b5
JABBER: ace@jabber.ietf.org
Etherpad: https://codimd.ietf.org/ace-interim-20-06-21#
- You currently need a datatracker account to edit. If this is a problem let me know and I will change the permissions.
AGENDA
Administrative
AD held documents
- draft-ietf-ace-dtls-authorize-10
- draft-ietf-ace-oauth-authz-33
- draft-ietf-ace-oauth-params-13
- draft-ietf-ace-oscore-profile-10
BK: Framework & params are done. Waiting for the other two documents to send up to the IESG
OSCORE profile almost done
FP: Just submitted a new verion. All comments except for text about size of nonces.
BK: That matches my notes. Did change the procedure for access of update rights.
May want to run a new IETF last call on that.
Have not yet looked at the DTLS profile, but it is believed to address all of my comments.
FP: For the ace framework, did look at the email thread on default values for auth-info
Not sure I understand what the issue is
LS: I looked at OAuth and have confirmed that they did not register any endpoints
We should be trying to mirror what OAuth does.
BK: I remember that OAuth has a discovery document to get that information.
Don’t remember that ACE has a discovery document.
If have a default value and no discovery then there is no way without hard coding in client/server then a problem ensues.
Names and path on server should belong to the server
CB: In CoAP we have a discovery mechanism - Resource Directory and /.well-known/core where the node can say something about the resoures.
LS: Haven’t got the compentence and time to do this.
FP: We registered a interface link attribute value for ACE.
Saw that CB suggested registering rt values instead.
CB: Did not have clear idea in 2012 about the rt and if attributes.
rt says over all purpose
if says has some behavior
Should have a single resource type and can have multiple interfaces
FP: Sounds like rt would be the right type for framework to register.
DM: Should we have a discovery document?
LS: Ask for a separte document to solve. Very short on time.
BK: Could just do in response to IESG comments and don’t typically do a LC for that.
DM: will this open new discussion issues
CB: This is something that the framework or profiles will define?
LS: Won’t use the same discovery for MQTT as for CoAP. May need to push to profiles.
BK: If define the new rt for … What are the things that need to be discovered.
CB: Need a resource type for endpoint, maybe some interfaces as well.
Different kind of endpoints should be findable - really should call entry points.
Really should do in profiles, even if the results are very similar.
JS: Currently get the AS from the RS in the AS info. Just need to discover the authz info point
BK: Just talk about the authz-info point
CB: If they are the same then do it in the framework.
LS: That would be specific to coap. Have had voices to find this
CB: Framework defines rt for CoAP transport profiles.
LS: Don’t know where to start
CB: Can send text. Bikeshed issue what is the name of it.
MT: All current items i think start with “ace.”
CB: MT and I can bikeshed the name off line and send to list.
BK: Sounds like we have a plan.
Marco’s non WG documents
-
Admin Interface - Marco Tiloca (timemark 0:25)
document: https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin/
slides: https://datatracker.ietf.org/meeting/interim-2020-ace-07/materials/slides-interim-2020-ace-07-sessa-20200622-ace-oscore-gm-admin.pdf
DM: What type of issues the document is raising?
What are things that might need discussions.
MT: JS had provided some reviews of CoRAL that might have additional ways to make some design choices.
DM: QUestion about adoption call
JS: No objects to doing it sooner rather than later
CB: In some deployment GM might know from application state which groups to create and not
provide the admin interface.
MT: Yes if it knows everything to start with - then no interface needed
CB: That would be important information to provide.
CB: If application is creating and removing groups from the application state, then that
can control the KDC instead.
MT: Really for external administrator
CB: Yes - or application interface for doing it.
-
Revoked Access Tokens - Marco Tiloca (timemark 0:38)
document: https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-token-notification/
slides: https://datatracker.ietf.org/meeting/interim-2020-ace-07/materials/slides-interim-2020-ace-07-sessa-20200622-ace-revoked-token-notification
BK: With the diff update, does seem to be useful but not sure that the last n changes is the most effective way to do this.
Reminded the JMAP protocol give a name to the state on a resource returns the state and can ask for changes since that state.
Also has a way for the server to return only a portion and returns an indicator that more exist
Server may say that state has been lost and client needs to do a full fetch
BK: Issue with what hash function is going to be used for this.
MT: Having the hash function put in the registration response.
MT: On the first point - a third mode oriented to snap shots.
BK: Possibly - just reviewed the JMAP as the iesg so don’t know the background
CB: Look at the series transfer pattern draft draft-bormann-t2trg-stp
See if this covers what is needed and if necessary to expand that draft to cover it.
BK: Cannot think of a reason that anything other than the latest version - no historic state.
Working Group Documents
- MQTT document (WGL ready version expected) (timemark 0:53)
document: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
CS: Updated a version 5 and JS has sent a review on it.
Not major technicals issues outstanding.
Some issues on coverging the session state kept by the broker.
Also the scope format.
Scope in the profile limits the versions and allows for a topic filter to be used.
Not currently setup in aif document.
DM: are you blocked on this.
CS: For the scope question yes, just a recommendation there to have some format there.
FP: Also have some discussion in the groupcomm document as well. Having some problesm with it.
CS: Can understand new keywords can be added.
JS: Worried that passing the binary version in the text field could be an issue.
CB: That would be what base64 is for.
DM: Should we be continuing with this new format.
FP: Can we take the scope discussion to my slides?
CS: Questioning about saved state. Need to flesh this out with Jim on reuse of the token vs a new token being used.
CS: Question of what happens on a re-connect and if the token is part of the state then tied to the old token - have an issue
suggested that it should be MAY rather than MUST just the client coming back
MQTT only recognises client by client id and this would be the same behavior.
Don’t think there would be a new security issue because permissions would be enforced on this.
DM: Need to spend more time on this but don’t see interopability problems.
JS: I need to try and build my attack case better. Might be ok.
CS: Could say continuing clients need to do a connect w/ old token and then immediately re-authenticated with the fresh token.
Will be the issue in github to look at.
FP: Sounds related to update of access rights in last meeting.
In oscore profile old token should not necessarily derive a new security association.
CS: Old token is just an ID proof for the session.
Group Keying Documents
-
Framework - Francesca Palombini (timemark 1:09)
document: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
slides: https://datatracker.ietf.org/meeting/interim-2020-ace-07/materials/slides-interim-2020-ace-07-sessa-ace-key-groupcomm-interim-0622.pdf
(slide 6)
JS: I do think that AIF needs some changes - hence my review.
JS: I think that the metheods need to be able have strings as well
I think that the resource name can be any string that is acceptable to the the AS and RS.
FP: Trying to make a question about the gid that I don’t understand
CB: Need to make sure tht the mapping of name to group id is done in a secure fashion.
Names of things are not always URI paths.
Need to do this to make AIF more useful in a nubmer of cases.
JS: SHould only put the group name in the AIF rather than the resource because the gorup ID might be changed by the KDC.
MT: Currently says gid, but really should be a group name
FP: THen instead of having the equivalence with the AIF then the structure should become the same.
MT: Only roles are talking about what can be done with the group members rather than the RS.
FP: So AIF would needs some large changes - as it is currently defined does not cover this case
CB: Really interesting - two aspects defining an overall structure which is simple and defining the elements of the structure.
The elements don’t fit with this. What about the overall structure?
FP: No the overall structure seems to be useful.
CB: Might be worth makeing the AIF document in two parts with that distinction.
DM: On the MQTT - wondering if not trying to make things harder for there.
JS: Reducing the number of ways that the AS needs to parse the scope is a big win
CB: Interesting question if wild cards in a constrained evn makes sense.
CS: Would it be possible to make the profile define new verbs as well.
CB: I think that is the direction to go – yes.
(slide 7)
Need native speaker review on channel text if not clear between management and data.
DM: Anybody else willing to review?
-
Group OSCORE - Marco Tiloca (timemark 1:35)
document:
https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/
slides: https://datatracker.ietf.org/meeting/interim-2020-ace-07/materials/slides-interim-2020-ace-07-sessa-20200622-ace-key-groupcomm-oscore.pdf
JS: I don’t understand why you care about this.
MT: Want to defer this as long as possible so that needs to be able to do things later.
DM: Allows the client to ask for a lower level of permissions at the join time.
MT: Yes - allows for fewer token requets to be done.
JS: I would like to see some interop testing before WGLC is done.
CLOSE THE MEETING at this point.
-
PubSub ( if document is being updated )
document: https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/
As time permits:
PARTICIPANTS
- Jim Schaad, August Cellars
- Daniel Migault, Ericsson
- Russ Housley, Vigil Security LLC
- Marco Tiloca, RISE
- Francesca Palombini, Ericsson
- Cigdem Sengul, Brunel University
- Rikard Höglund, RISE
- Olaf Bergmann, Uni Bremen TZI
- Mike StJohns, NthPermutation Sec LLC
- Michael Richardson, Sandelman Software Works
- Sebastian Echeverria
- Ben Kaduk, Akamai
- Casten Bormann
- Ludwig Seitz