Skip to main content

Minutes IETF111: ace
minutes-111-ace-00

Meeting Minutes Authentication and Authorization for Constrained Environments (ace) WG
Title Minutes IETF111: ace
State Active
Other versions plain text
Last updated 2021-07-30

minutes-111-ace-00
# IETF-111 : ace Thursday 2021-07-29 15:00 PDT (22:00 UTC)

# Agenda

* Agenda Bashing 5 min
* WG status 5 min
* closing WGLC
  * cmpv2-copa-transport Mohit 10 min
  * wg-coap-eap Dan 10 min
* ongoing work
  * key-groupcomm  (next to be WGLC) Marco 5 min
  * key-groupcomm-oscore Marco 5 min
  * gm-admin Marco 5 min
  * pubsub-profile (next to be WGLC) Cigdem 10 min
* possible new work
  * draft-tiloca-ace-revoked-token-notification (adoption ?) 5 min

# chair slides

[note
well](https://docs.google.com/presentation/d/1YuUzfZMbMijvpJJkBoOkppOaec4u2S_TMBowo1EqQVY/edit?usp=sharing)

---

# WG status

RFC Editor:
* -coap-est, -dtls-authorize, -oauth-authz, -oauth-params, -oscore-profile
  * still editorial nits so please make sure to respond with 24h to the RFC
  editor.
AD review:
* -aif, -mqtt-profile

---
WGLC: (This meeting closes the WGLC)
* -wg-coap-eap
* -cmpv2-coap-transport

WG:
* -key-groupcomm
  * expect a WGLC after this IETF
  * reviewers
  * Cigdem Sengul volunteered to look
  * Göran Selander
  * Francesca is coauthor, deep look would be useful. Marco has taken editor
  role. Have been following updates, maybe too familiar * WG Last call next week
* -pubsub-profile
  * (high priority for the WG)
  * Today: how far from WGLC?
* -key-groupcomm-oscore
  * sync with CORE WG
* -gm-admin
* draft-tiloca-ace-revoked-token-notification
  * call for adoption
---
AD remarks:
Ben Kaduk: Thanks everyone. Great that core cluster done. Sorry to be part of
the post-IESG delay, didn't get change for button pushing. Now done! Very
promising. Next doc is the MQTT profile. Next couple weeks should have
something. Great to have core work done. Still stuff for group communication

---

Draft discussion
====
# coap-eap
* Added ./well-known/a. Obviously IANA will change.
* Changed URI to confirm to HATOEAS
* Added error handling things
* Elaborated on key negotitation
* Since IOT device goes first need to add to controller. Afterward ok, but
message 1 and 2 require it * Carsten:  If we don't ask, never happen. Unusual
abbreviation * Once server gets message can create resource, any value assigned
by CoAP server. * CoAP engine will take care of ordering, nonexistence, etc. *
What if message out of place on the well known? Resource always available *
When comes from EAP controller to peer during authentication. Are in middle of
ongoing auth, send reset * Other case: well known message arrives from EAP peer
to authenticator because delayed. Nonconfirmable message. During authentication
controller omits no consequence * IoT device Sends Reset if things weren't
started by it * Cyphersuite negotation: Embedded in payload rather than option.
Embedded in key derivation to bind them. Need to be aware of EAP message
structure * EAP packet followed by CBOR array as EAP packet knows its own
length. IoT device selects in third message presented in second. * Derive from
MSK derived via EAP via HPKE with cybersuite negotation. * IANA considerations:
    * Well known
    * EAP lower layer identifier
 * Daniel (Chair): Can start with IANA to see if section is fine. While some
 other people review draft. Takes about 2 weeks * Carsten Bormann: Simple
 observation. Designing new PDUs, ciphersuites, etc. Make sure designed so when
 second version comes have ability to extend. Something in array or lifetime to
 say something differen. * Ben Kaduk: EAP side. Recent discussions in EMU and
 TLS 1.3 importance of EAP state diagram and sometimes protected indication of
 success or failure. Had to change after IESG evaluation to add. Looks like
 actual EAP success in OSCORE options. Seems like it would count but need to
 confirm * Dan Garcia-Corrrilo: Yes
# -CMPV2-coap-transport
Not presented.

# pubsub-profile
Cigdem Sengul
* Changes in third version
* Authorizes publishers and subscribers
* Initially TLS, didn't cover messages
* MQTT description added to profile
* In IETF 110, change to architecture
* Architecture change: from two AS to one
* Some concerns about separation, MQTT mapping, especially consistency of
policies * KDC in broker and AS are resource servers * Implementor could split
but policy consistency is implemented by choice, not default. Implementor
handles * Change authorization: before two auth requests to two servers, now
single one, but two audiencies: KDC and broker * Now aligned to groupcomm *
Subscriber auth now supported. * Daniel Migault: one token, two audiences, any
keys being shared? * A: yes secret for secure connection is a single thing.
Might need discussion. Since same policies consulted to grant permission to
pub/sub and encrypt acceptable. Happy to rethink if there is an issue. * Two
audiences should be ok? * CoAP and MQTT flows similar * Changes: no joint auth
and request to AS2, now separate. Auth to AS, join to KDC * MQTT: wildcards
with hierarchical tree * May span several layers in tree * Separated
application and group names. group communication considers communication group
* Must map application groups to security. Must discover. * Typical prefix to
publish is $SYS topic. * Broker specific info, widely adopted, well known.
acked in MQTT spec. * Client has to learn to get token scopes, covering each
security group covering opplications * SYS recommended protected. Introduces
another step. Auth AS to subscribe to SYS to go back to AS to cover additional
things to communicate, then come back and get keys etc. * Once client gets
necessary mappings scopes cover all groups. Separate joins for each security
group. Publications corresponding keys. RS will validate if token for client
right. Subscribe to filters: client has to understand how security groups map,
so broker can reject directly. * Work on client to ask for right things. Kind
of good tradeoff * WGLC? looking for implementors

* Ben Kaduk: Security depends on kind of token: single token multiple
audiences. Not inherently flawed, but should look carefully. Some places makes
sense but depends on what type of proof of posession key is being used.
Asymmetric works much better. * Cigdem: typically symmetric in main framework.
Giving as option better. Or do you suggest two tokens and don't describe two
audiences * BK: lots of overlap, natural for single token. Don't propose
default two tokens. Will need to have separate asymmetric vs symmetric case. *
BK: in oauth world commonplace for single token multiple audiences. Some
atttacks/weeknesses that fall out of that. Ouath has documented many, should
try to find and reference. * Cigdem: need to add more to security
considerations. * Hannes: need to think about what from oauth has these things
* DM: close to being done, some needs. Seems draft is stable. Might be asking
for who wants to look in August/September? * September: Marco * DM: draft sent
in September. Please review document # key-groupcomm Marco Tiloca: * Overview
of ACE groupcomm docs: key-groupcomm general message and proceedures, plus API
of a Key Distribution Center for providing key material to use in groups. This
is instanced by specific application profiles: first pubsub, second
key-groupcomm-oscore (for groups using Group OSCORE as secure communication
among group members). * key-groupcomm-oscore extends the API of the generic
KDC, which is the Group Manager for Group OSCORE. This document defines the
Group Manager interface for joining nodes and group members. *
key-groupcomm-oscore also affects the ace-oscore-gm-admin draft, which defines
an interface at the Group Manager intended for administrators. * The CoRE WG
developes the secure group communication protocol Group OSCORE. This has an
impact on ace-key-groupcomm-oscore and ace-oscore-gm-admin * DM: what is CORE
doing? * Marco: While in ACE we define key provisioning, in CoRE we define
Group OSCORE for message protection in the group * Interim:

As updates to ace-key-groupcomm
* From signatures to arbitrary proof of possesion as PoP evidence, it can be a
signature, but up to profiles to specify. * Public keys: from COSE keys to to
anything in "COSE Header Parameters registry" * X509, CWTs, CWT claims, etc. *
Not assuming identifier embedded into public key * now use peer_identifiers
parameter including node identifier * -13 is stable * Group OSCORE not finished
in CoRE, but one more round * Shouldn't impact this document, only
key-groupcomm-oscore * DM: chairs willing to take risk/ * Watson: group
memebership issue. * Marco: group members can query memberships by interacting
with the KDC * Marco: the secure group communication itself is out of scope
here: this is just about provisioning of keying material for the group
communication * DM: had same issue with previous. Maybe due to the name * We're
clear on intent whether it is clear or not. * Need to deconfuse this clearly in
the draft.

# key-groupcomm-oscore
* Marco Tiloca: Due to updates to Group OSCORE in CoRE, changes here: alignment
to parameters, proof of possession, stricter policies about group key
management and rekeying, and more * Expect one more update of Group OSCORE in
CoRE, one more change here * Marco Tiloca: this is about accessing in
authorized way groups where communication is protected with Group OSCORE. So it
is about getting the required keys for that, in an authorized way. * Daniel:
getting key using oscore * Marco: no, key fetching happens between joining node
and Group Manager (KDC) using whatever transport profile of ACE. Then, get key
material for using Group OSCORE as security protocol for communication among
group members. * # gm-admin Out of time #
draft-tiloca-ace-revoked-token-notification Out of time

---

Interim meeting:
* We will continue to plan them on a 1 per month basis
*

Interconnexion with other WG: OAUTH, GNAP ?
* Want to not isolate ourselves from other work being done
* Following: Not hearing many people
---