ACE @ IETF 122

Note talkers: Marco Tiloca, Christian Amsüss, ...

Message from Chairs (5 minutes)

Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-ace-chair-slides-ace-00

TH doing introductions

draft-ace-est-oscore (10 minutes) (Mališa Vučinić)

Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-ace-est-oscore-01

GF presenting (on behalf of authors)

GF (p2): Status recap; updates mostly addressing Esko's comments
GF (p4): composite issue #69, on sending certificates by reference
(e.g., x5t, x5u, c5t, c5u). The EDHOC protocol can do that to exchange
authentication credential by reference.
GF: Here, enrolling certificate by reference (client never sees
certificate).

GF (p5): Possible issue on interoperability, addressable using the
Accept option to indicate an exact expected CoAP Content-Format in the
response. In turn, the returned reference can simply be an opaque
certificate reference, without making the reference type explicit.
GF (p5): Client doesn't care and may not even parse it.
GF (p5): If it parses, it can put a specific type of refernce which it
is asking to be generated.
GF: Authors opinion, but group prefs?

FP: Don't like option 1, please do option 3, it's cleaner.
GF: Supporting both 2 and 3?
FP: Would like to see media type review in that case. Usually one media
type matches one format.

GF(p6): (also on #69). Same issue, but after enrollment. Whatever
certificate returned by the server, it has to be possible for the client
to use as its authentication credential in EDHOC. That something maybe
possible to cover in the -lake-app-profiles document.
GF: On x5t and x5u usage for retrieving a certificate of another peer.
Handling this sounds app specific. It might practically rely on
interacting with a remote repository, or with a local storage. We think
it's strictly speaking out of scope for this draft, still interesting to
have considerations.

GF(p8): #52.

MT: On p6: I think this is already covered in app-profiles.
Double-check.

draft-ietf-ace-workflow-and-params (10 minutes) (Marco Tiloca)

Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-ace-short-distribution-chain-sdc-workflow-and-new-oauth-parameters-for-the-authentication-and-authorization-for-constrained-environm-00

MT presenting.

MT(p1): New title as requested.
MT(p3): Dave's review. bidi moved out.
MT(p4): Previous version required C to send credential; small downside
is slightly quicker consumption of ID (favorable tradeoff).
MT(p5): C may know better than AS what to use.
MT(p6): Avoiding deadlocks.
MT(p7): Deadlock avoidance: done from two sides.

No questions.

draft-ietf-ace-authcred-dtls-profile (10 minutes) (Marco Tiloca)

Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-ace-additional-formats-of-authentication-credentials-for-the-datagram-transport-layer-security-dtls-profile-for-authentication-and-a-00

MT presenting

MT(p2): DTLS profile exists; updating.
MT(p6): updated list of options. Note registrations pending in other
draft.

No questions.

draft-ietf-ace-edhoc-oscore-profile (10 minutes) (Rikard Höglund)

Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-ace-edhoc-ace-profile-slides-ietf-122-00

RH presenting.

RH(p2): Overview.
RH(p3): Aligned with workflows-and-params as to how the AS assigns
identifiers to token series (now leveraging the client as an entity, not
its credential involved in the token series).
RH(p4): Clarify credential validation requirements (AS validating C's
credential).
RH (p5): Mentioned that C can do an EDHOC "roll call", as a CoAP trigger
request over multicast, aligned with the EDHOC reverse message flow.
Each RS will follow individually with EDHOC message_1, then C continues
running EDHOC individually with each oh those RSs.
RH (p5): Described that RS has to do a consistency check of C's
authentication credential, considering what is in EDHOC ID_CRED_X and
in the EDHOC EAD item where the access token is specified (by value or
through the session_id).
RH (p6): Limited use of the Request Creation Hints message defined in
RFC 9200. An RS supporting the EDHOC reverse message flow must not
include audience and scope in that message. That's for preventing that
message to defeat the identity protection that RS is supposed to achieve
being Initiator when running EDHOC in the reverse message flow.
RH (p6): Added parameter to the EDHOC_Information object, to indicate
supported trust anchors (taken out from -lake-app-profiles).
RH (p7): Clarified that naked COSE keys are not allowed in EDHOC, hence
related key confirmation methods are not applicable.
RH (p8): Next steps: early allocation of codepoints for confirmation
methods? Have the equivalent of Request Creation Hints through EAD
items? Proof-of-possession of C's credential at AS.

FP (on chat): offtopic: whenever this goes to wglc it would be good to
cc lake in the lc
MT (on chat): Most definitely

draft-ietf-ace-group-oscore-profile (10 minutes) (Rikard Höglund)

Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-ace-group-oscore-ace-profile-slides-ietf-122-00

RH presenting

RH (p2): Recap
RH (p3): The structure withing req_cnf of the token request has to be
exactly what C gave to the Group Manager of the OSCORE group. That's
relevant when the credential is part of a chain/bag of certificates.
RH (p4): Clarified guidance on possible use of multiple profiles. It now
has also a placeholder: the updated semantics of "ace_profile"
introduced in -ace-workflow-and-params can be also considered.
RH (p5): The AS still has to achieve proof-of-possession w.r.t. C's
private key, but it does not have to re-achieve it at every single token
request. The inclusion of the PoP evidence from C in the access token
request is thus fundamentally optional. If the AS needs it and does not
get it, the AS replies with an error (which should have a dedicated
error code, as mentioned before for -ace-worklow-and-params).
RH (p6): Other alignments, including IANA.
RH (p7): Next steps: considerations about group rekeying and its impact;
details on what happens for dynamic update of access rights; consider
how this can be extended for a single token to cover muliple
security/appication groups.

CA: Use cases for multiple-security-groups? Sounds very complex and easy
to get wrong, and client is already interacting with multiple entities
so could just get different tokens.
RH: To be explored. Agree that can be overly complex. If it's fine to
deal with multiple tokens, it might become just about it, without a too
complex optimization.

draft-ietf-ace-pubsub-profile (5 minutes) (Francesca Palombini)

Presented slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-ace-pubsub-profile-for-ace-00

FP presenting.

FP (p2): the pubsub document in CoRE is progressing and had WGLC.
-ace-key-groupcomm was published as RFC 9594. We need to do something in
this profile though.
FP (p3): The document covers also MQTT, but much less in detail. Also,
that would still require CoAP, so it feels not realistic that both are
supported by clients. Authors have discussed and prefer to remove all
the MQTT content from the draft, stramlining it to be just about pubsub
for CoAP.
FP: Objections here to removing it?
Matthias Kovatsch: Answer to "Why extra profile when we already have
building blocks?" was "B/c also MQTT". Now MQTT gone, question is back.

FP: Longer conversation; in short, it adds: authorization to
publish/subscribe; key provisioning; end-to-end protection of messages.
Suggest to read doc and discuss.

FP: Proposed new name for the draft considering the removal of MQTT
content. No objection for having "Constrained Application Protocol
(CoAP) Publish-Subscribe Profile for Authentication and Authorization
for Constrained Environments (ACE)"
PW: Will you confirm on the list?

Benson Muite (on chat): Last one is clearer, But maybe ok in
introduction
CA (on chat): … and let's talk to RFC editor what it takes to get some
abbreviations in.

AOB