Wednesday, 20 July, 2016, 10:00 - 12:30 Chairs: Kepeng Li, Hannes Tschofenig Minute Takers: Robin Wilton , Renzo, Francesca Palombini Jabber scribe: Renzo * Welcome and Status Update (Chairs, 15 min) 10h02 Start (10h03 Hannes Arrives :P) Hannes: Resume Trier univ about OAuth Workshop ACTION: Hannes will circulate notes from the developer sessions (challenges encountered, lessons learned, etc.) * Actors (Carsten, 15 min) - http://datatracker.ietf.org/doc/draft-ietf-ace-actors/ Goal: Determine what needs to be done to finalize the document. MILESTONE: Carsten Bormann: still has a couple of bits of feedback to process, on the Actors draft, but otherwise is close to being ready with it. * Authorization using OAuth 2.0 (Ludwig, 45 min) - https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Goal: Discuss and resolve open issues. 10h10 Start - major restructuring - list of updates for this version: * separation between framework and profiles * Defines the endpoints (different from OAuth: the AS informs the client of what profile to use)(OAuth/CoAP endpoints mixed in the document, need to resolved) * pop key distribution added + 10h20 Hannes: request to expand on OAuth bearer Token vs PoP Token. Assumption: How to protect the Key associated to the PoP token, the same stands for protecting a bearer token (when you got it the first time). In the long run PoP offers better security, but needs to be expanded on the document, we need to think about it. ACTION: Status of draft-ietf-oauth-pop-key-distribution will be discussed during the oauth session later today (20 Jul 2016) * key confirmation (different from pop token draft) * client tokens new. More reviews would be appreciated. + Renzo: Think this is useful. This use case/scenario should be taken care of. not sure if this is the ideal solution, but we should look into it. + Hannes: does this correspond to any of the use cases in the use cases document? this is different from OAuth, would require more security analysis. + Göran: motivated by the offline scenario. Analogous to what you do on the client side. Open for discussion. + Ludwig: please send us comments. * IANA section has grown * Deployment Scenarios section Request from Ludwig: please review the IANA section carefully (it's easy to incorporate errors unintentionally); Appendix and Deployment Scenarios are still "work in progress", so by all means review the text, but bear in mind that the details are still subject to change. - next steps + Kepeng: what is the difference with the DICE profile? + Hannes: DICE profile talks about how to use TLS/DTLS whereas the profile here talks about the use of OAuth. + Mike: Security question about the Client token idea; need to ensure that keys are distributed over a channel that is separate, or separately secured, from the messages they are used to protect + Ludwig: we assume client and AS share a long term secret that is used to validate the communication between those.(Ludwig's assumption is that this shared secret is established when the client device is enrolled) + Göran: token end-to-end protected between Client and AS via RS. As Hannes say, we need more security analysis. + Carsten: useful to discuss these requirements, even if we don't at the same time try to bind them to a specific mechanism for token exchange. It is valid to assume that client-to-AS traffic might use different mechanisms from those used for RS-to-AS traffic. +Hannes: this is similar to AAA (EAP, Radius) scenario. Do we want to spend time on this? Is this something people still find useful? +Goeran +Ludwig: at the beginning C does not know to wich RS it will talk. +Carsten: at one level there are similarities between this exchange and the mechanisms used in e.g. EAP, but the underlying assumptions are *not* identical... +Hannes: one area of remaining "fuzziness", when trying to compare the two, is that the EAP documentation does not yet describe how to handle proof-of-possession tokens. + Göran: comment to CoAP-DTLS profile: different ways to transport the access token using DTLS. One proposal was DCAF. + Hannes: How is the token conveyed from the C to RS, so it is different from DTLS/TLS in IoT Conclusion by Hannes: There is progress but there are also various open issues. Is September still a valid milestone date? Seems as though it would not leave much time for implementation work on top of the document work itself. Anyone can review the document in the next couple of months? Mike Jones, Tony Nadalin, Robin Wilton, John Bradley * CBOR Web Token (Mike, 15 mins) - https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ Goal: Resolve open issues. - status of the document - next steps +Ludwig: would it be possible to add a scope claim in the document? +Mike: this document is supposed to be the exact equivalent of JWT, where there is no scope. Other documents could define the scope claim. It doesn't have to be in the core document. +Ludwig: fine with that. +Justin: Shouldn't this document define the claims that are in the registry, not in the RFC?That is, start the new registry with the content of the JWT registry +Mike: we said we would match exactly the JWT document +Hannes: it makes sense to go through the registry and check if we see claims we would like to add +Justin on jabber: (+1 agree with Hannes "cnf" in particular. putting it in a secondary document doesn't make sense to me) +Brian Campbell: It makes sense to capture all the claims we find useful.[And I believe Brian said the JWT spec includes a "Scope" claim... but need to check that with Brian] +Hannes: Realistic timeline? +Mike: We could have a publishable version at the next IETF meeting. +Kepeng: What are the dependencies to other documents? +Mike: Dependency on the COSE document. +Jim Schaad: COSE in WGLC. Expecting no hang ups. +Ludwig: Only current dependency on the OAuth draft is the one relating to a POP token - and that's probably not critical on this timeline. +Justin: referring to the COSE draft: it's being shepherded right now (speaking as COSE chair) From Mike's slide: Next Steps = Create better examples and validate them with COSE implementations. * OSCOAP profile of ACE (Ludwig, 15 min) - https://datatracker.ietf.org/doc/draft-seitz-ace-oscoap-profile/ - slides: https://www.ietf.org/proceedings/96/slides/slides-96-ace-2.pdf Goal: Present the idea of profiles to the group - Overview - uses OSCOAP and EDHOC - 1st step: EDH exchange signed. (ref EDHOC later) - 2nd step: use OSCOAP +Clarification from Göran in response to question from Hannes: "When EDHOC is used here, it does more than just a pure D-H key exchange; the sender also signs message with the key of which s/he wishes to prove possession." +Ludwig: Asking for feedback - optionally define how to use EDHOC and OSCOAP in communication with AS. +Hannes: why leaving this optional? +Göran: constrained devices would probably have only one implementation, so if they have DTLS they would use only that, and same for OSCOAP-EDHOC. You may want to use OSCOAP only on the constrained link, but you may use DTLS with the AS if that link is not constrained. Could we say this in the document? +Hannes: in this case you would have to mandate DTLS, TLS, OSCOAP in the AS. +Kepeng: Which are the dependencies? +Ludwig: OSCOAP and EDHOC document +Kepeng: OSCOAP is not WG doc? +Ludwig: NO, neither DHelmann +Carsten: OSCOAP on the agenda at CoRE tomorrow, asking for adoption. * Group Communication Security (Hannes, 15 min) https://datatracker.ietf.org/doc/draft-hardjono-ace-fluffy/ https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/ Goal: Adopt group communication security as a WG item. slides: https://www.ietf.org/proceedings/96/slides/slides-96-ace-6.pdf - Background - Two Documents: distribution of keys for group communication - Architecture: 2 steps Core problem addressed here is how to protect keys for group communication (e.g., by an authorization server/key distribution server to IoT devices) especially considering the low latency requirements. How to ensure that only authorized entities get access to the keys? +Renzo: Is it source-authentication addressed? +Hannes: We will see in next slides, controversial. - Questions that need guidance from the wg +Kerry: You said this is this not applicable in some cases. Why? This sounds like a good idea, in general. +Hannes: We currently have one use case, lighting, that requires low latency communication. Other group communication use cases may not necessarily have the same low latency requirements. We are, however, happy to hear about more use cases. +Hannes: the question about whether ACE should look at this at all and whether symmetric crypto is an appropriate approach in this context. In this low latency environment the use of public key crypto may introduce performance/bandwidth problems. +Carsten: Answer to all questions [in the slides] but for DTLS is yes. +Renzo: the typical issue with using symmetric crypto for this purpose is that it's harder to achieve reliable identification of the source entity. +Hannes: Group communication keys will be re-generated periodically. Keys won’t be used for anything other than for group communication. Authorization is a separate mechanism that can be solved using the other tools we develop in ACE. +Mike StJohns: symmetric crypto is unsuitable if your endpoint devices don't have secure hardware for key storage because compromise of any device compromises all the others (in the group). ACE, here, is encountering exactly the same set of issues as DICE encountered. The issues here will get worse over time, not better, so issues of secure group multicast do need to be addressed; "please ensure Stephen Farrell [other Security AD] is aware of ACE's work on this". +Hannes: (...) Source authentication is difficult. I understand your concern but I don't hear your proposal. +Göran: has an idea on how that would work (shared key for confidentiality, public/private key for auth) but that would probably not address low latency problem. +Zach Zelby: Maybe performance is not an issue anymore with all the development around IoT hardware. I would like to se some "data": how much time does it take to process/create signatures, packet size.. +Mike StJohns: DICE produced two possible solutions - h/w crypto/key storage, or a public key solution. +Zach Zelby: ARM is making good progress in providing segmented, trusted computing envirnoments in hardware (as an example) ACTION: Hannes - poll for researchers prepared to write and publish relevant findings/recommendations +Mohit: on Friday (LWIG) I will be presenting numbers - 300 ms. It's an old document, but there is new data. +Subir Das: quantitative data on symmetric key implementation would be useful; +Oscar Garcia (Phillips) ?: Great to have public key promising results. But we need to look into the most constrained devices (symmetric). +Hannes: at the protocol level of abstraction, the risks inherent in different deployments could be very different... so, for instance, a spec based on the "smart lighting" use case could be quite inappropriate for other deployments. Functional separation between the endpoint functionality and an Authorization Server appears to be key + (Oscar agreed). +Hannes: Can anyone look more into the performance of asymmetric crypto? +Mohit: I am going to look more into numbers (symmetric crypto etc). +Göran: This work (and more precisely key distribution) is definitely in scope of ACE +Oscar Garcia: Example of energy harvesting from pushing a button . * Should the ACE group work on a solution for securing low latency group communication? -Humming: was almost the same (for yes and no). Kathleen Moriarty suggested doing hands. ~20 yes - ~5 no +Carsten Bormann: there's a widespread but false assumption that Authentication is a Boolean decision point... but it is not, and some forms of Authentication lack the flexibility/granularity that may be needed in particular use cases. +Schaad: the parameters of this problem can be identified to the extent needed for implementers to decide whether it's an issue for them or not. +Hannes: Is there an applicability statement that needs to accompany the technical specification... to mitigate the risk of the technical spec being inappropriately applied, or applied to the wrong kinds of use case. +Ludwig: one answer to this is to word the security considerations strictly... in the knowledge that even that will not stop fools from using the spec in silly ways (e.g. for nuclear power plant control systems rather than lighting controls......) +Mike StJohns: (1) yes, word the spec strictly; (2) design the protocol so that the risk can be constrained to a small number of devices * half of the room has an idea of what is going on. * Who would review this document? ~ 11 hands * who is interested in contribute - implement- deploy? ~ 5 hands +Ludwig: students working on the Application Layer security utilizing COSE, network overhead 8B less than DTLS +Pete Resnick: 5 is enough to not achieve rough consensus; should go to the list +Kathleen Moriarty: yes, it should go to the mailing list. +Hannes: Every decision has to be confirmed on the list anyway. * Privacy-Enhanced Tokens for Authorization in ACE (Daniel, 15 min) https://datatracker.ietf.org/doc/draft-cuellar-ace-pat-priv-enhanced-authz-tokens/ slides: https://www.ietf.org/proceedings/96/slides/slides-96-ace-3.pdf Goal: Determine whether the group is interested and ACE is the right group to work on this document. 12h03 Start - Focus on constrained devices - Goals of the draft - Architecture proposed: C - AS secure channel, C - RS insecure channel, shared secret AS - RS - Exchange of messages - protocol flow - Definition of tokens - Features - Implementation +Ludwig: general idea really useful (particularly for the privacy-enhancing effect of making it harder to link multiple requests from the same user to the same resource server). Why don't you make this as an extension of the OAuth framework that the wg is working on? +Daniel: this is planned. +Carsten: The link doesn't work. +Daniel: Will fix and post to the mailing list. * Ephemeral Diffie-Hellman Over COSE (Goeran, 15 min) https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe slides: https://www.ietf.org/proceedings/96/slides/slides-96-ace-5.pdf Goal: Determine whether the group is interested and ACE is the right group to work on this document. 12h14 Start - Background - COSE - How EDHOC uses COSE (note: 6.2.2.2 section reference is wrong in the slide, but correct in the draft) - What else EDHOC does (protocol features) - How EDHOC uses CoAP - EDHOC name - Next steps +Göran asks for feedback. +Subir Das: Why to use this if you already have a RPK? what's the rational behind? +Göran: It doesn't give the same forward secrecy property. Let's talk offline. +Kepeng: find a home for this work. Any ideas? +Göran: I think best proposal is ACE. (COSE wg is closing so it cannot be done there) +Carsten: this would make ACE the wg that does security using COSE. This is fine by me. michael richardson: It is important that we have a key agreement protocol whose code will be used for something else (i.e. OSCOAP?). Ace sounds like the right wg but it seems like this work is very orthogonal to other works in this wg. +Göran: the objective is to reuse code precisely. +Kathleen Moriarty: Thought this has already been discussed. +Goran: CBOR token was discussed and moved across from COSE. 12h31 Session Finished