Minutes IETF124: ace: Mon 17:00
minutes-124-ace-202511031700-00
| Meeting Minutes | Authentication and Authorization for Constrained Environments (ace) WG | |
|---|---|---|
| Date and time | 2025-11-03 17:00 | |
| Title | Minutes IETF124: ace: Mon 17:00 | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2025-11-18 |
ACE at IETF124
Agenda
- Message from co-chairs. 5 mins.
- Message from Sec AD. 5 mins.
- draft-ietf-ace-coap-pubsub-profile. Marco Tiloca. 10 mins.
- draft-ietf-ace-workflow-and-params. Marco Tiloca. 10 mins.
- EST-OSCORE. Mališa Vučinić. 5 mins.
- draft-ietf-ace-edhoc-oscore-profile. Rikard Höglund. 10 mins.
- AoB. 5 mins.
Notes
(Notes: MT, RH, CA)
TH doing introductions and agenda bashing
Security AD announcements
(none)
pubsub profile
MT presenting.
MT (p2): Recapping the solution. One access token for operations at
broker and one for operations at the KDC.
MT (p3): Narrowed to CoAP from MQTT+CoAP by May agreement. Updates from
applying AD comments to other document also here.
MT (p4): Updates for v-01. Editorial and IANA considerations.
MT (p5): Clarified point about nonce generation when TLS is used.
Clarified randomness and length of nonces. Adding references to
Appendixes.
MT (p6): We think the document is ready for WGLC.
GS: Believe this is ready; followed that draft.
TH: Can have WGLC within next couple of weeks.
workflow-and-params
MT presenting.
MT (p2): Recap, key feature is the AS uploading the access token to the
RS on behalf of the client.
MT (p3): Updates for v-06. Editorial. CDDL model with abbreviations.
MT (p4): Elaborated on the to_rs and from_rs parameters. The AS needs
to understand the semantics of these. In case of problems: Fall back to
original workflow, AS returns access token to client.
MT (p5): Considerations about updated_rights parameters, signals
updating of access rights.
MT (p6): Further details and semantics about updated_rights parameter.
MT (p7): IANA considerations. Updates to "Parameter Usage Location",
adding as-rs request and rs-as response.
MT (p8): Reminder: We have 7 open errata for RFC9200, please review.
MT (p9): Next steps.
DR: About updated_rights parameter. Suggested it, and a ton got added.
Editorial: use forward reference to keep "upload token" section not
noisy. Question: About "RS forgets, and AS sends update". C gets error.
So, new series gets started?
MT: (agrees)
DR: What if client forgets? New token, not an update_?
MT: Nothing to update; yes.
EST-OSCORE
MV presenting.
MV (p2): Today, covering 2 reviews from MT and ED.
MV (p4): MT provided 40 mostly editorial fixes, thinks document is
ready. Concrete non-applied: On normative language (input please!). MT
thinks "must" should be "MUST", but already mandating EDHOC and thus not
restate.
TH: If we mean "must" to mean "we're restating a normative requirement",
should say that explicitly in terminology.
MV: The last quoted sentence may cover your concern
TH: Doesn't work for readers; should be consistently 2119 or explain why
we do it differently
MT on chat: s/must/has to
MV: WFM.
CA on chat: Thumbs up on lower-case must when re-stating.
JR: RFC2119 update says lower-case has no special meaning. Avoiding
using must by has-to is common (???). Relying on syntax to disambiguate
is not good.
TH: That is my objection
JR: Not fine to redefine. We SHOULD NOT do that ;-)
TH: At the start of that paragraph, "The requirements here come from
EDHOC".
MV (p4): 4th paragraph.
TH: IMO that is poster child for when non-normative "must" makes sense.
MV, summarizing: So for 3rd and 4th, get away from lower-case "must" and
go with alternative wording.
TH: Got a lot of thumbs up, sounds good
ED on p4, 4th paragraph: Who issues what?
MV: Clear to me, needs clarification?
ED: Needs to be clearer, "its" can be ambigous
MV (p5): On ED's post-cutoff review.
MV (p6): just accepting ED's proposal, not controversial.
MV (p7): on "bag". is it always a bag or can be single cert? looked it
up and the response can be a single cert. still we want to get away from
the term "bag"
GS: Remnant from EST, responding with bag, is probably not right thing
to do. Should chain or single cert. Should take away bag.
ED: Depends if want to mimick what EST-COAPS has, does this allow bag?
Allows to have either one or multiple.
MV: Looking it up. The response is either a single cert or (I guess) a
bag. need to double-check
ED: If want to optimzie for constrained, chain makes sense.
MV: In case of DER encoding: Keep original semantics of EST-COAPS, but
for CBOR encoding we use chains. Works?
Someone in room: "Okay"
TH: If no more reviews come in, yes. Of course, comments can still come
any time. Once ED is happy wiht -10, do shepherd writeup.
EDHOC-OSCORE profile
RH presenting.
RH (p2): Overview.
RH (p3): Added requirements for the RS to support the Uri-Path-Abbrev
option defined in -core-uri-path-abbrev, for abbreviating
/.well-known/edhoc. Also expanded on using the two new EAD items
(request of other peer's credential by value and request for information
that would normally be in the Request Creation Hints response)
RH (p3): Why hint? Client may not know which AS to use yet. Combinable
with new credential-by-value item.
RH (p4): Example of full interaction where both those EAD items are
used. The client starts EDHOC with the RS without even knowing what AS
should be contacted. There's some limitations, but it works for pointing
the client to the right AS.
RH (p5): More updates, with examples for the ead_value of the new EAD
items.
RH (p6): Unlike in the DTLS profile, we forbid the AS from differing
CNFs.
RH (p7): Example work. Early allocations. Ciphersuite flexibility.
Implications of options.
CA on handling suites: Prefer not audience, but provide higher-level
information (not precisely method). Spelling out methods is problematic
anyway (see recent mail).
CA: Recent review just shortly before meeting, on list. Mostly
editorial. Selected items I'd like to bring up:
- Also, please early-allocate EAD labels. Impls start using it.
- Some flexibility (session IDs reused per client scoped by audience
(therefore client sometimes has to send audience when obtaining
updated tokens), announcement whether or not the content format is
sent, endpoint identity types): Are there actual use cases?
Otherwise, consider slimming it down.
RH: On session_id, can make it more unique.
RH: On registry content, we looked at EDHOC RFC at what is shown as
examples of app profiles (appendix or main section), that's why we have
content format option and the endpoint identity.
CA: Back then, had little experience with EDHOC as it was just being
written. Now we gathered experience, let's focus on the things we
learned are relevant, not everything that was thought of as possibly
relevant back then.
MT on session ID: 2nd option from mail should work
MT: as for early alloc, would need new version with IANA considerations,
with actual values.
TH, wrapping up: ToDos
- pubsub: ready for WGLC
- OSCORE: WGLC is ongoing, get one more update and ship to IESG if
everyone happy. - on workflow-params, need to review errata and approve (and review
MUST discussion in minutes)