Minutes IETF103: ace
minutes-103-ace-00

ACE WG Minutes
IETF 103

Thursday, November 8, 2018
16:10-18:10, Afternoon session II

Minutes taker: Ivaylo Petrov

Introduction and Status Update
==============================
presenters: Jim Schaad and Roman Danyliw
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-chairs-summary-04

The chairs presented the status of the WG -- recent WGLCs
(draft-ietf-ace-oscore-profile, draft-ietf-ace-authz, draft-ietf-dtl-authorize
and draft-ietf-ace-oauth-params); and drafts in shepherd review
(draft-ietf-ace-cwt-proof-of-possession).

ACE-OAuth
=========
presenter: Ludwig Seitz
draft: draft-ietf-ace-oauth-authz
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-ace-oauth-and-additional-oauth-parameters-for-ace-01

Ludwig Seitz presented changes made to the framework draft from the -13 to -17
revisions and led a discussion on open issues.

Per Slide #3, Discussion Point #1: Use of low-digit abbreviation
-- no feedback from the WG

Per Slide #3, Discussion Point #2: Unified registry of CBOR abbreviations

Comment: Mike Jones (Microsoft): I believe that has been discussed in the list
and there should be separate numeric spaces for claims and parameters.

Comment: Jim Schaad: The RATS BoF also discussed registering CWT claims.  We
would benefit from a common story.  Likely we should register maps then
everyone could get their own registry.

Q: Carsten Bormann: How many media types you have?
-A: Ludwig Seitz: There is one media type defined.
-A: Carsten Bormann: How do I know its CWT then?
-A: Ludwig Seitz: It is sent as a parameter in the message.
-A: Carsten Bormann: The important thing is that the thing claim received
should be formed as a CWT

Per Slide #3, Discussion Point #3: CWT as format for signed protocol messages

Comment: Ben Kaduk: Thinking about as CWT as signed claim messages, the ACME
just started using JWTs for all signed messages.

Comment: Mike Jones: As discussed on the list, use of JWTs as signed protocol
messages is being standardized by OpenID Connect and the OAuth WG.  Given that
ACE is trying to reused as much of OAuth as possible, it makes sense to use CWT
as signed messages. -A: Ludwig Seitz: Isn't there contention in the OAuth WG
about whether all messages should be JWTs.  Isn't it only for introspection
purposes? -A: Mike Jones: The OAuth draft is strictly scoped to the
authorization and responses.  OAuth isn't doing it for introspection at
present. -A: Ludwig Seitz: My concern is aligning with OAuth could delay
publication of the ACE framework. -A: Mike Jones: You are not going to
introduce a normative reference.  It would be a non-normative reference. -A:
Jim Schaad: I don't think we even need the informational reference, unless we
want to document that we are going to carry those messages in the framework -A:
Ludwig Seitz: Do you expect that this would be an additional draft that
describes the CWT representation? -A: Jim Schaad: Right.

Per Slide #3, Discussion Point #4: Alignment with OAuth

Comment: Hannes Tschofenig: We try to be more specific in the resource
identifier it makes the implementation simpler on the resource server because
there is a standardized way to do the comparison.  Otherwise you have to have
out-of-band communication in order to describe the semantics.  The current
approach makes the comparison more precise. Do you have a use case that needs a
more relaxed description? -A: Ludwig Seitz: No, I don't have such a use cases. 
The challenge I was addressing is that the URLs of constrained devices change
when they travel (move from one network to another).  It makes it tricky to use
this resource identifier. -A: Hannes Tschofenig: I see.  Good question. -A:
Ludwig Seitz: Let's continue this discussion on the mailing list

Q: Jim Schaad: Is the confirmation text well aligned?
-A: Ludwig Seitz: It is.

Per Slide #4, Discussion Point #5: Multiple tokens for one RS and client
How should the RS handle it?  Option #1: New token amends; Option #2: New token
overwrites.

Comment: Ludwig Seitz: the draft currently implies Option #1, but Option #2
would be simpler.  Would anyone have strong feelings with Option #2? -A: Jim
Schaad: I don't have a strong feeling, but there are two things I want to
raise. Many times the newer tokens is for a shorter-lifetime, so it might be
expired sooner. I know there is a draft in oauth WG for incremental updates.
-A: Ludwig Seitz: We should take a look at that.

Comment: Olaf: +1 for option 2.

Per Slide #4, Discussion Point #6: Expiration of tokens based on sequence
numbers for devices with no internal clock

Comment: Ludwig Seitz: Not very secure and as it is not probable.  This
mechanism seems obsolete and I would recommend to remove that.  Any opposition?

-- No concerns raised.

