Minutes IETF101: ace
minutes-101-ace-00

ACE WG
IETF 101
Monday March 19, 2018 0930h-1200h

Note Well and Agenda Bashing
============================
presenters: chairs
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-chair-slides-00

The chairs provided an update on the status of the working groups and its
drafts.

Comment: (Hannes Tschofenig) There is a related meeting, ATLS, at lunch today. 
I'll send information to the mailing list.  The background is as follows --
https://tools.ietf.org/html/draft-friel-tls-atls-00.

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

Jones summarized the changes made to -02 based on review comments.  The editors
believe that this draft is ready for WGLC.

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

van der Stok summarized the changes made in the -00 version and identified open
issues.

BRSKI modes
https://trac.ietf.org/trac/int/wiki/EnrollmentRoadmap

Q (Hannes Tschofenig): Can you explain server key generation?  This might not
be a good practice. A: (van der Stok): We received feedback (Panos Kampanakis)
that this was important.  The transport protects it. A: (Max ) The server key
generation was brought it to support RPKI mechanism A: (van der Stok) So you
believe this use case should be better explained? A: (Max ): Yes.

Comment: (Tschofenig): You might want to keep CoAP response codes separate --
not as a normative reference in the draft.  It would be better to get things
out into deployment.

Protecting EST payloads with OSCORE
===================================
draft: draft-selander-ace-coap-est-oscore
presenter: G?ran Selander
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-protecting-est-with-oscore-00

Selander summarized the changes in this rewritten draft that should now better
aligns with EALS.

Q to WG (by Selander): Was this the change you wanted?
Q (Kaduk): Who has read the draft?
A: [6 - 8 people]
A: (Kaduk): More people need to read it

Authentication and Authorization for Constrained Environments (ACE)
===================================================================
draft: draft-ietf-ace-oauth-authz
draft: draft-ietf-ace-dtls-authorize
draft: draft-ietf-ace-oscore-profile
presenter: Ludwig Seitz
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-ace-authorization-and-authentication-framework-and-profiles-00

Seitz summarized the changes from -08 to -10 of draft-ietf-ace-oauth-authz.

Seitz summarized the changes from -02 to -03 of draft-ietf-ace-dtls-authorize;
and identified next steps.

Comment (Hannes Tschofenig): I like the work on curve Ed25519, but it might be
a rush to make it mandatory.  Perhaps make it optional. A: (Olaf Bergmann): I
added it because no one objected in Prague A: (Schaad) What are the MTI for TLS
v1.3? A: (Tschofenig): I created a profile that mirrors TLS v1.3.  However,
many of these are not currently implemented in IoT because the hardware is
likely not ready A: (Kaduk): A: (): If we don't mandate Ed25519 now, they when?
 What would a transition phase look like? A: (Tschofenig): Agreed.  However, it
would be bad that no implementations would support it.  A transition phase
would be helpful. A: (Seitz): The positive of making it MTI, that would force
implementation. A: (Carsten Bormann): MTI might be less useful in this
environment.  We should start a concerted effort to revisit all algorithms
specified, almost like a CURDLE process. A: (Olaf Bergmann): +1 on review of
crypto algorithms.  There are open source implementations.  It makes sense A:
(Seitz): We also need to get it (ed25519) into the DTLS libraries.  It may take
a while. A: (): +1.  Other curves are already in and added to libraries.  What
is our goal in making this curve MTI?  It may present a barrier to adoption. A:
(Kaduk): We need to take this algorithm discussion to the list. A: (Seitz): A
decision would be helpful here. A: (Bormann): What would that mean? A: (Seitz):
Which curves should be MTI? A: (Bormann): This decision will require
coordination -- this isn't an ACE decision alone. A: (Seitz): Coordinate with
whom? A: (Bormann): For example, CORE.

Comment: (Seitz): We need more review.

Seitz summarized the changes from -02 to -03 of draft-ietf-ace-oscore-profile.

Q: (Seitz) Any volunteers to help with Token Binding work at OAuth?

Hannes Tschofenig and John Bradley were volunteered.

Q: (Seitz) Is there a (or do we want a) relationship to the OCF work?
A: (Dave Taylor): There was a meeting in Prague on Friday on OCF.  We will be
discussing how to coordinate across SDOs. A: (Kaduk) Was there also a virtual
meeting earlier?  Did something interesting happen? A: (Bormann): We are
holding coordination meeting every 6 months.  ACE security work and OCF is a
known issues, but has not been resolved.

Q: (Seitz) to WG: Should we do a WGLC?
A: (Tschofenig): I think it would be good to do a WGLC soon.  We need better
prototype implementations, especially open source, to help.

Q: (Seitz): Hannes you promised a paper on the analysis of the client token
functionality. A: (Tschofenig): the paper is published --
http://st.fbk.eu/sites/st.fbk.eu/files/osw2018-ace.pdf.  Additional relevant
papers can be found at https://st.fbk.eu/osw2018/program.

Q: (Kaduk): Who wants to see the client token work continue?
[room is quiet]
A: (Goeran Selander): There is missing functionality related to client
authorization -- the data going to the client about what it is supposed to do. 
For example when you authorize keys for group communication.

The chairs plan to discussion when to conduct the WGLC offline.

Key Provisioning for Group Communication using ACE
==================================================
draft: draft-palombini-ace-key-groupcomm
presenter: Francesca Palombini
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-group-key-provisioning-01

Palombini introduced draft-palombini-ace-key-groupcomm -- scope and

Q: (Seitz): Per slide 3, you noted that the KDC doesn't exist in ACE.  I
believe it does. A: (Palobinia): Yes, it does, but the flow in slide 5, does
not.

