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

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.