# 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 ---