ACE Virtual Interim Meeting - 16. June 2016 =========================================== Participants: * Samuel * Hannes Tschofenig * Carsten Borman * Erik * Francesca Palombini * Kathleen Moriarty * Klaus Hartke * Ludwig Seitz * Mohit * Renzo NAVAS * Shahid * Goeran Selander = Initial agenda * Solution document * Design team * CWT = Into * Carsten: There has been no update to Actors document * Hannes: Some interesting upcoming events * Hannes: OAuth security workshop * Hannes: Hackaton at IETF * Carsten: Riot summit - * Carsten mention another event that I missed to note Hannes: There is a new version of the solution Hannes: Samuel will present updated CWT draft Hannes: We also have some unclear submissions, has to be figured out to the IETF meeting. Ludwig: agenda bashing - can we move ace solution to the end? Carsten: Can we start with CWT and end with Design team = CWT Samuel presents (notes form hannes) Introduced registries for better alignment with COSE, such as the name <-> id mapping. 5 Open Issues * Need for additional examples * Details about creating and validating CWTs * Optimizations * Clean-up Ludwig noted that the COSE-C implementation is not tailored to embedded environments (use of OpenSSL and excessive buffers). Students are looking into COSE implementation; code can be found at https://github.com/Gunzter/COSE-C Possible completion date by September 2016. Carsten suggested to mark the next version as an implementation draft. = Solution document Ludwig presents Ludwig: PoP key distribution slide - we should add some acknowledgement Ludwig: Client token is a new concept, is it useful? well designed? give us feedback * Pause for questions, no questions * Token request slide Samuel: The example shows much text, in practice the values are encode to numbers. Carsten: You should look at COSE for examples on how to show this Hannes: Bearer tokens has been seen, are we to strict with pop. Ludwig: pop tokens solves some of the issues found in the OAuth spec with bearer so the simple solution was to go for pop. * Token Response slide Renzo: Is there an alternative to expired_in e.g. valid_from field and valid_to field Hannes: There are other fields, not valid before not valid after, etc Ludwig: all OAuth attributes has been mapped and can be used. * Introspection request slide Goeran: rs_cnf vs cnf, in my view cnf could be used for the RS keys so we don’t need both. Ludwig: Client might have multiple keys, so the AS need to be able to tell client which to use. Ludwig: naming it rs_conf instead of cnf is to avoid mistakes Goeran: There is a process for the client to get the token, that is where the binding between token and key is done. Ludwig: My idea that if you have a client with limited connectivity, it has one token and multiple keys and that one token can be bound to multiple keys dynamically in this way. So that we don’t have to use same key for multiple RSes Goeran: In case of symmetric keys this makes sense, we should only have one to one with RS keys. In case of asymmetric keys it could be ok. Hannes: It could be a privacy problems Renzo: I think it is a relevant case that ludwig presents Hanes: Maybe it could be a profile Goeran: The framework is the interaction with AS so a profile might not be the best solution. Maybe an extension. Hannes: Conceptually it looks like cerberus user to user authentication, maybe we could learn form there. -> end of presentations Hannes: Implementation is work ongoing e.g. Eriks experimentation Hannes: (I missed something here) Goeran: We are looking for good cose code Ludwig: We will start implementing i september Shahid: we are implementing this, in september a profile should be implemented Hannes: Carsten, do you have cose code? Carsten: Not yet? Hannes: Will it be based on Jims coded Carsten: Not so much Hannes: A few high quality implementation would be better then many low quality. Hannes: Other comments? Hannes: What is the next step? reviews? new draft for the IETF meeting? Ludwig: not much time, but if we get comments before end of June I might be able to do another update. Hannes: Does anyone have to to spare to do a Review, Shahid, Klause, Carsten Carsten: no Klaus: no, I have no time now Shahid: No Renzo: I can do a review Ludwig: Lets take client token discussion to the mailing list Carsten: calling CoAP resources endpoints is not so good Hannes: web-people call it endpoints, if you run it over http2 it would be good to call it endpoints Carsten: Lets take the endpoints discussion on the list Hannes: agree = Design team Hannes: announce in last IETF meeting, anyone is free to join Hannes: meeting time is Mondays 3pm CET (see presentation) Goeran: Will the clock be reset in power outage situation? Carsten: both cases exists, there are some tickers/clocks that can incremented only and newer resets. (presentation) Hannes: Renzo made an investigation Renzo: some information was not sent to the mailing list Hannes: I will send it to the mailing list (presentation) RPK is presented as one of the things that need a time Goeran: Why does RPK need time Renzo: there is no authentication with RPK only Hannes: you need to pre share the RPK to get authentication Goeran: Same with PSK Carsten: For RPK some claims are exchanged with time limit, and that is certificate like. But you can construct RPK solutions you would not need to design for time in that way. Carsten: With x509 there is timestamps in certificates and people using x509 assume they can and should use it. Renzo: I will se if I can find the reasoning behind the statement and send it to the list. Hannes: Renzo did a extensive investigation of three party solutions too Renzo: time is used for freshness if time is not available nonce is used Hannes: Carsten you taked about local relative time solutions (Hannes opens slides from Carsten) Carsten: Sides are about situations where you don’t have absolute time but relative time. (see presentation) Goeran: how does Access token relates to freshness tokens Carsten: that is unknown (I missed some stuff here) Goeran: How does it tie to the authorization Carsten: Resource server has an exchange with its authorizer Hannes: There is a meeting the Peter Aldworth. Information has been sent to the list but I can resend it. Shahid: I will ask a college to join Hannes: Anything else?