Minutes IETF102: ace
minutes-102-ace-00

ACE WG IETF 102 Minutes

Monday July 16, 2018 0930h-1200h

Chairs: Jim Schaad and Roman Danyliw
Minute takers: Francesca Palombini
Jabber scribe: Benjamin Damm

Introduction and WG Status
==========================
presenters: Jim Schaad and Roman Danyliw
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-chairs-update

The WG chairs introduced the agenda, summarized document status and reviewed
recently updated milestones.  The WG proposed no changes to these milestones

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
============================================================
presenter: Mike Jones
draft: draft-ietf-ace-cwt-proof-of-possession
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-pop-key-semantics-for-cbor-web-tokens-00

Jones presented a summary of feedback from the WGLC on
draft-ietf-ace-cwt-proof-of-possession-03.

(Carsten Bormann)  comment to think about: idea of COSE was to use JOSE as much
as possible, then there was reasons to have deviation, that's why it's
different. Main reason is the domain of application (devices). With CWT and CW
PoP we still have this need, I don't know how we can solve it, but maybe we
want to have more nailed down semantics in CWT and CW PoP.

(Mike Jones)  great point. Slides do oversimplify. A year ago there were 2
drafts that did the same thing. These 2 drafts were essentially the same,
including deleting the 7800, which showed that we were on the right track.

(Hannes Tschofenig)  use of multiple of keys, initially I was on favor then
changed my mind because I didn't have a use case. Maybe if it is a good use
case for CWT then it is also for JSON, but did not have one. One item I would
like to discuss is the key id topic. Did not see a good conclusion of that in
the mailing list.

(Mike Jones)  about multiple keys, after discussing it we decided to have it in
the doc. About the kid we did write a new section describing that if multiple
keys in different spaces you will have to be able to look up those keys.

(Jim Schaad)  Reference by kid is not adequately adressed in the doc. Whole lot
of issues are problematic and should be thought through, there is another that
I cannot now remember.

(Mike Jones)  do we also need to discribe other issues or only that issue
described better?

(Jim Schaad)  cconcept of single AS doing all the authorization on all the RS
is not correct, several AS that need to cooperate.

(Mike Jones)  this is far from OAuth

(Jim Schaad)  yes. the issue is tricking you into giving me the permission I
shouldnt have.

(Ludwig Seitz)  try to explain the problem: get the AS to issue the token. then
the attacker get to issue another token with another key, with the same key
identifier. Client submits the first token. the attacker can then trick the RS
to accept a second key linked to the same key identifier that the RS already
knows.

(Mike Jones)  even if that happens, the key will not be able to be used for PoP.

(Ludwig Seitz)  yes that's an issue that should be discussed, maybe not in this
document?

(Hannes Tschofenig)  CWT PoP is very limited in functionalities. The described
attack scenario should be described in the ACE doc. I don't think it is a
concern but implementations can make mistake so it is worth highliting those

(Russ) disagree with Hannes. Agree that ACE should describe it there, but a
warning in this document should be added here as well. What if someone
purposely maliciously does that. Should be discussed in this doc.

(Roman Danyliw)  I am going to be shepherd. I send mail last Thursday on the
remaining issues -- 3 categories: comments not "closed", comments that were not
in the doc, comments adressed. Walk through the list to check.

(Mike Jones)  will do. If people think that aditional things need to be said,
please provide text about it, so that we can add that.

EST over secure CoAP (EST-coaps)
================================
presenter: Peter van der Stok
draft: draft-ietf-ace-coap-est
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-est-over-secure-coap-00

van der Stok presented the background and recent updates for EST-coaps.  He
noted that there were no comments on: -- Long delay handling (sl 4) --
multipart payload (sl 5)

Ideally an interop can be done in the next 3 months

(Mohit Sethi) sl. 4 Can you not block this from the server and you will still
run in this same problem?  or is POST a CON POST?

(Peter van der Stok)  Yes it is confirmable

(Hannes Tschofenig)  why did you have to include the multipath part?

(Peter van der Stok)  First part you get cert request and server sends back
content format and (missed it) They both come from the server.

(Hannes Tschofenig)  original model did not require the multipath. Is it
because you are passing the certificate and the key as well.  (Server side key
generation is the cause of this)

(Peter van der Stok)  yes

(Hannes Tschofenig)  I was never in favor of this because of security. Is it
mandatory to implement?

(Peter van der Stok)  yes. Haven't said either mandatory or optional. we might
think about that.

(Hannes Tschofenig)  client req feature and server doesn't provide, it could
send an error, I think that would be good. I am still thinking that the
argument that provoked this multipath is dubious.

(Hannes Tschofenig)  Want to use TRNGs on IoT devices

(Peter van der Stok)  Yes but we also are going to handle old devices.

Core Framework and Profiles
===========================
presenter: Ludwig Seitz
drafts: draft-ietf-ace-oauth-authz,
        draft-ietf-ace-dtls-authorize, and
        draft-ietf-ace-oscore-profile
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-ace-authorization-and-authentication-framework-and-profiles-00

