Minutes IETF98: ace
minutes-98-ace-00

ACE WG Meeting
IETF 98 - Chicago
Monday, 27 March, 2017, 9:00 - 11:30
Chairs: Hannes Tschofenig, Kepeng Li

Note takers: Ari Keränen, Mohit Sethi

* Agenda Bashing and Status Update (Chairs, 10 mins)

Milestones need adjustment. Potentially need new milestones, depending on
discussions today. Little bit behind so need to speed up progress. CWT
milestone needs to be added. Looking for input on other documents if they
should be worked at ACE.

Virtual interim. Secure for low-latency group communication. We had a call for
adoption. Some people want to see changes. Re-scoping the document.

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

Informational doc that allways gets pushed back behind solutions doc.
Addressing review comments and submitted doc. Question (for off-line): are
there sections/subjects we want to drop in latter half? Want to compress latter
half. If opinions, please state on mailing list.

Hannes: When do you think the document is finished?
Carsten: next round availabel in May. If feedback received, might be done in
Prague.

Carsten: (agenda bashing) TUDA from last meeting could be squeezed in here

Hannes: reviewers? Elliot L and Dave T volunteered.

* CBOR Web Token (Mike Jones, 15 mins)
- https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/

Status of CWT doc.

Issue: complete examples that were self-contained. There are now examples with
full binary representations. People encouraged to try them with their
implementations.

Mike: Time for WGLC?

Hannes: objections to WGLC? Around for while already? Don't see any objections

Mike: where do we stand with COSE to RFC editor?
almost done
Ludwig: weakeness in JOSE work, and how that affects COSE and CWT?

Mike: asked to do presentation on the topic. Cases where you don't validate
input when using ephemeral key. Could gather info what implementation does with
bad input. Fixed in some Java frameworks, but want to have defense in depth.
Applications should understand if the crypto they do is valid. That's why
crypto agility

Hannes: Mike, please post info to the mailing list on the issue. Antonio did
good writeup.

Brian C: Re CWT, one issue related to crpyto agility. Algos in the body of the
token. Algo designation in control of attacker and apps not specific what they
accept. Also attack on ECDH. Requires point validation before key agreement.
Hannes: CWT one shot message. Both sides need to understand what needs to be
there. Saw implementations in WS where any algo accepted (even none). Brian:
people getting this wrong. Arguments towards not including algo agility in the
message. Need stronger text on what needs to be done. Could be more clear in
COSE. Hannes: need to have second look at the text

* Authorization using OAuth 2.0  (Ludwig Seitz, 10 mins)
- https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/

Ludwig: This is framework document. Profiles for the framework in other
documents. Review of IANA section very welcome; it's getting long.

Different meaning of end-point in Oauth and CoAP. Referring to OAuth end-point
here. Grant flow relevant for ace.

Hannes: mobile phone with device flow ruled out?
Ludwig: would use plain OAuth for that. Need to have powerful device anyway in
that case so can use plain OAuth.

Ludwig: Updated security and privacy considerations. Tokens valid for multiple
RS. RS can impoersonate if same symmetric key is used. Info can be leaked from
non-encrypted CWT. Profiles not ready for implementation. More implementations
needed. Framework is becoming stable. BLE profile. Time adopt some profiles?

Hannes: milestone out of date. What reasonable timeframe?
Ludwig: don't need implementation ready, right?
Hannes: Hackaton effort on this. Next hackaton could look into this too.
Ludwig: document-wise not much left. We could WGLC now. Now focusing getting
implemented.

Göran S: maybe bit early for WGLC. Some stuff specified in profiles need to
work in framework. Maybe some stuff from profiles should be in framework.
Hannes: expect guys who work on profiles have read framework and can give
comments framework fits their needs

* ACE Profiles (Göran Selander, 20 mins)
- https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/

Currently 4 profiles paritally overlapping. Need to figure out how to handle
that. CoAP-DTLS and -OSCOAP relatively straightforward. MQTT TLS and CoAP
pub/sub profiles more complex and slightly overlapping.

Hannes: overlapping in terms of pub/sub but otherwise quite different?

Gorän: sure. overlap how do we coordinate. Reference each other?

Mohit: do you have profile negotiation? How do I know if the other endpoint
does what? Ludwig: had in early version of draft complex profile negotiation.
But was overengineered. Now assumptions that AS knows what RS and client knows
(since they registered) and selects the best matching one. Client informed what
to use. Hannes: some profiles have static conf or obvious from context. E.g.
BLE may have specific profile. Göran: profiles need to be modular and refernce
each other Carsten: profile negotiation between two authorization managers.