Q: (Bormann): What is the claim made about the public keys in the KDC?
A: (Palombini): KDC will store and distribute the public keys.  The draft does
not specify how these keys are used. A: (Bormann): Understood.  We should
specify this somewhere.

CoAP Pub-Sub Profile for ACE
============================
draft: draft-palombini-ace-coap-pubsub-profile
presenter: Francesca Palombini
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-pubsub-profile-for-groups-00

Palombini summarized the updates in -02 of
draft-palombini-ace-coap-pubsub-profile.

Q: (Eve Mayler): Per slide 8, you've defined a standardized interface for KDC
which is a function of the AS that is OATH protected.  That makes it an RS? A
(Palombini): It does not do authentication. A (Mayler): To clarify, is my
understanding right?  I've written a spec that has a very similar design
pattern. A: (Palombini): Yes.

Q (Palombini) to WG: Do you still support this work?
[no feedback]

Joining of OSCOAP multicast groups in ACE
=========================================
draft: draft-tiloca-ace-oscoap-joining
presenter: Marco Tiloca
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-joining-oscore-groups-using-ace-01

Tiloca summarized the changes made from -02 to 03 of the draft.  This revision

Q: (Tiloca): Is this draft ready for WG adoptions.
A: (Selander): There is interest to create protocols for simple devices.  This
draft could solve some of these problems. A: (van der Stok): I support this
document.

Key exchange for OSCORE
=======================
presenter: G?ran Selander
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key-exchange-w-oscore-00

Selander contrasted the options to a key exchange protocol with OSCORE --
Option A: reuse transport layer security at application layer; or Option B: a
compact key exchange protocol using CBOR and COSE.

Q: (Selander): Per Slide 6, ..
A: (Michael Richardson): The result of not having a key exchange will be
reduced security.  We deployed a variety of protocols without security
protocols before.  It is unfair to say that there has been no security
analysis. A: (Selander): Yes, but there haven't been papers. A: (Richardson):
Bugs will be found after reviews are done.  Thanks for slide 5.  Did you run
the numbers on raw public keys?  What was the overhead?  How can raw PSK be
less than the public keys? What keys? A: (Schaad): 256 ED25519

Q: (Malisia Vucinic(?)): From the experience of 6TiSCH, I support Richardson's
comments.  TLS isn't ready on our timeline.

Comment: (Tschofenig): You are asking us to re-implement TLS on CBOR/COSE.  The
reason TLS looks as it does, the standards process added various
features/functionality.  That functionality then needs to be maintained by
implementers.  These changes add more work. A: (Bormann): We are implementing
these features in open-source projects.  Time to market is an important
differentiator of companies. A: (Tschofenig): I appreciate your research
implementation.  You are down-playing the investment required.  It takes us a
long time to right solid implementations.  We want to reuse code.  Shaving off
a few bytes and adding others requires reuse that we're not seeing demand for
in our customers. A: (Vucinic): The companies we are working with are
interested. A: (Bormann): I agreed that we need implementations that are
production quality.  Counting open source implementation isn't enough.  TLS
doesn't currently do what we need it to do.  We need an adapter. A:
(Tschofenig): The adapter is a key extractor.  It has been used.  I'm still
waiting for deployment of OSCORE.

Comment: (Kathleen Moriarty): Thanks for your work measuring the byte sizes. 
The IoT market is large enough for different architectures.  I'd like to see it
continue.  There is sufficient time to still perform security analysis.

Scope of ACE Authorization Work
===============================
presenter: G?ran Selander
slides:
https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-scope-of-authorization-work-00

Selander framed discussion on the scoping and defining around the next steps of
the authorization work across all of the WG and individual drafts given the ACE
framework.

Comment: (Seitz): As to the ACE mode of operations, let's not limit ourselves
to just what we have adopted as of now.

Q: (Schaad): How soon is pub-sub going to be done in CORE?
A: (Bermann): There is confusion about terms.  The pub-sub profiles are a bit
different from the way they are being described in ACE.  Interest is picking up
-- perhaps a half year to address issues. A: (Schaad): What about OSCORE draft?
 That's still an individual draft? A: (Bermann): It has been adopted.

Q: (Kaduk): Any opinions -- we have open mic time.

(Bermann): When we started, we had an idea of the problems to solve. We agreed
OATH would be a starting point.  I would like to complete that work and then
move on to new work.  We should do new work too on authorization/authentication
in IoT. More discussion is required.  We are not done as a WG.

(Tschofenig): Why are people already talking about closing down the WG.  The
drafts aren't finished.  I concur that we should reassess what else has
happened since we tried to understand the problems.  For example, in the home
IoT there hasn't emerged a big interest in standardized solutions.  The
industry IoT has shown interest.  We should double-check which original ACE use
cases are still applicable and let that guide the future work.

Wrap Up
=======

Q: (Kaduk): Who has read the EDHOC draft?
[about 15 people]

Q: (Kaduk) Are you interested in adopting the EDHOC document?
[Moderate strength hum to support adoption]

Q: (Kaduk) Are there specific technical objections to EDHOC (not business ones)?
A: (Tschofenig): I would be interested to see the detailed numbers posted to
the list -- the protocols have different features.  Message size is not the
only feature to measure for performance. A: (Kaduk): Yes, the numbers will be
posted and we should discuss on the list.

Open Mic
========
Comment: (Tschofenig): I will post an article from Networking Magazine about
problems we are encountering in the IoT space.  This creates a conclusion by
the public that the IETF work is not done and not ready.

Comment: (Moriarty): It doesn't appear that any technical objections were
voiced to EDHOC.  To confirm, it is going to the list to discussion? A:
(Kaduk): Yes (on both).

Comment: (Selander): This isn't about replacing TLS -- double stacks.