Per Slide #4, Discussion Point #7: Symmetric cnf keys and multi RS audiences

Comment: Ludwig Seitz: Might lead to impersonating. Should we recommend against
using symmetric cnf keys in multi resource servers? -A: Jim Schaad: Recommend
the text recommend SHOULD NOT and wait for use cases to think against about it.
-A: Ben Kaduk: I would be pretty uncomfortable to allow, so we'd need a good
use case to proceed. -A: Ludwig Seitz: Is SHOULD NOT strong enough? -A: Roman
Danyliw: Perhaps MUST NOT or NOT RECOMMENDED? -A: Ben Kaduk: It would depend on
the rest of the text. -A: Ludwig Seitz: Let's go to the ML for further
discussion.

NEXT STEPS: (Jim Schaad): When could the next version of the draft be published?
-A: Second-half of December 2018

DTLS Profile for ACE
====================
presenter: Göran Selander
draft: draft-ietf-ace-dtls-authorize
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-dtls-profile-for-ace-00

Göran Selander presented updated made in the -05 version of the DTLS profile
draft and led a discussion around WGLC feedback.

Per Slide #3 (WGLC #1)

Q: Hannes Tschofenig: Is the client supposed to send the key ID to the AS or
the other way around? -A: Göran Selander: It is the AS -A: Hannes Tschofenig:
But the AS can provide that key ID already. -A: Göran Selander: This was
missing in the text -A: Jim Schaad: This issue has been overtaken by events, we
should use refresh tokens without using the key ID. -A: Göran Selander: Do we
need a special case for RPKs.  It's the same, so no

Per Slide #4 (WGLC #2)

Comment: Göran Selander: I'm not sure if I understand the question in this WGLC
feedback -A: Hannes Tschofenig: JWT answer to this is to include an algorithm
id. -A: Göran Selander: That is easy to address.

Per Slide #5 (WGLC #3)
-- No feedback

Per Slide #6 (WGLC #4)

Q: Jim Schaad: I don't remember this proposal being in the reviewed drafts and
don't know what it does. -A: Göran Selander: It transport the salt.  Use the
key shared between AS and RS to derive the key. -A: Hannes Tschofenig: Is this
a good idea? You are adding another key derivation approach that needs to be
implemented?  It would be good if the JWT and CWT functionality matches. -A:
Göran Selander: Yes this approach is typical for 6tish where a CWT doesn't fit
in one segment.  It's the constrained use case. -A: Ludwig Seitz: It also has
the advantage that an attacker who learns the content of the cnf claim can not
derive the key. -A: Hannes Tschofenig: There is an assumption of
confidentiality between the client and AS already. -A: Göran Selander: This
would be encrypted and this wouldn't only have to be integrity protected. -A:
Jim Schaad: Yes, it which will already be encrypted. I am worried about
possible problems with the keys being protected correctly. You are adding a key
derivation on a secret that was meant to do something to do something else. -A:
Göran Selander: Agreed.  The intention was to use a derived key.  I'll check if
it is written in the draft.

Q: Göran Selander: The question is how would the cnf look like (not whether the
method should be used). -A: Hannes Tschofenig: From the JSON version/JWE, there
is an unencrypted version or not.  Do you want an encrypted and not encrypted
version? -A: Göran Selander: No, not encrypted, but it could be. -A: Hannes
Tschofenig: Is it a key container or a JWE.  But then you'd need a wrapper. -A:
Göran Selander: It used to have that in the COSE key container. We realized it
is not a good idea. -A: Jim Schaad: You are missing a layer in your example.
-A: Göran Selander: Yes, reading your review you made that clear.

NEXT STEPS: (Roman Danyliw): When could the next version of the draft be
published? -A: December 2018

OSCORE Profile for ACE
======================
presenter: Francesca Palombini
draft: draft-ietf-ace-oscore-profile
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-oscore-profile-of-ace-02

https://www.youtube.com/watch?v=hx1SdnOROUE
56:21

Francesca Palombini summarized changes to the OSCORE profile draft made in -05
and led a discussion around WGLC and related open issues.

Per Slide #3:
Q: Francesca Palombini: Are there more situation where the client or the server
needs to discard their security context? -- none heard -A: Francesca Palombini:
If you have ideas, please send them to the mailing list

Per Slide #4:
Q: Francesca Palombini: IANA registry creation with Expert Review Required for
parameter registration.  Is there feedback? -- none heard

Per Slide #5-16, the client and the RS can forget the sec ctx and they might
forget the tokens. The client can get an old, non-expired token from AS.  
There might be place for an replay attack if the RS loses it's security ctx. To
solve this, we add a nonce from the RS to the client.  The usage of nonce is
now mandatory.  There are three options.  Option #3 is preferred but requires a
change to the ACE framework (instead of just the payload, send a map).

