ACE WG IETF 102 Minutes Monday July 16, 2018 0930h-1200h Chairs: Jim Schaad and Roman Danyliw Minute takers: Francesca Palombini Jabber scribe: Benjamin Damm Introduction and WG Status ========================== presenters: Jim Schaad and Roman Danyliw slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-chairs-update The WG chairs introduced the agenda, summarized document status and reviewed recently updated milestones. The WG proposed no changes to these milestones Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) ============================================================ presenter: Mike Jones draft: draft-ietf-ace-cwt-proof-of-possession slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-pop-key-semantics-for-cbor-web-tokens-00 Jones presented a summary of feedback from the WGLC on draft-ietf-ace-cwt-proof-of-possession-03. (Carsten Bormann) comment to think about: idea of COSE was to use JOSE as much as possible, then there was reasons to have deviation, that's why it's different. Main reason is the domain of application (devices). With CWT and CW PoP we still have this need, I don't know how we can solve it, but maybe we want to have more nailed down semantics in CWT and CW PoP. (Mike Jones) great point. Slides do oversimplify. A year ago there were 2 drafts that did the same thing. These 2 drafts were essentially the same, including deleting the 7800, which showed that we were on the right track. (Hannes Tschofenig) use of multiple of keys, initially I was on favor then changed my mind because I didn't have a use case. Maybe if it is a good use case for CWT then it is also for JSON, but did not have one. One item I would like to discuss is the key id topic. Did not see a good conclusion of that in the mailing list. (Mike Jones) about multiple keys, after discussing it we decided to have it in the doc. About the kid we did write a new section describing that if multiple keys in different spaces you will have to be able to look up those keys. (Jim Schaad) Reference by kid is not adequately adressed in the doc. Whole lot of issues are problematic and should be thought through, there is another that I cannot now remember. (Mike Jones) do we also need to discribe other issues or only that issue described better? (Jim Schaad) cconcept of single AS doing all the authorization on all the RS is not correct, several AS that need to cooperate. (Mike Jones) this is far from OAuth (Jim Schaad) yes. the issue is tricking you into giving me the permission I shouldnt have. (Ludwig Seitz) try to explain the problem: get the AS to issue the token. then the attacker get to issue another token with another key, with the same key identifier. Client submits the first token. the attacker can then trick the RS to accept a second key linked to the same key identifier that the RS already knows. (Mike Jones) even if that happens, the key will not be able to be used for PoP. (Ludwig Seitz) yes that's an issue that should be discussed, maybe not in this document? (Hannes Tschofenig) CWT PoP is very limited in functionalities. The described attack scenario should be described in the ACE doc. I don't think it is a concern but implementations can make mistake so it is worth highliting those (Russ) disagree with Hannes. Agree that ACE should describe it there, but a warning in this document should be added here as well. What if someone purposely maliciously does that. Should be discussed in this doc. (Roman Danyliw) I am going to be shepherd. I send mail last Thursday on the remaining issues -- 3 categories: comments not "closed", comments that were not in the doc, comments adressed. Walk through the list to check. (Mike Jones) will do. If people think that aditional things need to be said, please provide text about it, so that we can add that. EST over secure CoAP (EST-coaps) ================================ presenter: Peter van der Stok draft: draft-ietf-ace-coap-est slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-est-over-secure-coap-00 van der Stok presented the background and recent updates for EST-coaps. He noted that there were no comments on: -- Long delay handling (sl 4) -- multipart payload (sl 5) Ideally an interop can be done in the next 3 months (Mohit Sethi) sl. 4 Can you not block this from the server and you will still run in this same problem? or is POST a CON POST? (Peter van der Stok) Yes it is confirmable (Hannes Tschofenig) why did you have to include the multipath part? (Peter van der Stok) First part you get cert request and server sends back content format and (missed it) They both come from the server. (Hannes Tschofenig) original model did not require the multipath. Is it because you are passing the certificate and the key as well. (Server side key generation is the cause of this) (Peter van der Stok) yes (Hannes Tschofenig) I was never in favor of this because of security. Is it mandatory to implement? (Peter van der Stok) yes. Haven't said either mandatory or optional. we might think about that. (Hannes Tschofenig) client req feature and server doesn't provide, it could send an error, I think that would be good. I am still thinking that the argument that provoked this multipath is dubious. (Hannes Tschofenig) Want to use TRNGs on IoT devices (Peter van der Stok) Yes but we also are going to handle old devices. Core Framework and Profiles =========================== presenter: Ludwig Seitz drafts: draft-ietf-ace-oauth-authz, draft-ietf-ace-dtls-authorize, and draft-ietf-ace-oscore-profile slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-ace-authorization-and-authentication-framework-and-profiles-00 Seitz presented an updated to the drafts based on comments and the interop. (Hannes Tschofenig) clarification: presence of CBOR unchanged, but the use of CBOR is (Hannes Tschofenig) follow up on sl 4: we will have a discussion in OAuth wg about this. If anyone is interested, come to that meeting. Discussion points per sl 5: - key identifier (discussed before) - alignment with OAuth: go to meeting on Thursday - All the param currently in the framework are either in OAuth or RFC7800 + profile. Open to discussion which ones of those are unimportant enough for a larger abbreviation: (Carsten Bormann) You can waste a lot of time discussing this. Someone should just write down a proposal (Mike Jones) my suggestion is to work with the designated experts for CWT claim registration and then make a proposal, and get their feedback. Now rather than when this is done Discussion per RD attributes for AS discovery: (Carsten Bormann) how a RS can send the info about how to get the AS. Can define a new relation type to hold this information and what it would look like. (Ludwig Seitz) have this in this draft or in a different draft? (Carsten Bormann) worthwhile independent effort. should be something basic about what a RS does for unauth req (Ludwig Seitz) currently I removed the direct ref to RD. "you are allowed to use other mechanisms" (Peter van der Stok) I agree - keep it an independent document. Question: Are we ready for WGLC? (Jim Schaad, as chair): we need to get an update with all the comments. Let's shoot for september (Carsten Bormann) did we have a version of this for implementation? (Ludwig Seitz) not explicitely (Carsten Bormann) Maybe we should do that for next version (Ludwig Seitz) implementations: one by me, one by Jim, Olaf is working on a constrained impl, Hannes has one (partial C-RS is CoAP but AS interactions are HTTP based), SEI lab has an unconstrained version on my code and a constrained version in developement, one from RISE for Contiki. We want to do more interop (Roman Danyliw) September we will start the WGLC (after update) Group Communication =================== Key Provisioning for Group Communication ---------------------------------------- presenter: Francesca Palombini drafts: draft-palombini-ace-key-groupcomm : draft-palombini-ace-coap-pubsub-profile slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-group-key-provisioning-00 Palombini provided an update on the key provisioning and pub-sub drafts. -- Major update: Retrieval of updated keying material. -- Open Issues: 3 choices, Issue of how to combine a request for the public keys of others with a request for an update of the simmetric key. (Jim Schaad) Pefer not to use the different resources and do it in a message. Need to think about this for how to do as resources. (Peter van der Stok) Why are there two drafts on group communication rather than a single draft. (Roman Danyliw) Initial request from the group was to separate the model from the details of how to do in a specific profile (Roman Danyliw) Can make some decisions if the WG decides to adopt them. (Chairs) Want to get the Oauth-Authz document published before pulling in new work. Joining OSCORE groups --------------------- presenter: Marco Tiloca draft: draft-tiloca-ace-oscoap-joining slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-ace-joining-00 Tiloca presented an update on the draft-tiloca-ace-oscoap-joining draft. (Peter van der Stok) Want to express the interest in this draft and hope it goes on smoothly (Roman Danyliw) WG will defer adoption after the framework is done, same as the drafts Francesca presented Resource Directory Authorization Issues ======================================= presenter #1: Peter van der Stok and Carsten Bormann) slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-resource-directory-authorization-issues-00 : https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-resource-directory-permissions-part-2-00 van der Stok and Bormann presented the motivation for discussing resource directory authorization to stimulate discussion in the WG. The chairs framed the discussion in slide #7 of their intro materials. (Jonhatan Hammel) for cert id to align with CMS, you would use issuer and serial number (Mohit Sethi) Way too complex for a problem we have seen in many places. Encourage using something completely random. What requirements you have on the endpoint name, human readable? I think this is way too complex (Hannes Tschofenig) similar problem seen before: identifier at 2 different layers: (D)TLS and CoAP RD. The problem was at higher layer you have a non authenticated (the CoAP). My proposal was getting rid of that. Your solution is binding those, which is possible, as long as you make sure that they are the same, then it's not a problem. But then why do you have to send the same thing twice? (Matthias ) I agree with Hannes. Question: one way which is Ace related, but there are other ways right? (Peter van der Stok) I am not aware (Matthias ) we need authorization for RD, that is clear, and your way uses ACE, but there are other ways. (Hannes Tschofenig) another issue: 3rd party registration. In my opinion it doesn't work exactly as you describe it. Security story is harder here. Need to be able to do multiple registerations in a single security session. (Hannes Tschofenig) interesting. I think you are shoveling the problem around. Discussion is "do we need this endpoint name" the answer cannot be "there are all these things that we can talk about instead" Yes there are also sorts of complicated problems, some of which are unsolvable. But if we can just solve the simpler "what is the semantic of the endpoint name". I fear that if I pick up Leshan, I will get that server to trick me (...) (Carsten Bormann) problem is that if we only solve that problem the people are going to start to encoding other things with that. Not a good thing (Jim Schaad) CWT expand the scope to be a binary value. There is a potential problem that we don't have standardized way to structure data. I am trying to figure out 1) Are we asking the group to solve a particular problem with RD or are we trying to solve the more general problem? in the latter case I have an issue trying to understand what the general problem is from Peter's presentation Can you tell me what the general problem should be? (Kerry ) the following: DNS. Things come out of the box, and we need to give them to the clients and we need to be (...) (Roman Danyliw) one sentence? (Kerry ) No human in the loop. (Ari ) if protect endpoint or semantics, I think we should protect both. I think we have a problem to solve right now with EP ID, but I think we need to then continue. I like the idea to have a way to protect RD semantics, but it shouldn't be the only way. (Carsten Bormann) initial assumption AS and RD so that all of this can be done behind the scene. Now we are trying to see how. (Kerry ) questions: 1) should protecting the information (from RD to AS) also extends to the client itself when you ask the client what it supports? 2) sign collection of links that come back? (Carsten Bormann) maybe we need to be careful on preserving ways of using RD. 2) we have to protect shared resource. Slightly different objectives. (Jim Schaad) another problem: when you ask a RD it will return bits and pieces in different places. (Carsten Bormann) Maybe we want to change that. Bring back to the wg (Hannes Tschofenig) I don't think scope is the right thing to use. More about the client information. It should go into a different structure. (Carsten Bormann) scope pertains to the client (Hannes Tschofenig) yes but CWT scope has a different semantics (Padhu ) (...) if we are able to achieve the context between endpoint and RD, that context remains constant. (Carsten Bormann) Are you saying We need to be able to have a local id? (Padhu ) Yes (Matthias ) Got confused so I'd like to summarize the problem. With PoP tokens, a client can prove a certain claim is true. AS can grant authorization to an RD, but it is up to the client to prove that the client can use this endpoint name. The AS has no say or even knowledge about the endpoint name claim. There must be something like a cert saying the client is allowed to use a certain endpoint name. My point is to separate this: AS allow the client to reg to the RD, but it is not the AS that proves endpoint name is true. (Carsten Bormann) so second issue (Matthias ) Yes this is more complex to dynmically attest an endpoint name. We need to start with a simple solution that solves the two problems at hand: getting authorized to register with an RD (ACE can help here) and proving the registered information is true. Let's not entangle these two different issues. (Carsten Bormann) useful observation (Matthias ) start with something simple: client has a key that proves the information being registered -- in particular the endpoint name -- is true, so that you don't need Ace. So go back to simple proposal such as certs by Hannes. Second part is to use ACE to get authorized to register with a third-party RD. And 3rd part for the future is to look into dynamic attestation that registered information is true. (Jim Schaad) one topic which has impact and we have not discussed: groups (Carsten Bormann) 2 parts: 3rd party control who is member of a group and member (Dave Thaler) similar to what Matthias said. outside of IETF. (Hannes Tschofenig) discussion about this later today as a bar bof 6pm This is the EAT BOF (Kerry ) Separating the accuracy of info and the auth info that goes into the RD: do you want to limit the RD (Carsten Bormann) This is about integrity not privacy (Michael Koster) We have been doing some discussions about allowing things to be registered in the RD which would not be part of .well-known/core. This may be something that needs to be discussed. (Ben Kaduk, as AD) Thanks for having this discussion. (Roman Danyliw) In summary, the feedback is that the WG needs to consider group communication, but any approach should "keep it simple." See slide #8 of chairs's slides. EDHOC ===== presenter: Göran Selander draft: draft-selander-ace-cose-ecdhe-09 slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-edhoc-00 Selander presented an updated on the revisions to EDHOC in the -09 draft. Closing ======= discussion lead: chairs The WG chairs summarized discussion as follows: ** draft-ietf-ace-cwt-proof-of-possession -- authors should respond to outstanding issues posted by Document Shepherd on ML (07/12/2018) ** draft-ietf-ace-oauth-authz -- publish revised draft to address feedback; WGLC in September 2018 ** Group Communication Individual Drafts -- continue work; deferring WG adoption discussion until framework documents progress ** Resource Directory Authorization Discussion -- more discussion required on problem and solution