IETF 95 ACE Meeting Agenda Monday, 10:00-12:30 Chairs: Kepeng Li/Hannes Tschofenig Meeting Minute Taker: Thomas Fossati * Status Update (Hannes, 5 min) [Slides at https://www.ietf.org/proceedings/95/slides/slides-95-ace-0.pdf] • No Kepeng this time. • Milestones: RFC7744 published. • We are a bit late on the architecture document. • The solution document needs a milestone adjustments: we should probably move the milestone after next IETF to take the implementation feedback into account (e.g. SICS project, ARM implementation started at Prague's hackathon, Erik Wahlstroem implementation on github). • Call for adoption for the CWT document (see below). • Note that there is a OAuth security workshop (the week before next IETF). The scope is to bridge standardisation and research. The topics under discussion will also include ACE. Position paper deadline: 21 May 2016. * Actors (Carsten Bormann, 15 min) [I-D: http://datatracker.ietf.org/doc/draft-ietf-ace-actors/] Carsten: Already got reviews from Robin and Michael R. -- reviews needed from Sandeep & Robert. Need a further round of edits, then it should be pretty much ready. Hannes: Who read this? 9 hands up. Dave volunteers for another review. Dave Robin: confusing terminology for someone coming from OAuth (AS / RS terminology reuse with slightly different semantics). Will provide comments on the list. Hannes: end of May date for a virtual meeting? Who'd participate: 10 hands up. * Authorization for the Internet of Things using OAuth 2.0 (Goeran, 80 min) [I-D: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-01/] Goeran goes through the "ACE solution summary" and "ACE framework and ACE profiles" slides (see 3-5 from https://www.ietf.org/proceedings/95/slides/slides-95-ace-2.pdf) Need to precisely define draft scope (what belongs into the document and what doesn't). The following 7 dimensions are explored (see 7-14 from https://www.ietf.org/proceedings/95/slides/slides-95-ace-2.pdf). Goeran provides his proposed option (marked as "[G's proposal]"). • #1 - deployment options (aka token introspection in or out) o [G's proposal] leave it in • #2 - application or transport security o [G's proposal] both, i.e. 1 transport (DTLS) and 1 application • #3 - credential options? o [G's proposal] RPK and PSK (leave out full blown X.509 certificates) • #4 - token transport o [G's proposal] only "POST /authz-info" • #5 - RS-synchronised time (device with non-synchronised clocks) o [G's proposal] nonce based mechanism for RS synchronisation with AS in separate draft • #6 - CoAP vs HTTP o [G's proposal] leave HTTP out • #7 CBOR/COSE vs JSON/JOSE o [G's proposal] CBOR/COSE only Dave Thaler: need to define a MTI choice for each of the options, otherwise no interop is possible. Hannes: milestone says to be finished in May, but that sounds non realistic. Also needs implementation & interop tests. We should put the minimum in this doc, specifically: • #2 - DTLS only • #3 - RPK only (The IoT device generates the key-pair and sends it to the AS. This which looks a bit like a certificate but not in the WebPKI sense.) • #4 - note that token binding (tokbind) approach could be re-used here Carsten: open to any division of labour we come up with. framework vs profile. Dave Thaler: propose to let this document solely describe the framework, whereas other documents will define individual profiles. No strong preference on how to operate the split. Renzo Navas: on #5 (PoP token). Sent an email (https://www.ietf.org/mail-archive/web/ace/current/msg01742.html) to the list with slides listing a bunch of proposals for how to do that (https://www.ietf.org/mail-archive/web/ace/current/pdfKXSPtuAcJZ.pdf). Mohit: In IoT there are too many options, it's impossible to make everyone happy. Suggests to pick one or two use cases and derive options from there to define the profiles. Rob Cragie (from Jabber): +1 on splitting the document, framework vs profile. Goeran: agrees on one framework & multiple profiles. Renzo Navas: on OAuth PoP-token solutions (goes through the slides at https://www.ietf.org/mail-archive/web/ace/current/pdfKXSPtuAcJZ.pdf) • An overview of TTP-based auth key establishment options from literature that don't use timestamps (they are all nonce-based) and could be used to solve the PoP token generation. ??: Why do we need to sync with RS? Wouldn't it be sufficient to have the RS provide its own relative time? Dave Robin: For example suppose C can't see RS. C goes to AS and gets a token that is good for one day. Than RS becomes reachable and C supplies the token to it. Dave Robin: Replacing duration with expiration is not an option because you need to remember every single token you have ever seen otherwise it could be replied. Hannes: About document split. The proposal is to have one that describes the framework, plus a number of separate docs one for each profile to which an implementation can claim conformance. Who's OK with this? 10 hands on + 2 from jabber. Who's not OK with this? No hands on. Goeran: Which profiles we want to work on? Hannes: question to the room on #2 about which secure channel should we use. TLS? 6 hands on. Application layer? 8 hands on. (Intersection between the two sets is non empty.) Carsten to explain what the application layer solution currently explored in CoRE. Carsten: CoAP needs to secure the relationship between request and responses also in presence of proxies. COSE in ACE would inform how CoAP signing is done in CoRE. Hannes: question to the room on #1. Token introspection? 4 hands on. Local verification model: 6 hands on. Jim: What is the use case? Is it restricted RS or restricted C? It looks like restricted C. Hannes: to keep communication small (RS, e.g. door lock, uses back-channel to outsource the authorization to the AS, to keep the RS very simple). Hannes: question to the room on #3. PSK? 6 hands on. RPK? 7 hands on. X509 certificates? 3 hands on. (Intersection between the three sets is non empty.) Hannes: question to the room on #4. It looks it might be too early to have an informed decision on this. Goeran: We should aim for the common denominator of all the profiles. Hannes: question to the room on #5. Who's interested in synchronised clocks use cases? 11 hands on. Who's interested in non-sychronised clocks? 5 hands on. Hannes: question to the room on #6. Goeran: Do we really care? Mohit: these are often not independent choices. ??: How does CoAP compares to HTTP/2? Carsten: We should model the REST interface, then the transport is secondary. Hannes: A profile needs to say exactly which transport protocol it has to implement. Dave Robin: About modelling the REST interface: /authz-info is an example of something we did like that because the transport (CoAP). In HTTP this would have gone into a header. Hannes: again, question to the room on #6. HTTP 1.1, 5 hands on. HTTP/2, 5 hands on. Hannes: I want to come up with a list of people that want to work together on specific profiles: 1. PSK-based, no introspection, CoAP based (C->AS, C->RS), DTLS, CBOR/COSE token 2. RPK-based, no introspection, CoAP based (C->AS, C->RS), DTLS, CBOR/COSE token Hannes: dependency on time should be addressed separately. Thomas W & Carsten: lots of fun in this area Hannes: Who'd like to work on non-synchronised clocks? Ludwig, Renzo, Thomas W, Carsten volunteer. * CBOR Web Token (Mike, 15 min) [I-D: https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/] [Slides at https://www.ietf.org/proceedings/95/slides/slides-95-ace-1.pdf] Mike: CBOR/COSE equivalent of JWT spec. Draft updated (added registry info for CWT claims). Call for adoption in the ACE WG. 4 people have looked at it Hannes: this small number is surprising since we don't have a non-JSON way to encode the token in ACE. Who wants to review? Diego, Carsten, Michael R. volunteer. * Security for Low-Latency Group Communication (Sandeep, 30 min) [I-D: https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/] Low latency communication for group communication. Hannes: illustrates the architecture of group key distribution in the lightning use case.