Comment: Ludwig Seitz: Like proposal 3.  We need to define a new content type
for sending CWTs directly (ACE+CWT). Profiles that use auth end point can use
this new content type. -A: Francesca Palombini: However, in the ACE framework,
the content format ACE+CBOR is only defined for client-to-AS and vice versa,
but not client-to-resource server. -A: Ludwig Seitz: That is an oversight. I
will create an issue. -A: Ben Kaduk: In terms of cryptographic usage, proposal
3 is the best.

Comment: Carsten Bormann: I am confused as to what just got said about media
types. There is CWT media type. What do you want to define?  "+CWT" doesn't
exist. -A: Francesca Palombini: I said I want to define ACE+CBOR to send a CBOR
map (of a nonce and CWT).  Ludwig said he will update the framework for ACE+CWT
to sent just a CWT. -A: Carsten Bormann: Let's take that offline.

Comment: Mike Jones: In the secevent WG, they just finished the security token
draft which was the first to use a +JWT media suffix (secevent+jwt).  Hence, it
wouldn't be unheard of for such a draft to introduce such media type and you
can copy the text from the secevents draft. -A: Francesca Palombini:
Understood.  This still seems related to the previous conversation with Ludwig
and Carsten on media format.

Comment: Francesca Palombini: I heard people like option 3, which is great.

Per Slide #17:

Q: Jim Schaad: Is there a problem with using a content type with a created
response? -A: Francesca Palombini: No. -A: Ludwig Seitz: I don't see a problem
with that. -A: Carsten Bormann: I also don’t see a problem.  As long as the
media types doesn't start to mean something different.

Q: Francesca Palombini: Nonce is only registered for AS-to-client response. 
Can it be made more general? -A: ?: Yes.

NEXT STEPS: (Roman Danyliw): When could the next version of the draft be
published? -A: Early December 2018

PoP Key Semantics for CWTs
==========================
presenter: Mike Jones
draft: draft-ietf-ace-cwt-proof-of-possession
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-pop-key-semantics-for-cwts-00

Mike Jones presented changes made to the PoP draft based on WGLC feedback and
identified the outstanding issue.

NEXT STEPS: (Chairs): When could the next version of the draft be published?
-A: in the next few days

EST over secure CoAP
====================
presenter: Michael Richardson
draft: draft-ietf-ace-coap-est
slides:
https://datatracker.ietf.org/meeting/103/materials/slides-103-ace-est-over-secure-coap-draft-ietf-ace-coap-est-00

Michael Richardson presented updates made in the -06 of the EST over secure
CoAP draft, and feedback from multi-party interop testing.

Q: Michael Richardson: this draft has applications in particular vertical use
cases.  There is concern that this draft won't survive IESG review without more
text on why this approach is secure.  However, detailing the use cases may be a
rat hole. -A: Hannes Tschofenig: Our use cases is for device management for
IoT. -A: Michael Richardson: Do you think we should include this use case in
the draft. -A: Hannes Tschofenig: We are open about this use case.  This use
case horizontal across many vendors. -A: Michael Richardson: Between vendor and
customers; not "internet level" interoperable - having different manufacturers,
customers, etc. -A: Hannes Tschofenig: We provision at device manufacturing

Comment: Jim Schaad: EST is secure by TLS.
-A: Michael Richardson: Yes.
-A: Jim Schaad: You aren't talking about securing in the channel but how you
get trust in the channel -A: Michael Richardson: Correct. -A: Jim Schaad: No, I
don't think we need to add text. -A: Christen: You could describe in certain
details how a person buys a widget and how it is registered. The concern with
this use case is likely if that person wants to reset that device and then how
the manufacturer would support it. -A: Michael Richardson: This protocol has
none of that. There is no magic, only a static list of clients and servers. -A:
Christen?: ? -A: Hannes Tschofenig: I don't worry about future IESG comments on
that.

(Roman Danyliw) Does anyone disagrees that this draft is ready for WGLC?
-A: Peter van der Stok: Has edits to make.

NEXT STEPS: (Roman Danyliw): When could the next version of the draft be
published? and the basis of a WGLC? -A: Early December 2018

New Work Adoption
=================
The chairs engaged the WG to under the level of interest in adopting three
draft related to group communication.  Adoption on these drafts has been
deferred in recent meetings pending progression of the early documents to WGLC.

For each draft three questions were asked:

** (as a hum) Is it worthwhile to do -- adoption? should not do? don't know?
** Would you want to review it?
** Would you want to implement it?