Seitz presented an updated to the drafts based on comments and the interop.

(Hannes Tschofenig)  clarification: presence of CBOR unchanged, but the use of
CBOR is

(Hannes Tschofenig)  follow up on sl 4: we will have a discussion in OAuth wg
about this. If anyone is interested, come to that meeting.

Discussion points per sl 5:
-    key identifier (discussed before)
-    alignment with OAuth: go to meeting on Thursday
-    All the param currently in the framework are either in OAuth or RFC7800 +
profile. Open to discussion which ones of those are unimportant enough for a
larger abbreviation:

(Carsten Bormann)  You can waste a lot of time discussing this. Someone should
just write down a proposal

(Mike Jones)  my suggestion is to work with the designated experts for CWT
claim registration and then make a proposal, and get their feedback. Now rather
than when this is done

Discussion per RD attributes for AS discovery:
(Carsten Bormann)  how a RS can send the info about how to get the AS.  Can
define a new relation type to hold this information and what it would look like.

(Ludwig Seitz)  have this in this draft or in a different draft?

(Carsten Bormann)  worthwhile independent effort. should be something basic
about what a RS does for unauth req

(Ludwig Seitz)  currently I removed the direct ref to RD. "you are allowed to
use other mechanisms"

(Peter van der Stok)  I agree - keep it an independent document.

Question: Are we ready for WGLC?

(Jim Schaad, as chair): we need to get an update with all the comments. Let's
shoot for september

(Carsten Bormann)  did we have a version of this for implementation?

(Ludwig Seitz)  not explicitely

(Carsten Bormann)  Maybe we should do that for next version

(Ludwig Seitz)  implementations: one by me, one by Jim, Olaf is working on a
constrained impl, Hannes has one (partial C-RS is CoAP but AS interactions are
HTTP based), SEI lab has an unconstrained version on my code and a constrained
version in developement, one from RISE for Contiki. We want to do more interop

(Roman Danyliw)  September we will start the WGLC (after update)

Group Communication
===================

Key Provisioning for Group Communication
----------------------------------------
presenter: Francesca Palombini
drafts: draft-palombini-ace-key-groupcomm
      : draft-palombini-ace-coap-pubsub-profile
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-group-key-provisioning-00

Palombini provided an update on the key provisioning and pub-sub drafts.

-- Major update: Retrieval of updated keying material.
-- Open Issues: 3 choices, Issue of how to combine a request for the public
keys of others with a request for an update of the simmetric key.

(Jim Schaad)   Pefer not to use the different resources and do it in a message.
 Need to think about this for how to do as resources.

(Peter van der Stok)   Why are there two drafts on group communication rather
than a single draft.

(Roman Danyliw)  Initial request from the group was to separate the model from
the details of how to do in a specific profile

(Roman Danyliw) Can make some decisions if the WG decides to adopt them.

(Chairs) Want to get the Oauth-Authz document published before pulling in new
work.

Joining OSCORE groups
---------------------
presenter: Marco Tiloca
draft: draft-tiloca-ace-oscoap-joining
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-ace-joining-00

Tiloca presented an update on the draft-tiloca-ace-oscoap-joining draft.

(Peter van der Stok)  Want to express the interest in this draft and hope it
goes on smoothly

(Roman Danyliw) WG will defer adoption after the framework is done, same as the
drafts Francesca presented

Resource Directory Authorization Issues
=======================================
presenter #1: Peter van der Stok and Carsten Bormann)
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-resource-directory-authorization-issues-00
      :
      https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-resource-directory-permissions-part-2-00

van der Stok and Bormann presented the motivation for discussing resource
directory authorization to stimulate discussion in the WG.  The chairs framed
the discussion in slide #7 of their intro materials.

(Jonhatan Hammel) for cert id to align with CMS, you would use issuer and
serial number

(Mohit Sethi) Way too complex for a problem we have seen in many places.
Encourage using something completely random. What requirements you have on the
endpoint name, human readable? I think this is way too complex

(Hannes Tschofenig)  similar problem seen before: identifier at 2 different
layers: (D)TLS and CoAP RD. The problem was at higher layer you have a non
authenticated (the CoAP). My proposal was getting rid of that. Your solution is
binding those, which is possible, as long as you make sure that they are the
same, then it's not a problem. But then why do you have to send the same thing
twice?

(Matthias ) I agree with Hannes. Question: one way which is Ace related, but
there are other ways right?

(Peter van der Stok)  I am not aware

(Matthias ) we need authorization for RD, that is clear, and your way uses ACE,
but there are other ways.

(Hannes Tschofenig)  another issue: 3rd party registration. In my opinion it
doesn't work exactly as you describe it.  Security story is harder here.  Need
to be able to do multiple registerations in a single security session.

