Minutes for ACE at IETF-96
minutes-96-ace-1

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