Göran: do we need to control this? Anyone can submit profiles and we adopt
them? More coordnation needed? Hannes: Somewhat pragmatic. Figuring out what is
best at given point of time. we just discuss differences and iron out
differences.

Göran: if we adopt one draft that is overlapping with non-adopted. Need to
consider that? Already overlaps. Could take practical approach and go ahead and
see what happens.

M. Richardson: Go ahead. We are producing proposed Internet standards. If later
detect there was common text that should be somewhere, can be fixed later. Not
unreasonable and faster too.

Carsten: Just had discussion of JWT/CWT being under attacker control. Profile
selection has same problem. If AS can push in profile that makes client think
it's talking to wrong RS, that's problem. Göran: if AS is not trusted, we have
problem anyway

Göran: error handling should be in framework or profiles?
Hannes: will ask profile authors to provide feedback to framework to get
alignment. All profile authors should be familiar with the framework draft.

* DTLS Profile for ACE (Carsten Bormann, 10 mins)
- https://datatracker.ietf.org/doc/draft-gerdes-ace-dtls-authorize/

Carsten: DTLS channel setup happens with RPK or PSK.

Ludwig: one option is to incude CNF conf claim that just specifies a kid. "I've
established this key; please bind new access token to the key"

Carsten: access token designed to be transmitted in clear (even if PSK). Client
gets PSK key in COSE structure. Assuming secure channel to AS. Server can
extract key from access token (encrypted, derived, or by reference).

Hannes: so 3 different ways to get key. Challenges with interop? Which to
implement? Carsten: AS-specific. Between RS and AS. Need to agree on way to do
this. Hannes: easier to just define one? Carsten: originally had just one, but
people wanted to have other ways. Don't mind cutting down.

John Mattson: should commit to adding TLS. Changes would be small.
Carsten: agree
John: Which version of DTLS this applies?
Carsten: hopefully a reference to RFC 6347. 1.2 since CoAP uses that, but once
1.3 is out need to have a look. John: should mostly just work. Some cipher
suite negotation needs to have look. Carsten: UTF PSK problematic Hannes: in
TLS 1.2 PSK not UTF in wire; question was how user indicates and how passed to
sw. One uniform encoding for passing from UI to stack. Carsten: if you read
spec, implementers may not have got that right John: ready for WG adoption
Hannes: currently not in chartered item, so AD needs to approve. Good to get
confirmation. Would make sense to me but up to AD to decide. Göran: Comment on
charter. Profiles are missing part. Charter are already covers profiles.
Hannes: interpreted charter as profiles already part of?

Kathleen: Seems to be interest. But need to make sure there's energy behind.
Need to update charter. But don't seem to be out of scope for ACE.

Hannes: asking 1) if we should adopt the doc 2) who would be working
(15 hands shown for "who has read" asked by Carsten)
who supports adoption: 17 hands + 1 in jabber (Renzo)
who objects: none
reviewers: Jim, Michal, Sean (4-5 hands)
Implementations: Ludwig, Renzo (one java implementation before adoption)
(Renzo: no java implem. I think it is Ludwig Java and Olaf C/libcoap). Kathleen
will comb through the charter. Still confirmation needed on list.

* CoAP Pub-sub Profile (Francesca Palombini, 15 mins)
- https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/

Francesca: Using token-less exchange that was removed from framework. Could be
useful to have it back. Hannes: was less baked idea (back then)

MQTT profile does not differentiate between published and subsbriber.
Hannes: design decision for MQTT broker were supposedly different. Do you know
why? Francesca: (second bullet of nodes); depending on if you're worried of DoS
attacks or need more control on who can subscribe. CoAP MQTT differences.
Ludwig: in MQTT profile broker is trusted. Payload not trusted so profile can
modify. Difference in assumptions who is trusted. Hannes: why different
assumptions made in different profiles? Carsten: both approaches have their
place. Are situations where broker is trusted and can go with something simple.
When not fully trusted, go with something like this. Don't need to do anything
extra on CoAP side since we have pieces in place for this. Ludwig: not sure if
mechanism for updating the public keys subsribers have if new publisher gets
autorized. Francesca: not yet Carsten: fun part: when publisher of subscriber
gets de-authorized. Francesca: could be another doc

Randy Turner: pub/sub CoAP discusses also broker-less. Broker can be real thing
or just interface. Anything in the profile about brokerless? Francesca: not
yet, but if there's interest, could look into it

Hannes: who has read the doc?
(about 10)
Hannes: not yet lots of feedback. Who could review?
(Michael K, Ari, Carsten, (Jim S?), Jaime)
Henk: thank you for including way to proof and sign data provencance; it's
awesome Carsten: really group communication profile, beyond pubsub. Also want
to have gating function, broker only lets through authorized publications.
Hannes: working on implementation? Francesca: not right now

