ACE @ IETF 120

• Update from Chairs. 5 minutes.
• draft-ietf-ace-coap-est-oscore 10 minutes.
• draft-ietf-ace-pubsub-profile 10 minutes.
• draft-ietf-ace-edhoc-oscore-profile 15 minutes.
• draft-ietf-ace-oscore-gm-admin 15 minutes.
• draft-ietf-ace-workflow-and-params 15 minutes.
• draft-ietf-ace-group-oscore-profile 10 minutes.
• AoB 5 minutes.

Update from Chairs

TH doing introduction

Agenda bashing: move the -edhoc-oscore-profile down before the
-group-oscore-profile

draft-ietf-ace-coap-est-oscore

https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est-oscore/

MV presenting

MV: -05 fixes a misc set of things and issues.
MV (p4): addressed and closed issue #36. Improved security
considerations on channel binding.
MV (p5): Addressed and closed issue #19. Clarified scope of the
document, in the introduction and abstract (rewritten). ...
MV (p6): Also clarified use of initial authentication credential.
MV (p7): Addressed and closed issue #29. Added an example with an
optimized EDHOC execution flow, per draft-ietf-core-oscore-edhoc. Some
TBDs are still there as placeholders due to pending registrations in
COSE.
MV (p8): Misc updates, e.g., alingment with the COSE C509 certificate
draft; using also the privkey media type defined therein.
MV (p9): Issues still open are #52 (CDDL structure) and #54 (type of
enrollment credentials, possibly aided by the EDHOC cipher suite
negotiation).
MV (p10): Next steps: closing remaining issues on Github. After that,
WGLC should be possible.

No questions raised.

draft-ietf-ace-pubsub-profile

https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/

CS presenting

CS (p1): Updates cover both -09 and -10.
CS (p2): Recap. Protect both end-to-end communication and communication
with broker.
CS (p3): Going through updates, starting with lot of cleanup. Still
building on draft-ietf-ace-key-groupcomm and keeping alingment with it.

CS (p4): Multiple passes in revising the format of scope, based on an
AIF data model. Covering operations for pubsub clients, for either
joining a security group at the KDC, or an application group at the
broker.
CS (p5): "Delete" semantics depending on scope, naming changes, more
details.
CS (p7): Next steps: possible additional means for topic metadata
discovering, and group policies. Then ready for WGLC?

No questions raised.

draft-ietf-ace-oscore-gm-admin

https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/

MT presenting.

MT (p2): Recap: Purpose, resources, ACE roles.
MT (p3): visualization; operations.
MT (p4): Comparison to IETF119 state.
MT (p5..): -12 addresses Carsten's review (see slides).
MT (p9): Revisited regular expression expression
MT (p10): Define "having permission" in a single place. Overwrites are
now POST.
MT (p13): All WGLC comments should be addressed, CB please confirm.
Editorial changes pending. Expect -12 to be shepherd ready.

TH: With the changes, recirculate for 2w in the WG?
MT: Up to you. Authors think it is ready.

CA (chat only): I do have questions about the PUT->POST change, but will
first read that change and then follow up offline.

draft-ietf-ace-workflow-and-params

https://datatracker.ietf.org/doc/draft-ietf-ace-workflow-and-params/

MT presenting.

MT (p2): recap of components.
MT (p3): e'' notation as in gm-admin.
MT (p4): AS-RS communication, pre-configured clients, parameter updates
(see next slide)
MT (p5): token_upload now allows more meanings (including requesting
token hash).
MT (p6): token_hash mechanism is consistent with other ACE documents.
Why would the client need hash or token? Token hash is to use token
revocation; token is to re-upload the token itself, eg. in ACE OSCORE
profile.
MT (p7): Comparison of successful uses.
MT (p8..): exploring bidirectional control. Primary and opposite
direction. See issue #1, seems to be possible, sketch already available.
Still, only one device is ACE client. rev_aud, rev_scope. AS generates
them based on access control policies. Both rely on secure
communication. Dynamic rights update is still possible, with caveat that
only access token requester can trigger an update in the same token
series. Also works with alternative flow.
MT (p12): Outlook; have clear roadmap and continue exploring
bidirectional (esp. with two ASes).

TH: Intrigued by bidir idea, clever, makes sense for p2p. Did this come
from somewhere else?
CA: No previous application I know of; motivating case was CoRE Resource
Directory where CoAP roles can be reversed.

draft-ietf-ace-edhoc-oscore-profile

https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/

RH presenting.

RH (p2): Overview.
RH (p3): e'' notation.
RH (p4): Editorials. Policy for EDHOC Information registry. Reason for
only supporting CWT (not JWT) is that CWT is the default and recommended
format in ACE anyway, and it avoids complications due to base64url
encoding if the CWT/JWT and CBOR/JSON message encoding are mixed.
RH (p5): Clarify relation to EDHOC forward/reverse message flow, as
either can be used. Ultimately, it's still about which identity one
wants to protect the most. Which EAD message is used depends on flow and
desired security/privacy properties (to be elaborated in draft).
RH (p6): Outlook, including group audiences.

CA: On concistency check, will that consistency check be strict and
disallow have distinct CWTs in ID_CRED_I and EAD3? (one for
authentication, one for authorization).
RH: What we had in mind was that an absolute match.
(to be taken offline)
MT: As I imagine it it will not be ruled out; the consistency check is
between ID_CRED_I of the EDHOC message and the content of the cnf
claim within ACE token in the EAD. Those two things are both the public
authentication credential of the client, and to be cross-checked.

draft-ietf-ace-group-oscore-profile

https://datatracker.ietf.org/doc/draft-ietf-ace-group-oscore-profile/

RH presenting.

RH (p2): Access control for accessing resources in group memebers.
Happens after group joining (see other docs, incl
ace-key-groupcomm-oscore). Token bound to existing group context.
RH (p3): Scenarios. Group membership does not imply access rights
(zero-trust model).
RH (p4): e'' in CBOR diagnostic notation examples, also using registered
values when possible.
RH (p5): consistency, revised example, fixes.
RH (p6): Sketched plan for access rights updates. The plan is to build
on concepts/parameters from draft-ietf-ace-workflow-and-params intended
to enable/ensure dynamic update of access rights in general. This boils
down to the concept of "token series" and a parameter/claim explicitly
indicating the token series to which an access token belong to.
No need for new concept due to workflow-params work.
RH (p8): On an RS storing multiple access tokens per PoP key. Deviating
form 9200 recommendation where it is inflexible for applications using
this transport profile. 3 examples: the same Client with a given PoP key
can obtain two tokens, each of which for a different audience, or OSCORE
group, or transport profile of ACE.
RH (p9): Outlook. Eg. multiple profiles, token per profile. Tokens
spanning groups.

TH: It should be fine to have multiple tokens for the same PoP key, but
document it well in the security considerations to be sure that nothing
goes wrong if that happens.

CA: On token spanning groups: Ideas yet on how different scopes
combined? (Eg. one may have AIF, other may have AIF)?
Plans so far, or just early exploration?
RH: Do have plans, not considered different scope types yet. May need to
make some parameters structured (multiple values where previously had
one).

AoB

None.