Minutes for ACE at IETF-91
minutes-91-ace-2

ACE WG Meeting
IETF 91 - Honolulu
Wednesday 12 November 2014, 13:00 - 15:00 HST
Chairs: Kepeng Li, Hannes Tschofenig

Agenda          * Administrative and Agenda Bashing (Chairs, 5 mins)

* Use Cases (Sandeep Kumar, 30 mins)
  - http://datatracker.ietf.org/doc/draft-seitz-ace-usecases/

   - 7 use cases should cover most interesting IoT areas
   - Updates include the numerous feedback and change of focus, requirements
   removed - Scenarios overview (one new scenario uses store and forward) -
   Summary of owner's main auth problems - Highlight of home use problems
   (non-technical admins) - Lifecycle considerations - How to proceed

     Q&A:
   Justin Richer: New key use case should be industrial control for
   manufacturers/supply-chain-management. Hannes: Good progress in this
   document. Who has read the draft? about 20 hands. Rene Struik: Usefull; we
   can always expand. Requirement (which are still in the end of the draft) to
   dynamically revoke authorization is not discussed well enough. Solutions
   will not cover recovering from anomalies. => Only adopt use cases but now
   MUSTs. Mike St. Johns: Are we writing multiple protocols or multiple
   profiles of one protocol..? Can we do segmentation because the use cases are
   very diverse. Decide what is costly and what not in whtich use case, do a
   cost/benefit analysis for each use case. Lionel Morand:  use case examples
   are good. Not so much about volunteering new use cases, but asking ourselves
   if the current use cases covers the full range of requirements. Sandeep:
   Yes, adding new use cases is about checking if there are still unseen
   problems. Carsten: Adoption is no-brainer. Getting rid of the requirements
   was good, as this is about problem statements and their cost. Tony:
   submitted my use cases but was told they are out of scope. Would like to see
   the doc adopted but worried that not the right set of use cases. Ludwig via
   Jabber: Document does not advocate any solutions. Tony was not told it were
   out-of-scope. Tony: I was, it's on the mailing list. Hannes: We want to
   avoid covering everything to not end up with a very heavyweight solution.
   Happy with draft being solution-agnostic. Hannes: Didn't quite understand
   the cost/benefit analysis. Mike, can you elaborate? Mike: Safety
   requirements have a higher budget in industry automation, insurances might
   be different, requiring an expert is sometimes not costly, sometimes it is.
   Mike: I think we have a good set of use cases. Would welcome additional
   comment on "ok to be expensive, not ok",  "ok to require an expert, not ok".
   Hannes: Would be useful if you post a bit of text to the mailing list to
   clarify what you mean .Aiming at building blocks that can be used in
   different environments, but there can be more environment details that
   cannot be covered by IETF. Mike: Smart energy has very different
   requirements, for instance, power plant vs light switch. Kathleen Moriarty
   (AD hat off): Switch or thermostat could also have privacy implications.
   Kathleen Moriarty (AD hat on): Adoption does not mean it is done! Robert
   Cragie: To early to start to talk about costs. Use cases draft can be
   updated in the future to have a better picture. Rene Struik: It should be
   possible to design a uniform architecture to cover all use cases. Barry
   Leiba  (AD): regarding adoption, one can disagree with most of the content
   and still be in favor of adoption. You will still have an opportunity to
   fight for the content. Carsten: Best place to work on requirements is the
   individual solution document. Each schould have a requirements section.
   Robert Cragie: Use cases should not be abstract because they are about
   real-world applications. Hannes: we'll remove the last bits of requirements
   language from the document. Hum result: adopt.

   Carsten: MUSTs in the document are there to describe the use cases, no
   requirements language (MUSTs).

* Actors (Carsten Bormann, 25 mins)
   - http://datatracker.ietf.org/doc/draft-gerdes-ace-actors/

   - People often failed talking to each other because of terminology
   - Document collects relevent terms, in particular, the abstract "roles"
   (taken -> "actors") of the components - Problem statement: at least one
   actor is constrained (not necessarily both) - Overview of basic security
   requirements- Authenticated Authorization: sometimes hard to separate -
   Overview of auth and security objectives, granularity - new terms in -02.
   Believes more terms are still needed.

   Q&A:
   Justin Richer: Consider combinations (e.g., first two)
   Carsten: Yes

   - Perimeter security not optimal for IoT in general (home automation is
   based on this today). - Long appendix in the doc to detail the tasks to do
   throught the scenarios - We need names for the actors, which can be mere
   models (virtual)constrained actors, humans/corps. with interests -> owners -
   Constraints met by adding a less-constrained level CAM/SAM managers act on
   behalf of owner - Changed terminology in this version to clear some
   confusion. - Actors are logical, can be combined on devices/in software
   (figure labels just for illustration) - Take away slide: 3 levels of
   control. Humans on the top, less constraiend under them, and constrained at
   the bottom. - Terminology frames thinking. - Next steps: can we align the
   terminology across drafts, do we neeed new terms, changes? Then decide if
   this document should be published on its own right, or content go elsewhere.

   Hannes: Good question where would the terminology reside. Some of the terms
   can be found already in the use case document, but many definitions are
   missing. Would it be possible to move the terminology to the use case
   document? Detailed steps are not good for the use case doc. Carsten: should
   not go there, it's about solutions' terminology, not use case terminology.
   Dave Robben: Likes the document and "real names." Confusing though: Similar
   to OAuth, but owner does not own whole resource server. Problem when RO, R,
   and RS belong to same security domain. Some Resources might be owned by
   manufacturer. We need to consider that ROs do not own RSs, but Resources.
   Hannes: question also about separation of AM for client and for server. Look
   at Kantara UMA work. Came up with different terminology, should look at that
   and see if can reuse terminology. Robert Cragie: Really good, useful
   document. Should be clarified that the RS has multiple Rs. Set of
   terminology should be consistent for us, but does not need to be aligned
   across WGs/areas. Mike: There are many such systems out there already.
   Confusing to slice along the "speakers," but it should be about the
   credentials. Mike: your taxonomy starting to look confusing, Tony: found the
   document very useful, but terminology similar to OAuth - a problem. Carsten:
   It is more about the purpose not the protocol. Justin Richer: It is clear
   that naming things is hard. Kantara came up with terms and with solutions
   coming up things became clearer and some terms were dropped. Kepeng: Two
   open issues, one is combining or separating CAM/SAM, another is to include
   terminology in use case draft or keep it separate or let it standalone?
   Carsten: Keep it separate. There is also no connected deliverable. Hannes:
   were hoping to progress the use cas document faster, not reference other
   documents. Sandeep: some terminologies in use case documents, but not
   solution terminology. Adding it would sorta dictate solutions. Hannes
   disagrees, take the action point to go through use case doc and find what
   terms need to be defined. The documents dont completely overlap. Matthias:
   important to keep the terminology in sync, but not necessary to copy the
   terminology section into the use case document (also to keep it
   solution-agnostic). Hannes: use case doc needs to have a definition for
   terms, as it has today. But only a few are there, which leaves the others
   undefined. ok with that? Carsten: example of ..., can only talk about it if
   you know what the solution is.

   Recommends to finish the use case doc, use the terms the best way you feel
   the termnilogy document is going to define them. The terminology doc will
   define them more accurately. Rene Hummen: Keep CAM/SAM separate to be open
   for solutions and see what turns out (the can be combined afterall).
   Stefanie via Jabber: We want to keep solutions out of the use case document.