* Ephemeral Diffie-Hellman Over COSE (John Mattsson, 15 mins)
- https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/

Few implementations in progress. Interop planned before the summer.

Mohit: (EDHOC with asymmteric keys slide) message 1, does that propose set?
John: only proposes one.
Mohit: public key already encoded?
John: yes, choose one algo
Michael R: only one algorithm proposed? How to migrate?
Jim S: actually propose several and opposite side chooses one.
Mohit: if it support several curves then how is Public key encoded in the first
message? Jim: curve and key type for eph key sender chooses one and if you
don't like it it's error message in protocol Michael R: (slide with OSCOAP
embedding; "example") One situation that is valuable; what if server not
prerapered to answer message #2 but don't want client keep on asking? Do we
need more separation between post and response? Between message 1-3? Too
complicated? Carsten: CoAP has separate response; ACK and make client quiet.
Michael: exactly what I want Peter: HTTP similar(???) Hannes (from floor):
reflects my fears of the work. Re-building TLS handshake. Adding soon all the
goodness we've added in TLS WG. But could just use TLS. Main difference is the
encoding. Broadband forum has been looking into this. Have run TLS handshake as
app-layer mechanism. Sounds like lot of work re-designing security protocol.
Should take that cautiously. John: implementation of sigma protocol; proofs in
place. This is more simple than TLS handshake with all options. Benefit being
able to use COSE and not have COSE and TLS.

Dave T: using fixed paths not under .well-known. See RFC 7320

Carsten: have implemnted TLS in app layer long ago. Internet draft about that.
Doesn't take away the point of doind something smaller.

Dan Harkins: what is (one of the keys)
John: lots of entropy - just like you should. Need to clarify in the draft.