Comment: Francesca Palombini: Before we discuss the second draft, as an author,
I want to make it clear that it hasn't been updated recently or prioritized. 
It was also delayed due to work in CORE. -A: Roman Danyliw: Are you
recommending we don't call for adoption? -A: Francesca Palombini: Your decision.

draft-palombini-ace-key-groupcomm
---------------------------------

** adoption hum: considerable humming for adoption, some for not knowing.
** reviewers: ~6
** implementers: ~3

draft-palombini-ace-coap-pubsub-profile
---------------------------------------
Comment: Carsten Bormann: This is a comment on group communication.  I'm not
sure if CORE not making progress should prevent us from moving forward.

** adoption hum: loudest on "no idea"
** reviewers: ~4
** implementers: none

Comment: Jim Schaad: Most people seem to have no idea. Would anyone who hummed
no idea want to explain what they would need to make a decision? -A: Göran
Selander: This is important work.  However, it hasn't been prioritized.  Let's
visit at a later meeting.

draft-tiloca-ace-oscoap-joining
-------------------------------

** adoption hum: hums heard in favor of adoption and don't know
** reviewers: ~5
** implementers: ~2-3

Open Mic
========

Comment: Ari Keraenen: I understand that pubsub is of lower priority.  However,
it is planned to be finished, so it will be a pity if the work is abandoned.
-A: Jim Schaad: I have been hearing this for quite some time. I would like a
substantial updates. -A: Ari Keraenen: There is a substantial progress and
implementation.  I hope we will be able to push it through the final line soon.

Q: Ludwig: There was prior discussion (and a draft) on ACE with MQTT?  Is there
interest?  My impression is MQTT is commonly used. -A: Jim Schaad: My
understanding from the authors of that draft was that they weren't ready to
take it to a WG yet.

Comment: Hannes Tschofenig: It would be nice to see more productions
implementations of ACE.  What I see is prototype implementations. It is one
thing to push through documents quickly (or relatively quickly). -A: Carsten
Bormann: If I had the money to invest in a product, would I implement it and
hope that in 2-3 years the IESG will accept it? We are damaging the reputation
of being able to push things through. Pubsub is just an example application,
but there are other examples as well, which would benefit from standardized
solutions. Maybe this has been represented differently from how it is going to
be used. I am not sure it will only be used in pubsub. -A: Zach Shelby: I
disagree with Carsten.  We should build real application for real people and
get that experience.  We don't need a completed drafts for implementations.  I
see feature creep in IoT drafts -- more at every meeting. -A: Hannes
Tschofenig: We have been deploying CoAP over TCP for some time before it was
finished. We had some problems with different versions, but it is possible. -A:
Carsten Bormann: I agree there is a problem with the deploy-ability of the ACE
stack. We now have something that might be workable. I am not sure having a
product is requirement for having a standard. We are working with other SDOs
that are looking to the IETF for building blocks.  Only some may be successful.
 Are we interested in implementing shouldn't be the gating function. -A: Zach
Shelby: I want to see implementations (not necessarily products) that are
deployed. It has nothing to do with ARM, Ericson, etc. Other SDOs should be
kept to the same standard - there is also feature creep there as well. This is
not only ACE thing, but more IoT level problem.

Comment: Göran Selander: The group communication is not a feature creep. People
are asking for it - when can we have this? I don't see a problem here. -A:
Gunter: That is why OCF is talking regularly to T2T. -A: Göran Selander: I
don't see problem with people implementing things in advance or after the
protocol is specified. -A: Hannes Tschofenig: On group communication, we have
been working on and will release the code.  The draft was unfortunately
shutdown by Mike St. Jones because of not liking the symmetric keys.

Comment: Hannes Tschofenig: In LWM2M we have published version 1. We will have
a plug-fest interop event - even non-members can come. We have been using
things from the CORE WG. -A: Carsten Bormann: Where and when? -A: Hannes
Tschofenig: I think in April next year in Amsterdam or ... - I can send an
email to the ML.

Comment: Carsten Bormann: Maybe in Prague we can have more than 2 days for
plugtests as 2 days are not enough. We could for example start on Wednesday or
something.

Q: Francesca Palombini: When do you think we can have the decisions on those
works? A: Chairs: We will take things to the ML, so maybe a couple of weeks.

Closing and Summary
===================
The discussed documents will be updated per the following schedule:

** draft-ietf-ace-oauth-authz: Second-half of December 2018
** draft-ietf-ace-dtls-authorize: December 2018
** draft-ietf-ace-oscore-profile: Early December 2018
** draft-ietf-ace-cwt-proof-of-possession: in the next few days
** draft-ietf-ace-coap-est: Early December 2018 (and then WGLC)