Minutes for ACE at interim-2016-ace-2
minutes-interim-2016-ace-2-2

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?