Göran: point (to Hannes' comment) is we're using on a small device with COSE,
CoAP, and CBOR. Want to have small addition of code to have key management
protocol. That's why different from TLS.

Hannes: ball is with Kathleen with this kind of work.
John: used by 6tisch already
Carsten: given the status, typical place where we would go for WG adoption.
Don't know which WG. Enough people in the room who understand the topic even if
we don't know the right WG. Hannes: need to excuse myself on this Göran:
already discussed what is the relevant WG. Feeling was that ACE is the one.
Hannes: don't think it's covered in charter

Kathleen (as AD): if WG wants adopt this, we add to charter. Two meetings ago
minutes reflected interest. Can now poll again interest. How many have read the
document (12 + 1 jabber), how many interested adopting (15 + 2 jabber).
Opposing adoption (Hannes).

Sean: as long as we keep small and no feature creep
Mohit: already options for extensions in draft
Kathleen: core document without extensions fine?
Sean: yes, just set the bar really high
Kathleen: seems to be enough interest in the WG. Who interested in deploying
(around 6 + 1 jabber) Kathleen: will go through the formal process on list

* EST over secure CoAP (Peter van der Stok, 15 mins)
- https://datatracker.ietf.org/doc/draft-vanderstok-ace-coap-est/

Peter: Extension of Anima work. Specifies EST over CoAP+DTLS. Can make adding
CoAP and HTTP devices to networks work the same way.

Elliot L: important work. Important start. Not sure if ACE is right WG. Maybe
goto to ANIMA. Peter: kind of depends on knowledge here could be here; also
discussed with CoRE. Elliot: need to be coordinatied with BRSKI work etc.
Hannes: strictly tied to ANIMA? Initial work on EST was generic in some sense.
Is ANIMA adding something specific? Elliot: no, meant to solve the problem
where you want to end up with rigth certificate and trust with the thing

Derrel Piper: concerned that is this in charter? Do we want this?
Hannes: competing effort / other solutions? Which direction we want to go?
Where should the work happen? Derrel: important principle: keep trusted
computing space small Dave: No opinion on where it should progress. Don't fix
URIs. Host can do /est but it is recommended. Recommended is bad. Every draft
that uses fixed URIs Max Pritkin: agnostic on where work happens. Agree on
basic goal. ANIMA BRSKI uses JSON. Need to make sure aligned with BRSKI draft.
Not using CBOR now. If important for BRSKI, need feedback there. M. Richardson:
BRSKI is not the name of the protocol. I don't think this belongs in ACE.
Important work, keep doing it. Removed all CoAP CBOR stuff from BRSKI because
didn't know how to do it.  Nothing prevents us from adding it later. Currently
not enouraged to work with constrained devices at ANIMA.

Peter: I like building blocks and blocks that can be removed.
M. Richardson: Conitnue with this but don't think this belongs in ACE.
Sean T: Contenct accept header; client can tell what it supports and server can
give right kind of thing back. Derrel: if want from XML to JSON welcome to my
table Kathleen (as AD): this group has published only one doc so far.
Milestones need to be updated. Need to understand priorities and streamline.
Need to understand with new work what we're taking on.

* Enrollment with Application Layer Security (Goran Selander, 15 mins)
- https://www.ietf.org/id/draft-selander-ace-eals-00.txt

Another draft of certificate enrollment.
May or may not do in this working group. Not a competetor but a compliment to
the previous proposal. There is overlap in names. Work ongoing in application
layer security. You don't have to implement TLS/DTLS.

Hannes: (phase #1 slide) where is certificate signing?
Göran: this is phase #1, that's in next phase

Mike: motivation for client token?
Göran: used to establish key between client and RS who have never met before.
Client is offline and can't contact AS before joining network. In order to
contact RS need to go via point in network. All communication between client
and RS unprotected. Michael R: sounds like some is confused with needed routing
info to get stuff through. Göran: ties in with next presentation about
disconnected clients Hannes: is fair characterization: both drafts use cert
signing request to communicate with infra? Göran: both very closely linked to
EST. Previous draft replaces HTTP/TLS with CoAP/DTLS. This draft replacing TLS
with app layer security. Hannes: seems we have one camp that likes TLS and
other who don't. Should standardize both because provide security in different
layers? Göran: yes. Working on both app and transport layers. Ming Pei: app
security vs dtls. How device is authorized given a certificate? Many ways to do
the same thing in EST? Hannes: only one in both these documents Sean: PKI had
four ways to do this. Would be great to have only one. Hannes: different
approahces: thousand flowers to bloom; easier for WG chairs and ADs Max P:
looks like bootstrapping to secure key infra flow. More like BRSKI. Inluceded
ownership voucher? All other messages CBOR? Expecting CBOR here? Göran: detail
in the draft. Expect to take most compact representation available. Max: seems
more input to ANIMA that all should be CBOR. Hannes: EST and x509 you need
ASN.1 libraries. Gorän: Would like to have more compact representation than
ASN.1.

Michael R: I think on can do TLS with RPK pinned to ownership voucher. With
opaque text you pass to registrar. Device doesn't need to do any ASN.1
operations. Simple comparison operations. Can do with TLS and OSCOAP. Can get
away without arguments of needing ASN.1. Don't need to parse ASN.1. Hannes:
would be useful if can write this down Michael: will implement first. Would
look like implementing full thing but don't need to.

* Offline usage of ACE (Jintao Zhu, 15 mins)
- https://datatracker.ietf.org/doc/draft-zhu-ace-offline/

Göran: (client-AS disconnet slide) the case in previous preso with clien token.
Resource serve is proxy for AS information. Jintao: suggestion to send auth
information in step E (of slide). Göran: want clien token via E and F to
client? Jintao: client as RS to obtain auth information from E. Göran: auth
info for RS is in response. ... in client token. Can take this off-line

Dave Robin: very similar to previous presentation. When bringing building
automation online, client often on latptop and can get to AS, but resource
server can not. This is opposite of what we usually see. Hannes: had discussion
already in WG; can come up with different variations. Which ones we want to
work first? There are other scenarios for the authors. Dave R: just throwing in
data point that generally we see that RS can't talk to network

Jintao: acceptable for RS to have cache managed by client?
Ludwig: not sure. Could allow client token to delete it's own access token.
Would need to manage rights. Don't spontaneously see problem.

Jintao: (client-RS disconnect); OK for AS to act as proxy for requests to RS?
Göran: assume AS is non-constrained device. What is use case when client can't
access RS? Jintao: smart home device control remotely. Can't connect to it
directly. Mohit: if you are remote don't have bluetooth access to device, use
hub instead. That's use case. Dave R: example flow is correct, but it's not AS
doing the proxy function but hub. Ludwig: this is specified in RFC2904 as agent
sequence. Before OAuth so no access token. Not covered by ACE FW as it's now.
And would require great changes to OAuth. Is pattern that has been used before
in IETF. Darrel: wasn't but it was bad idea. Justin R: AS not a box. It's a
function. Known as API GW. Single box doing proxy and AS. Also need to keep in
mind that constrained means different things to different people. Agree with
Kathleen that this WG needs to solve actual problems.

* Wrap-up (Chairs, 5 min)

Will work with Kathleen on the action items. OAuth meeting will have related
stuff. If have time go there.