* Architecture Comparison (Bert Greevenbosch, 25 mins)
   - http://datatracker.ietf.org/doc/draft-greevenbosch-ace-comparison/

   - Compares several technical solutions for ACE on the table. Compared 5
   different solutions in this draft. - Compares: DCAF (pull), OAuth (push or
   pull), EAP (pull, AAA as AS), TWAI (indirect push), and PULL (pull model) (I
   checked the draft) - Actually 3 categories:
      - Push model: client might not have the direct connection to the
      authorization server; - Indirect push model: RS needs to cache the
      tickets; - Pull model: nothing specific mentioned.

   - Number of parties
   - Ticket format
   - Protocol for auth info exchange
   - Client credentials: mostly out-of-scope
   - Considerations: DCAF, TWAI, and PULL designed for IoT; EAP and OAuth
   originally designed for normal Internet

   Carsten: CAM/SAM in DCAF is not proprietary, could use any protocol.
   Robert Craige: AM role in the pull model is different from that in the other
   models, makes it confusing. This with actor terminology and a mapping table
   for the original specs would be helpful. We need to understand the bottom
   line of the models, not the details of protocols or credentials. Dave
   Robben: You consider monolithic device clients, which have a DTLS identity,
   like a lightswitch or bulb. These are not multi-user clients from the normal
   Internet. In the latter case it is about the users, not the device. 
   Somebody takes control of the hand tool. OAuth is independent from the
   device identity! Robert Craige: Clients are not devices. There might be
   multiple clients on a deivce as well as multiple RSs. It is a lot about
   state in the lifecycle. Bert: We are still in a constrained environment
   where the roles of the small things are not that dynamic. What is the cost
   to be this flexible. Barry: relaying Erik Walstroem on Jabber: solutions
   adapted to IoT.

* Object Security (John Mattsson, 30 mins)
   - http://datatracker.ietf.org/doc/draft-selander-ace-object-security/

   - end-to-end security together with proxies, can be more lightweight than
   DTLS. - Fits into ACE because the AS can help with key management. - Based
   on a working implementation? - Help with more input if you are working on
   similar approaches - Similar to JOSE

    Hannes: Why only the signature capabilities and not also the encryption?
    John: Time issues.
    Zach: Why a CoAP option? How does this work in combination with encryption?
    John: Not all CoAP messages have payloads. Details about payload not
    figured out, but signatures need to be optimized (not repeated). Derek
    Atkins: How about CBOR and JOSE? John: JOSE is defined today, but the
    possibility to make it smaller is something to follow. Carsten: on he CoAP
    option vs paylod question, this is somethung we need to work on. We need
    some good ways to combine these.

    - Overview of what should be protected.
    - Replay protection using a transaction ID that is different from MID or
    Token (the are also changed by proxies), key identifier and sequence
    number. - Ongoing work: how to do caching and observe; future: encryption
    for privacy in data aggregation nodes.

    Mikko Sarnivala: What is the additional overhead?

    John: JOSE: 150 B for HMAC and 300+ for digital signature; could be
    optimized.

* Wrap-up (Chairs, 5 mins)

    - Use case document was most important, audience voted for adoption, please
    still provide input on additional use cases. - We are not yet there to go
    for solutions, so no adoptions there. - Aiming for next IETF meeting to go
    into solution space. - Webinar on IoT hardware: another round specifically
    on energy-efficiency (Doodle). - Some data points on ECC performance will
    be sent around.

     Kathleen: IESG discussed this. Recommend to split the doc. Wiki could be a
     better tool than drafts that are not headed for RFC. Hannes: People
     sometimes want an RFC published. Participant via Jabber: Why should I
     invest my time in a document that does not get published? Barry: This
     contributes to the entire set of documents; might not have your name on it
     but is important work. Carsten: "Diversity" (academic attendence problem..)

     Kathleen: for this document, we continue the normal RFC publication
     process. For future work, the trend is not to publish use case document as
     RFC.