ACE WG Meeting IETF 98 - Chicago Monday, 27 March, 2017, 9:00 - 11:30 Chairs: Hannes Tschofenig, Kepeng Li Note takers: Ari Keränen, Mohit Sethi * Agenda Bashing and Status Update (Chairs, 10 mins) Milestones need adjustment. Potentially need new milestones, depending on discussions today. Little bit behind so need to speed up progress. CWT milestone needs to be added. Looking for input on other documents if they should be worked at ACE. Virtual interim. Secure for low-latency group communication. We had a call for adoption. Some people want to see changes. Re-scoping the document. * Actors (Carsten Bormann, 5 mins) - http://datatracker.ietf.org/doc/draft-ietf-ace-actors/ Informational doc that allways gets pushed back behind solutions doc. Addressing review comments and submitted doc. Question (for off-line): are there sections/subjects we want to drop in latter half? Want to compress latter half. If opinions, please state on mailing list. Hannes: When do you think the document is finished? Carsten: next round availabel in May. If feedback received, might be done in Prague. Carsten: (agenda bashing) TUDA from last meeting could be squeezed in here Hannes: reviewers? Elliot L and Dave T volunteered. * CBOR Web Token (Mike Jones, 15 mins) - https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/ Status of CWT doc. Issue: complete examples that were self-contained. There are now examples with full binary representations. People encouraged to try them with their implementations. Mike: Time for WGLC? Hannes: objections to WGLC? Around for while already? Don't see any objections Mike: where do we stand with COSE to RFC editor? almost done Ludwig: weakeness in JOSE work, and how that affects COSE and CWT? Mike: asked to do presentation on the topic. Cases where you don't validate input when using ephemeral key. Could gather info what implementation does with bad input. Fixed in some Java frameworks, but want to have defense in depth. Applications should understand if the crypto they do is valid. That's why crypto agility Hannes: Mike, please post info to the mailing list on the issue. Antonio did good writeup. Brian C: Re CWT, one issue related to crpyto agility. Algos in the body of the token. Algo designation in control of attacker and apps not specific what they accept. Also attack on ECDH. Requires point validation before key agreement. Hannes: CWT one shot message. Both sides need to understand what needs to be there. Saw implementations in WS where any algo accepted (even none). Brian: people getting this wrong. Arguments towards not including algo agility in the message. Need stronger text on what needs to be done. Could be more clear in COSE. Hannes: need to have second look at the text * Authorization using OAuth 2.0 (Ludwig Seitz, 10 mins) - https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Ludwig: This is framework document. Profiles for the framework in other documents. Review of IANA section very welcome; it's getting long. Different meaning of end-point in Oauth and CoAP. Referring to OAuth end-point here. Grant flow relevant for ace. Hannes: mobile phone with device flow ruled out? Ludwig: would use plain OAuth for that. Need to have powerful device anyway in that case so can use plain OAuth. Ludwig: Updated security and privacy considerations. Tokens valid for multiple RS. RS can impoersonate if same symmetric key is used. Info can be leaked from non-encrypted CWT. Profiles not ready for implementation. More implementations needed. Framework is becoming stable. BLE profile. Time adopt some profiles? Hannes: milestone out of date. What reasonable timeframe? Ludwig: don't need implementation ready, right? Hannes: Hackaton effort on this. Next hackaton could look into this too. Ludwig: document-wise not much left. We could WGLC now. Now focusing getting implemented. Göran S: maybe bit early for WGLC. Some stuff specified in profiles need to work in framework. Maybe some stuff from profiles should be in framework. Hannes: expect guys who work on profiles have read framework and can give comments framework fits their needs * ACE Profiles (Göran Selander, 20 mins) - https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ Currently 4 profiles paritally overlapping. Need to figure out how to handle that. CoAP-DTLS and -OSCOAP relatively straightforward. MQTT TLS and CoAP pub/sub profiles more complex and slightly overlapping. Hannes: overlapping in terms of pub/sub but otherwise quite different? Gorän: sure. overlap how do we coordinate. Reference each other? Mohit: do you have profile negotiation? How do I know if the other endpoint does what? Ludwig: had in early version of draft complex profile negotiation. But was overengineered. Now assumptions that AS knows what RS and client knows (since they registered) and selects the best matching one. Client informed what to use. Hannes: some profiles have static conf or obvious from context. E.g. BLE may have specific profile. Göran: profiles need to be modular and refernce each other Carsten: profile negotiation between two authorization managers. Göran: do we need to control this? Anyone can submit profiles and we adopt them? More coordnation needed? Hannes: Somewhat pragmatic. Figuring out what is best at given point of time. we just discuss differences and iron out differences. Göran: if we adopt one draft that is overlapping with non-adopted. Need to consider that? Already overlaps. Could take practical approach and go ahead and see what happens. M. Richardson: Go ahead. We are producing proposed Internet standards. If later detect there was common text that should be somewhere, can be fixed later. Not unreasonable and faster too. Carsten: Just had discussion of JWT/CWT being under attacker control. Profile selection has same problem. If AS can push in profile that makes client think it's talking to wrong RS, that's problem. Göran: if AS is not trusted, we have problem anyway Göran: error handling should be in framework or profiles? Hannes: will ask profile authors to provide feedback to framework to get alignment. All profile authors should be familiar with the framework draft. * DTLS Profile for ACE (Carsten Bormann, 10 mins) - https://datatracker.ietf.org/doc/draft-gerdes-ace-dtls-authorize/ Carsten: DTLS channel setup happens with RPK or PSK. Ludwig: one option is to incude CNF conf claim that just specifies a kid. "I've established this key; please bind new access token to the key" Carsten: access token designed to be transmitted in clear (even if PSK). Client gets PSK key in COSE structure. Assuming secure channel to AS. Server can extract key from access token (encrypted, derived, or by reference). Hannes: so 3 different ways to get key. Challenges with interop? Which to implement? Carsten: AS-specific. Between RS and AS. Need to agree on way to do this. Hannes: easier to just define one? Carsten: originally had just one, but people wanted to have other ways. Don't mind cutting down. John Mattson: should commit to adding TLS. Changes would be small. Carsten: agree John: Which version of DTLS this applies? Carsten: hopefully a reference to RFC 6347. 1.2 since CoAP uses that, but once 1.3 is out need to have a look. John: should mostly just work. Some cipher suite negotation needs to have look. Carsten: UTF PSK problematic Hannes: in TLS 1.2 PSK not UTF in wire; question was how user indicates and how passed to sw. One uniform encoding for passing from UI to stack. Carsten: if you read spec, implementers may not have got that right John: ready for WG adoption Hannes: currently not in chartered item, so AD needs to approve. Good to get confirmation. Would make sense to me but up to AD to decide. Göran: Comment on charter. Profiles are missing part. Charter are already covers profiles. Hannes: interpreted charter as profiles already part of? Kathleen: Seems to be interest. But need to make sure there's energy behind. Need to update charter. But don't seem to be out of scope for ACE. Hannes: asking 1) if we should adopt the doc 2) who would be working (15 hands shown for "who has read" asked by Carsten) who supports adoption: 17 hands + 1 in jabber (Renzo) who objects: none reviewers: Jim, Michal, Sean (4-5 hands) Implementations: Ludwig, Renzo (one java implementation before adoption) (Renzo: no java implem. I think it is Ludwig Java and Olaf C/libcoap). Kathleen will comb through the charter. Still confirmation needed on list. * CoAP Pub-sub Profile (Francesca Palombini, 15 mins) - https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/ Francesca: Using token-less exchange that was removed from framework. Could be useful to have it back. Hannes: was less baked idea (back then) MQTT profile does not differentiate between published and subsbriber. Hannes: design decision for MQTT broker were supposedly different. Do you know why? Francesca: (second bullet of nodes); depending on if you're worried of DoS attacks or need more control on who can subscribe. CoAP MQTT differences. Ludwig: in MQTT profile broker is trusted. Payload not trusted so profile can modify. Difference in assumptions who is trusted. Hannes: why different assumptions made in different profiles? Carsten: both approaches have their place. Are situations where broker is trusted and can go with something simple. When not fully trusted, go with something like this. Don't need to do anything extra on CoAP side since we have pieces in place for this. Ludwig: not sure if mechanism for updating the public keys subsribers have if new publisher gets autorized. Francesca: not yet Carsten: fun part: when publisher of subscriber gets de-authorized. Francesca: could be another doc Randy Turner: pub/sub CoAP discusses also broker-less. Broker can be real thing or just interface. Anything in the profile about brokerless? Francesca: not yet, but if there's interest, could look into it Hannes: who has read the doc? (about 10) Hannes: not yet lots of feedback. Who could review? (Michael K, Ari, Carsten, (Jim S?), Jaime) Henk: thank you for including way to proof and sign data provencance; it's awesome Carsten: really group communication profile, beyond pubsub. Also want to have gating function, broker only lets through authorized publications. Hannes: working on implementation? Francesca: not right now * Ephemeral Diffie-Hellman Over COSE (John Mattsson, 15 mins) - https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/ Few implementations in progress. Interop planned before the summer. Mohit: (EDHOC with asymmteric keys slide) message 1, does that propose set? John: only proposes one. Mohit: public key already encoded? John: yes, choose one algo Michael R: only one algorithm proposed? How to migrate? Jim S: actually propose several and opposite side chooses one. Mohit: if it support several curves then how is Public key encoded in the first message? Jim: curve and key type for eph key sender chooses one and if you don't like it it's error message in protocol Michael R: (slide with OSCOAP embedding; "example") One situation that is valuable; what if server not prerapered to answer message #2 but don't want client keep on asking? Do we need more separation between post and response? Between message 1-3? Too complicated? Carsten: CoAP has separate response; ACK and make client quiet. Michael: exactly what I want Peter: HTTP similar(???) Hannes (from floor): reflects my fears of the work. Re-building TLS handshake. Adding soon all the goodness we've added in TLS WG. But could just use TLS. Main difference is the encoding. Broadband forum has been looking into this. Have run TLS handshake as app-layer mechanism. Sounds like lot of work re-designing security protocol. Should take that cautiously. John: implementation of sigma protocol; proofs in place. This is more simple than TLS handshake with all options. Benefit being able to use COSE and not have COSE and TLS. Dave T: using fixed paths not under .well-known. See RFC 7320 Carsten: have implemnted TLS in app layer long ago. Internet draft about that. Doesn't take away the point of doind something smaller. Dan Harkins: what is (one of the keys) John: lots of entropy - just like you should. Need to clarify in the draft. Göran: point (to Hannes' comment) is we're using on a small device with COSE, CoAP, and CBOR. Want to have small addition of code to have key management protocol. That's why different from TLS. Hannes: ball is with Kathleen with this kind of work. John: used by 6tisch already Carsten: given the status, typical place where we would go for WG adoption. Don't know which WG. Enough people in the room who understand the topic even if we don't know the right WG. Hannes: need to excuse myself on this Göran: already discussed what is the relevant WG. Feeling was that ACE is the one. Hannes: don't think it's covered in charter Kathleen (as AD): if WG wants adopt this, we add to charter. Two meetings ago minutes reflected interest. Can now poll again interest. How many have read the document (12 + 1 jabber), how many interested adopting (15 + 2 jabber). Opposing adoption (Hannes). Sean: as long as we keep small and no feature creep Mohit: already options for extensions in draft Kathleen: core document without extensions fine? Sean: yes, just set the bar really high Kathleen: seems to be enough interest in the WG. Who interested in deploying (around 6 + 1 jabber) Kathleen: will go through the formal process on list * EST over secure CoAP (Peter van der Stok, 15 mins) - https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/ Peter: Extension of Anima work. Specifies EST over CoAP+DTLS. Can make adding CoAP and HTTP devices to networks work the same way. Elliot L: important work. Important start. Not sure if ACE is right WG. Maybe goto to ANIMA. Peter: kind of depends on knowledge here could be here; also discussed with CoRE. Elliot: need to be coordinatied with BRSKI work etc. Hannes: strictly tied to ANIMA? Initial work on EST was generic in some sense. Is ANIMA adding something specific? Elliot: no, meant to solve the problem where you want to end up with rigth certificate and trust with the thing Derrel Piper: concerned that is this in charter? Do we want this? Hannes: competing effort / other solutions? Which direction we want to go? Where should the work happen? Derrel: important principle: keep trusted computing space small Dave: No opinion on where it should progress. Don't fix URIs. Host can do /est but it is recommended. Recommended is bad. Every draft that uses fixed URIs Max Pritkin: agnostic on where work happens. Agree on basic goal. ANIMA BRSKI uses JSON. Need to make sure aligned with BRSKI draft. Not using CBOR now. If important for BRSKI, need feedback there. M. Richardson: BRSKI is not the name of the protocol. I don't think this belongs in ACE. Important work, keep doing it. Removed all CoAP CBOR stuff from BRSKI because didn't know how to do it. Nothing prevents us from adding it later. Currently not enouraged to work with constrained devices at ANIMA. Peter: I like building blocks and blocks that can be removed. M. Richardson: Conitnue with this but don't think this belongs in ACE. Sean T: Contenct accept header; client can tell what it supports and server can give right kind of thing back. Derrel: if want from XML to JSON welcome to my table Kathleen (as AD): this group has published only one doc so far. Milestones need to be updated. Need to understand priorities and streamline. Need to understand with new work what we're taking on. * Enrollment with Application Layer Security (Goran Selander, 15 mins) - https://www.ietf.org/id/draft-selander-ace-eals-00.txt Another draft of certificate enrollment. May or may not do in this working group. Not a competetor but a compliment to the previous proposal. There is overlap in names. Work ongoing in application layer security. You don't have to implement TLS/DTLS. Hannes: (phase #1 slide) where is certificate signing? Göran: this is phase #1, that's in next phase Mike: motivation for client token? Göran: used to establish key between client and RS who have never met before. Client is offline and can't contact AS before joining network. In order to contact RS need to go via point in network. All communication between client and RS unprotected. Michael R: sounds like some is confused with needed routing info to get stuff through. Göran: ties in with next presentation about disconnected clients Hannes: is fair characterization: both drafts use cert signing request to communicate with infra? Göran: both very closely linked to EST. Previous draft replaces HTTP/TLS with CoAP/DTLS. This draft replacing TLS with app layer security. Hannes: seems we have one camp that likes TLS and other who don't. Should standardize both because provide security in different layers? Göran: yes. Working on both app and transport layers. Ming Pei: app security vs dtls. How device is authorized given a certificate? Many ways to do the same thing in EST? Hannes: only one in both these documents Sean: PKI had four ways to do this. Would be great to have only one. Hannes: different approahces: thousand flowers to bloom; easier for WG chairs and ADs Max P: looks like bootstrapping to secure key infra flow. More like BRSKI. Inluceded ownership voucher? All other messages CBOR? Expecting CBOR here? Göran: detail in the draft. Expect to take most compact representation available. Max: seems more input to ANIMA that all should be CBOR. Hannes: EST and x509 you need ASN.1 libraries. Gorän: Would like to have more compact representation than ASN.1. Michael R: I think on can do TLS with RPK pinned to ownership voucher. With opaque text you pass to registrar. Device doesn't need to do any ASN.1 operations. Simple comparison operations. Can do with TLS and OSCOAP. Can get away without arguments of needing ASN.1. Don't need to parse ASN.1. Hannes: would be useful if can write this down Michael: will implement first. Would look like implementing full thing but don't need to. * Offline usage of ACE (Jintao Zhu, 15 mins) - https://datatracker.ietf.org/doc/draft-zhu-ace-offline/ Göran: (client-AS disconnet slide) the case in previous preso with clien token. Resource serve is proxy for AS information. Jintao: suggestion to send auth information in step E (of slide). Göran: want clien token via E and F to client? Jintao: client as RS to obtain auth information from E. Göran: auth info for RS is in response. ... in client token. Can take this off-line Dave Robin: very similar to previous presentation. When bringing building automation online, client often on latptop and can get to AS, but resource server can not. This is opposite of what we usually see. Hannes: had discussion already in WG; can come up with different variations. Which ones we want to work first? There are other scenarios for the authors. Dave R: just throwing in data point that generally we see that RS can't talk to network Jintao: acceptable for RS to have cache managed by client? Ludwig: not sure. Could allow client token to delete it's own access token. Would need to manage rights. Don't spontaneously see problem. Jintao: (client-RS disconnect); OK for AS to act as proxy for requests to RS? Göran: assume AS is non-constrained device. What is use case when client can't access RS? Jintao: smart home device control remotely. Can't connect to it directly. Mohit: if you are remote don't have bluetooth access to device, use hub instead. That's use case. Dave R: example flow is correct, but it's not AS doing the proxy function but hub. Ludwig: this is specified in RFC2904 as agent sequence. Before OAuth so no access token. Not covered by ACE FW as it's now. And would require great changes to OAuth. Is pattern that has been used before in IETF. Darrel: wasn't but it was bad idea. Justin R: AS not a box. It's a function. Known as API GW. Single box doing proxy and AS. Also need to keep in mind that constrained means different things to different people. Agree with Kathleen that this WG needs to solve actual problems. * Wrap-up (Chairs, 5 min) Will work with Kathleen on the action items. OAuth meeting will have related stuff. If have time go there.