ACE WG Minutes IETF 103 Thursday, November 8, 2018 16:10-18:10, Afternoon session II Minutes taker: Ivaylo Petrov Introduction and Status Update ============================== presenters: Jim Schaad and Roman Danyliw slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-chairs-summary-04 The chairs presented the status of the WG -- recent WGLCs (draft-ietf-ace-oscore-profile, draft-ietf-ace-authz, draft-ietf-dtl-authorize and draft-ietf-ace-oauth-params); and drafts in shepherd review (draft-ietf-ace-cwt-proof-of-possession). ACE-OAuth ========= presenter: Ludwig Seitz draft: draft-ietf-ace-oauth-authz slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-ace-oauth-and-additional-oauth-parameters-for-ace-01 Ludwig Seitz presented changes made to the framework draft from the -13 to -17 revisions and led a discussion on open issues. Per Slide #3, Discussion Point #1: Use of low-digit abbreviation -- no feedback from the WG Per Slide #3, Discussion Point #2: Unified registry of CBOR abbreviations Comment: Mike Jones (Microsoft): I believe that has been discussed in the list and there should be separate numeric spaces for claims and parameters. Comment: Jim Schaad: The RATS BoF also discussed registering CWT claims. We would benefit from a common story. Likely we should register maps then everyone could get their own registry. Q: Carsten Bormann: How many media types you have? -A: Ludwig Seitz: There is one media type defined. -A: Carsten Bormann: How do I know its CWT then? -A: Ludwig Seitz: It is sent as a parameter in the message. -A: Carsten Bormann: The important thing is that the thing claim received should be formed as a CWT Per Slide #3, Discussion Point #3: CWT as format for signed protocol messages Comment: Ben Kaduk: Thinking about as CWT as signed claim messages, the ACME just started using JWTs for all signed messages. Comment: Mike Jones: As discussed on the list, use of JWTs as signed protocol messages is being standardized by OpenID Connect and the OAuth WG. Given that ACE is trying to reused as much of OAuth as possible, it makes sense to use CWT as signed messages. -A: Ludwig Seitz: Isn't there contention in the OAuth WG about whether all messages should be JWTs. Isn't it only for introspection purposes? -A: Mike Jones: The OAuth draft is strictly scoped to the authorization and responses. OAuth isn't doing it for introspection at present. -A: Ludwig Seitz: My concern is aligning with OAuth could delay publication of the ACE framework. -A: Mike Jones: You are not going to introduce a normative reference. It would be a non-normative reference. -A: Jim Schaad: I don't think we even need the informational reference, unless we want to document that we are going to carry those messages in the framework -A: Ludwig Seitz: Do you expect that this would be an additional draft that describes the CWT representation? -A: Jim Schaad: Right. Per Slide #3, Discussion Point #4: Alignment with OAuth Comment: Hannes Tschofenig: We try to be more specific in the resource identifier it makes the implementation simpler on the resource server because there is a standardized way to do the comparison. Otherwise you have to have out-of-band communication in order to describe the semantics. The current approach makes the comparison more precise. Do you have a use case that needs a more relaxed description? -A: Ludwig Seitz: No, I don't have such a use cases. The challenge I was addressing is that the URLs of constrained devices change when they travel (move from one network to another). It makes it tricky to use this resource identifier. -A: Hannes Tschofenig: I see. Good question. -A: Ludwig Seitz: Let's continue this discussion on the mailing list Q: Jim Schaad: Is the confirmation text well aligned? -A: Ludwig Seitz: It is. Per Slide #4, Discussion Point #5: Multiple tokens for one RS and client How should the RS handle it? Option #1: New token amends; Option #2: New token overwrites. Comment: Ludwig Seitz: the draft currently implies Option #1, but Option #2 would be simpler. Would anyone have strong feelings with Option #2? -A: Jim Schaad: I don't have a strong feeling, but there are two things I want to raise. Many times the newer tokens is for a shorter-lifetime, so it might be expired sooner. I know there is a draft in oauth WG for incremental updates. -A: Ludwig Seitz: We should take a look at that. Comment: Olaf: +1 for option 2. Per Slide #4, Discussion Point #6: Expiration of tokens based on sequence numbers for devices with no internal clock Comment: Ludwig Seitz: Not very secure and as it is not probable. This mechanism seems obsolete and I would recommend to remove that. Any opposition? -- No concerns raised. Per Slide #4, Discussion Point #7: Symmetric cnf keys and multi RS audiences Comment: Ludwig Seitz: Might lead to impersonating. Should we recommend against using symmetric cnf keys in multi resource servers? -A: Jim Schaad: Recommend the text recommend SHOULD NOT and wait for use cases to think against about it. -A: Ben Kaduk: I would be pretty uncomfortable to allow, so we'd need a good use case to proceed. -A: Ludwig Seitz: Is SHOULD NOT strong enough? -A: Roman Danyliw: Perhaps MUST NOT or NOT RECOMMENDED? -A: Ben Kaduk: It would depend on the rest of the text. -A: Ludwig Seitz: Let's go to the ML for further discussion. NEXT STEPS: (Jim Schaad): When could the next version of the draft be published? -A: Second-half of December 2018 DTLS Profile for ACE ==================== presenter: Göran Selander draft: draft-ietf-ace-dtls-authorize slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-dtls-profile-for-ace-00 Göran Selander presented updated made in the -05 version of the DTLS profile draft and led a discussion around WGLC feedback. Per Slide #3 (WGLC #1) Q: Hannes Tschofenig: Is the client supposed to send the key ID to the AS or the other way around? -A: Göran Selander: It is the AS -A: Hannes Tschofenig: But the AS can provide that key ID already. -A: Göran Selander: This was missing in the text -A: Jim Schaad: This issue has been overtaken by events, we should use refresh tokens without using the key ID. -A: Göran Selander: Do we need a special case for RPKs. It's the same, so no Per Slide #4 (WGLC #2) Comment: Göran Selander: I'm not sure if I understand the question in this WGLC feedback -A: Hannes Tschofenig: JWT answer to this is to include an algorithm id. -A: Göran Selander: That is easy to address. Per Slide #5 (WGLC #3) -- No feedback Per Slide #6 (WGLC #4) Q: Jim Schaad: I don't remember this proposal being in the reviewed drafts and don't know what it does. -A: Göran Selander: It transport the salt. Use the key shared between AS and RS to derive the key. -A: Hannes Tschofenig: Is this a good idea? You are adding another key derivation approach that needs to be implemented? It would be good if the JWT and CWT functionality matches. -A: Göran Selander: Yes this approach is typical for 6tish where a CWT doesn't fit in one segment. It's the constrained use case. -A: Ludwig Seitz: It also has the advantage that an attacker who learns the content of the cnf claim can not derive the key. -A: Hannes Tschofenig: There is an assumption of confidentiality between the client and AS already. -A: Göran Selander: This would be encrypted and this wouldn't only have to be integrity protected. -A: Jim Schaad: Yes, it which will already be encrypted. I am worried about possible problems with the keys being protected correctly. You are adding a key derivation on a secret that was meant to do something to do something else. -A: Göran Selander: Agreed. The intention was to use a derived key. I'll check if it is written in the draft. Q: Göran Selander: The question is how would the cnf look like (not whether the method should be used). -A: Hannes Tschofenig: From the JSON version/JWE, there is an unencrypted version or not. Do you want an encrypted and not encrypted version? -A: Göran Selander: No, not encrypted, but it could be. -A: Hannes Tschofenig: Is it a key container or a JWE. But then you'd need a wrapper. -A: Göran Selander: It used to have that in the COSE key container. We realized it is not a good idea. -A: Jim Schaad: You are missing a layer in your example. -A: Göran Selander: Yes, reading your review you made that clear. NEXT STEPS: (Roman Danyliw): When could the next version of the draft be published? -A: December 2018 OSCORE Profile for ACE ====================== presenter: Francesca Palombini draft: draft-ietf-ace-oscore-profile slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-oscore-profile-of-ace-02 Francesca Palombini summarized changes to the OSCORE profile draft made in -05 and led a discussion around WGLC and related open issues. Per Slide #3: Q: Francesca Palombini: Are there more situation where the client or the server needs to discard their security context? -- none heard -A: Francesca Palombini: If you have ideas, please send them to the mailing list Per Slide #4: Q: Francesca Palombini: IANA registry creation with Expert Review Required for parameter registration. Is there feedback? -- none heard Per Slide #5-16, the client and the RS can forget the sec ctx and they might forget the tokens. The client can get an old, non-expired token from AS. There might be place for an replay attack if the RS loses it's security ctx. To solve this, we add a nonce from the RS to the client. The usage of nonce is now mandatory. There are three options. Option #3 is preferred but requires a change to the ACE framework (instead of just the payload, send a map). Comment: Ludwig Seitz: Like proposal 3. We need to define a new content type for sending CWTs directly (ACE+CWT). Profiles that use auth end point can use this new content type. -A: Francesca Palombini: However, in the ACE framework, the content format ACE+CBOR is only defined for client-to-AS and vice versa, but not client-to-resource server. -A: Ludwig Seitz: That is an oversight. I will create an issue. -A: Ben Kaduk: In terms of cryptographic usage, proposal 3 is the best. Comment: Carsten Bormann: I am confused as to what just got said about media types. There is CWT media type. What do you want to define? "+CWT" doesn't exist. -A: Francesca Palombini: I said I want to define ACE+CBOR to send a CBOR map (of a nonce and CWT). Ludwig said he will update the framework for ACE+CWT to sent just a CWT. -A: Carsten Bormann: Let's take that offline. Comment: Mike Jones: In the secevent WG, they just finished the security token draft which was the first to use a +JWT media suffix (secevent+jwt). Hence, it wouldn't be unheard of for such a draft to introduce such media type and you can copy the text from the secevents draft. -A: Francesca Palombini: Understood. This still seems related to the previous conversation with Ludwig and Carsten on media format. Comment: Francesca Palombini: I heard people like option 3, which is great. Per Slide #17: Q: Jim Schaad: Is there a problem with using a content type with a created response? -A: Francesca Palombini: No. -A: Ludwig Seitz: I don't see a problem with that. -A: Carsten Bormann: I also don’t see a problem. As long as the media types doesn't start to mean something different. Q: Francesca Palombini: Nonce is only registered for AS-to-client response. Can it be made more general? -A: ?: Yes. NEXT STEPS: (Roman Danyliw): When could the next version of the draft be published? -A: Early December 2018 PoP Key Semantics for CWTs ========================== presenter: Mike Jones draft: draft-ietf-ace-cwt-proof-of-possession slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-pop-key-semantics-for-cwts-00 Mike Jones presented changes made to the PoP draft based on WGLC feedback and identified the outstanding issue. NEXT STEPS: (Chairs): When could the next version of the draft be published? -A: in the next few days EST over secure CoAP ==================== presenter: Michael Richardson draft: draft-ietf-ace-coap-est slides: https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-est-over-secure-coap-draft-ietf-ace-coap-est-00 Michael Richardson presented updates made in the -06 of the EST over secure CoAP draft, and feedback from multi-party interop testing. Q: Michael Richardson: this draft has applications in particular vertical use cases. There is concern that this draft won't survive IESG review without more text on why this approach is secure. However, detailing the use cases may be a rat hole. -A: Hannes Tschofenig: Our use cases is for device management for IoT. -A: Michael Richardson: Do you think we should include this use case in the draft. -A: Hannes Tschofenig: We are open about this use case. This use case horizontal across many vendors. -A: Michael Richardson: Between vendor and customers; not "internet level" interoperable - having different manufacturers, customers, etc. -A: Hannes Tschofenig: We provision at device manufacturing Comment: Jim Schaad: EST is secure by TLS. -A: Michael Richardson: Yes. -A: Jim Schaad: You aren't talking about securing in the channel but how you get trust in the channel -A: Michael Richardson: Correct. -A: Jim Schaad: No, I don't think we need to add text. -A: Christen: You could describe in certain details how a person buys a widget and how it is registered. The concern with this use case is likely if that person wants to reset that device and then how the manufacturer would support it. -A: Michael Richardson: This protocol has none of that. There is no magic, only a static list of clients and servers. -A: Christen?: ? -A: Hannes Tschofenig: I don't worry about future IESG comments on that. (Roman Danyliw) Does anyone disagrees that this draft is ready for WGLC? -A: Peter van der Stok: Has edits to make. NEXT STEPS: (Roman Danyliw): When could the next version of the draft be published? and the basis of a WGLC? -A: Early December 2018 New Work Adoption ================= The chairs engaged the WG to under the level of interest in adopting three draft related to group communication. Adoption on these drafts has been deferred in recent meetings pending progression of the early documents to WGLC. For each draft three questions were asked: ** (as a hum) Is it worthwhile to do -- adoption? should not do? don't know? ** Would you want to review it? ** Would you want to implement it? Comment: Francesca Palombini: Before we discuss the second draft, as an author, I want to make it clear that it hasn't been updated recently or prioritized. It was also delayed due to work in CORE. -A: Roman Danyliw: Are you recommending we don't call for adoption? -A: Francesca Palombini: Your decision. draft-palombini-ace-key-groupcomm --------------------------------- ** adoption hum: considerable humming for adoption, some for not knowing. ** reviewers: ~6 ** implementers: ~3 draft-palombini-ace-coap-pubsub-profile --------------------------------------- Comment: Carsten Bormann: This is a comment on group communication. I'm not sure if CORE not making progress should prevent us from moving forward. ** adoption hum: loudest on "no idea" ** reviewers: ~4 ** implementers: none Comment: Jim Schaad: Most people seem to have no idea. Would anyone who hummed no idea want to explain what they would need to make a decision? -A: Göran Selander: This is important work. However, it hasn't been prioritized. Let's visit at a later meeting. draft-tiloca-ace-oscoap-joining ------------------------------- ** adoption hum: hums heard in favor of adoption and don't know ** reviewers: ~5 ** implementers: ~2-3 Open Mic ======== Comment: Ari Keraenen: I understand that pubsub is of lower priority. However, it is planned to be finished, so it will be a pity if the work is abandoned. -A: Jim Schaad: I have been hearing this for quite some time. I would like a substantial updates. -A: Ari Keraenen: There is a substantial progress and implementation. I hope we will be able to push it through the final line soon. Q: Ludwig: There was prior discussion (and a draft) on ACE with MQTT? Is there interest? My impression is MQTT is commonly used. -A: Jim Schaad: My understanding from the authors of that draft was that they weren't ready to take it to a WG yet. Comment: Hannes Tschofenig: It would be nice to see more productions implementations of ACE. What I see is prototype implementations. It is one thing to push through documents quickly (or relatively quickly). -A: Carsten Bormann: If I had the money to invest in a product, would I implement it and hope that in 2-3 years the IESG will accept it? We are damaging the reputation of being able to push things through. Pubsub is just an example application, but there are other examples as well, which would benefit from standardized solutions. Maybe this has been represented differently from how it is going to be used. I am not sure it will only be used in pubsub. -A: Zach Shelby: I disagree with Carsten. We should build real application for real people and get that experience. We don't need a completed drafts for implementations. I see feature creep in IoT drafts -- more at every meeting. -A: Hannes Tschofenig: We have been deploying CoAP over TCP for some time before it was finished. We had some problems with different versions, but it is possible. -A: Carsten Bormann: I agree there is a problem with the deploy-ability of the ACE stack. We now have something that might be workable. I am not sure having a product is requirement for having a standard. We are working with other SDOs that are looking to the IETF for building blocks. Only some may be successful. Are we interested in implementing shouldn't be the gating function. -A: Zach Shelby: I want to see implementations (not necessarily products) that are deployed. It has nothing to do with ARM, Ericson, etc. Other SDOs should be kept to the same standard - there is also feature creep there as well. This is not only ACE thing, but more IoT level problem. Comment: Göran Selander: The group communication is not a feature creep. People are asking for it - when can we have this? I don't see a problem here. -A: Gunter: That is why OCF is talking regularly to T2T. -A: Göran Selander: I don't see problem with people implementing things in advance or after the protocol is specified. -A: Hannes Tschofenig: On group communication, we have been working on and will release the code. The draft was unfortunately shutdown by Mike St. Jones because of not liking the symmetric keys. Comment: Hannes Tschofenig: In LWM2M we have published version 1. We will have a plug-fest interop event - even non-members can come. We have been using things from the CORE WG. -A: Carsten Bormann: Where and when? -A: Hannes Tschofenig: I think in April next year in Amsterdam or ... - I can send an email to the ML. Comment: Carsten Bormann: Maybe in Prague we can have more than 2 days for plugtests as 2 days are not enough. We could for example start on Wednesday or something. Q: Francesca Palombini: When do you think we can have the decisions on those works? A: Chairs: We will take things to the ML, so maybe a couple of weeks. Closing and Summary =================== The discussed documents will be updated per the following schedule: ** draft-ietf-ace-oauth-authz: Second-half of December 2018 ** draft-ietf-ace-dtls-authorize: December 2018 ** draft-ietf-ace-oscore-profile: Early December 2018 ** draft-ietf-ace-cwt-proof-of-possession: in the next few days ** draft-ietf-ace-coap-est: Early December 2018 (and then WGLC)