Minutes IETF119: ace
minutes-119-ace-00

message from Chairs. (5 minutes)

TH doing introduction

MT: the presentation on the pub-sub can be moved to the end
TM: That’s fine

draft-ietf-ace-oscore-gm-admin (10 minutes)

MT presenting

Presented slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-ace-draft-ace-oscore-gm-admin-00.pdf

MT: Summary out WG Last Call outcomes. Addressed comments from Cigdem and
Göran, plus editorial comments from Carsten and comments already in the
authors’ queue. MT: Next step is addressing Carsten’s comments and submit a v
-12, hopefull ready to send to the IESG. TM: Sounds good.

[no comments / questions ]

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

MT presenting

Presented slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-ace-draft-ace-workflow-and-params-00.pdf

MT: Any feedback on the changed formulation in the two profile requirements
from RFC 9200? Goran: The original formulation was also fine, but the new one
is also fine, no change needed to it.

GS: New hackathon item, on the token upload. The client asks the AS for a token
upload to RS. If token is uploaded successfully by the AS, then it is not
provided to the client. GS: But it might be the case that, even so, RS then
lost token, or deleted the token for lack of space. To be safe in that case,
the client might ask the AS to be provided with a copy of the access token to
present to RS, even in case of successful upload by the AS. What do you think?

Dave Robin: You mentioned that you have made a change where the client needs to
be aware of the new workflow and opts-in. You changed it. Why? Preloaded tokens
are for clueless clients […] The AS pre-deliveres the token to RS. The client
attempts to connect to the RS. […] It is an important use case for us. There
are few RSs that want to protect themselves. The AS effectively pre-delivers
the access token. The Client doesn’t even know that they use tokens.

DR: It’s a great migration plan. You said “the client must optin”. Why?
Marco: The change was not about security. A client not supporting the new
worflow but simply complying with the original one, expects to find an access
token in a successful response from the AS. That Client would consider a
different successful response non valid, and it cannot follow-up anyway since
it has received no access token from the AS. Dave: it will just get an answer
back from the RS […] CA (on chat): If the client doesn’t talk to the AS at all,
the client doesn’t need to do that opt-in in any request it sends to the AS –
should all just work fine. GS (on chat): Agree. CA (on chat): I think it should
just work as Dave describes it, without any impact of the changes to the
workflow Marco made. You’re just using a part of the new workflow, and that’s
good. GS (on chat): Dave’s proposal should work fine and would be great to
include as a deployment case in the draft.

TM: Issue to be taken up to the list.

draft-ietf-ace-group-oscore-profile (10 minutes)

RH presenting

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

RH (p2): recap on motivations; access control within groups. For non-basic use
cases, being a group member does not imply any particular access right per se.
RH (p3): access control to access group members’ resources is handled
separately, in line with the NIST zero-trust principles. RH (p4): this profile
of ACE uses Group OSCORE as security protocol; it assumes having joined the
OSCORE group first, then it focuses on accessing resources at group members.
The access token is bound to the Group OSCORE Security Context and the
authentication credential that the Client uses in the group. RH (p5): example
of protocol execution

RH (p6-7): Summary of updates in the latest v -01. Deleting the Access Token is
not followed by deleting the Group OSCOER Security Context. Renamed a TLS
Exporter Label to be more appropriate (used to assist proof-of-possession
between C and AS). Also discussed the computation of PoP evidence separately
for (D)TLS 1.2 and 1.3. RH (p7): Fixed and clarified the computation of the PoP
evidence when C and AS use OSCORE. Now using the same HDKF they use in their
OSCORE Security Context. Also correctly handled the case where the ID Context
is not set at all (different than an empty one). RH (p8): editorial
improvements; clarified expectations on the AS when processing the PoP evidence
received from the Client in the Access Token Request.

RH (p9): Next steps include improving notation in the examples, consider Access
Token covering more than one OSCORE group, advice on how separately using the
OSCORE profile to target a single RS server, aligning the text confirming
adherence to the profile requirements from RFC 9200.

draft-ietf-ace-est-oscore (10 minutes)

MV presenting

Presented slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-ace-draft-ietf-ace-coap-est-oscore-00.pdf

MV (p2-3): The latest version -04 addresses JPM’s review and related issues,
now closed. MV (p4): Closed issue #34, seemingly editorial and related to
draft-ietf-cose-cbor-encoded-cert. MV (p5): Closed issue #35, on mandatory to
support Content-Formats for servers. MV (p6): Issue #38 needs feedback, still
on support of Content-Formats. Due to a “MAY”, this can result in
interoperability issues, also from experience in ANIMA. A way to handle this is
in draft-ietf-anima-constrained-voucher. I will open an issue an solicit
feedback. MV (p7): Issue #43 opened by GS, on using static DH keys, which are
also in other NIST specifications. The same keys can be used also for signing.
New next is allowing the use of such keys for one-time signing. MV (p9): Still
open issues are #36, #29, and #19. MV (p10): We’ll address the still open
issues; we’d like reviews before being ready for WG Last Call.

draft-ace-edhoc-oscore-profile (10 minutes)

GS presenting

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

GS (p2-3): recapping the profile and its workflow GS (p4): the access token is
either uploaded to /authz-info or in EDHOC message_3 in an EAD item (not in EAD
item of EDHOC message_1 anymore). When in an EAD item of EDHOC message_3,
either the actual access token or an identifier is conveyed.

GS (p5-6): Shown one optimized workflow, relying on compact credential
identifiers. In this case, each credential owner is selecting the identifier of
its own credential, with the risk of collision if we consider a large set of
interacting peers. GS (p7): It would be good to have some alternative
identifiers that are still unique but not discretionally generated by the
interested party. Hashes would be good. We have that for certificates, but not
for CCS and CWT. That means registering the necessary COSE Header Parameters
and CWT/JWT confirmation methods. MT: A document in COSE
https://datatracker.ietf.org/doc/html/draft-tschofenig-cose-cwt-chain is
defining COSE Header parameters for chain/bag/hash/uri of CWT. It might be
already ok for covering the CWT case, with a caveat to double-check: it
considers CWT in general, whlie EDHOC thinks of an authentication credential as
a CWT including a COSE Key (for which a COSE Header Parameter ‘kcwt’ has been
defined and registered). CA (on chat): (Yeah, what Marco said :-) )

GS (p8): Discussion on the possible use of the EDHOC Reverse message flow.
Fundamentally possible, just overlooked so far. It requires more thinking.
Having the access token conveyed in EDHOC would need to be in an EAD item of
EDHOC message_2.

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

Not presented due to lack of time.