(Hannes Tschofenig)  interesting. I think you are shoveling the problem around.
Discussion is "do we need this endpoint name" the answer cannot be "there are
all these things that we can talk about instead" Yes there are also sorts of
complicated problems, some of which are unsolvable. But if we can just solve
the simpler "what is the semantic of the endpoint name". I fear that if I pick
up Leshan, I will get that server to trick me (...)

(Carsten Bormann)  problem is that  if we only solve that problem the people
are going to start to encoding other things with that. Not a good thing

(Jim Schaad)  CWT expand the scope to be a binary value. There is a potential
problem that we don't have standardized way to structure data. I am trying to
figure out 1) Are we asking the group to solve a particular problem with RD or
are we trying to solve the more general problem? in the latter case I have an
issue trying to understand what the general problem is from Peter's presentation

    Can you tell me what the general problem should be?

(Kerry ) the following: DNS. Things come out of the box, and we need to give
them to the clients and we need to be (...)

(Roman Danyliw)  one sentence?

(Kerry ) No human in the loop.

(Ari ) if protect endpoint or semantics, I think we should protect both. I
think we have a problem to solve right now with EP ID, but I think we need to
then continue. I like the idea to have a way to protect RD semantics, but it
shouldn't be the only way.

(Carsten Bormann)  initial assumption AS and RD so that all of this can be done
behind the scene. Now we are trying to see how.

(Kerry ) questions: 1) should protecting the information (from RD to AS) also
extends to the client itself when you ask the client what it supports? 2) sign
collection of links that come back?

(Carsten Bormann)  maybe we need to be careful on preserving ways of using RD.
2) we have to protect shared resource. Slightly different objectives.

(Jim Schaad)  another problem: when you ask a RD it will return bits and pieces
in different places.

(Carsten Bormann)  Maybe we want to change that. Bring back to the wg

(Hannes Tschofenig)  I don't think scope is the right thing to use. More about
the client information. It should go into a different structure.

(Carsten Bormann)  scope pertains to the client

(Hannes Tschofenig)  yes but CWT scope has a different semantics

(Padhu ) (...) if we are able to achieve the context between endpoint and RD,
that context remains constant.

(Carsten Bormann)  Are you saying We need to be able to have a local id?

(Padhu ) Yes

(Matthias ) Got confused so I'd like to summarize the problem. With PoP tokens,
a client can prove a certain claim is true. AS can grant authorization to an
RD, but it is up to the client to prove that the client can use this endpoint
name. The AS has no say or even knowledge about the endpoint name claim. There
must be something like a cert saying the client is allowed to use a certain
endpoint name. My point is to separate this: AS allow the client to reg to the
RD, but it is not the AS that proves endpoint name is true.

(Carsten Bormann)  so second issue

(Matthias ) Yes this is more complex to dynmically attest an endpoint name. We
need to start with a simple solution that solves the two problems at hand:
getting authorized to register with an RD (ACE can help here) and proving the
registered information is true. Let's not entangle these two different issues.

(Carsten Bormann)  useful observation

(Matthias ) start with something simple: client has a key that proves the
information being registered -- in particular the endpoint name -- is true, so
that you don't need Ace. So go back to simple proposal such as certs by Hannes.
Second part is to use ACE to get authorized to register with a third-party RD.
And 3rd part for the future is to look into dynamic attestation that registered
information is true.

(Jim Schaad)  one topic which has impact and we have not discussed: groups

(Carsten Bormann)  2 parts: 3rd party control who is member of a group and
member

(Dave Thaler) similar to what Matthias said. outside of IETF.

(Hannes Tschofenig)  discussion about this later today as a bar bof 6pm  This
is the EAT BOF

(Kerry ) Separating the accuracy of info and the auth info that goes into the
RD: do you want to limit the RD

(Carsten Bormann)  This is about integrity not privacy

(Michael Koster) We have been doing some discussions about allowing things to
be registered in the RD which would not be part of .well-known/core.  This may
be something that needs to be discussed.

(Ben Kaduk, as AD) Thanks for having this discussion.

(Roman Danyliw) In summary, the feedback is that the WG needs to consider group
communication, but any approach should "keep it simple."  See slide #8 of
chairs's slides.

EDHOC
=====
presenter: Göran Selander
draft: draft-selander-ace-cose-ecdhe-09
slides:
https://datatracker.ietf.org/meeting/102/materials/slides-102-ace-edhoc-00

Selander presented an updated on the revisions to EDHOC in the -09 draft.

Closing
=======
discussion lead: chairs

The WG chairs summarized discussion as follows:

** draft-ietf-ace-cwt-proof-of-possession -- authors should respond to
outstanding issues posted by Document Shepherd on ML (07/12/2018) **
draft-ietf-ace-oauth-authz -- publish revised draft to address feedback; WGLC
in September 2018 ** Group Communication Individual Drafts -- continue work;
deferring WG adoption discussion until framework documents progress ** Resource
Directory Authorization Discussion -- more discussion required on problem and
solution