Note talkers: Marco Tiloca, Rikard Höglund, Benson Muite
"Key Provisioning for Group Communication Using Authentication and
Authorization for Constrained Environments (ACE)" - F. Palombini, M.
Tiloca
draft-ietf-ace-oscore-gm-admin (Tim)
MT: Better to have draft-ietf-ace-group-oscore-profile right after the
other profile document draft-ietf-ace-edhoc-oscore-profile
MT: We've also got recently approved for publication
draft-ietf-ace-revoked-token-notification
Presented slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-ace-est-oscore-00
MV presenting
MV (p2): New version -06 out, largely based on the review from Esko
Dijk. A total of 26 GitHub issues came up, 9 are closed already, what's
left is for discussion today.
MV (p3): Issue #76 on when using the CoAP-to-HTTP proxy. The client can
rely on multiple alternatives and it feels like it complicates the
specification. The authors proposed to remove the alternative for using
DTLS between the EST Client and the proxy, but to use only OSCORE
instead.
MV (p5): Need to understand what Content-Format identifiers to use for
the responses from the /skg resource. Especially the Accept option can
be used for future Content-Format.
MV (p6): Issue about handling TA databases (issue #65). Implicit and
explicit TA database exists for client to auth the server. Currently we
are not fully compliant with RFC9148. We want to refer to it and explain
database population.
MV (p7): Clarification on use of HTTP. Convered in issue #59.
Misconception about this in introduction. Solution is to remove mention
of HTTP in the intro.
MV (p8): Issues tracked on GitHub. Resolve open issues on GitHub.
Questions?
No questions.
Presented slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-ace-group-oscore-ace-profile-ietf-121-00
RH presenting
RH (p2) Recap of the profile gist. EDHOC is used for key establishment,
OSCORE for secure communication. The access token is uploaded by the
client using an EDHOC EAD item.
RH (p3): Clarified that the access token can be uploaded in EAD_2
(reverse flow). or EAD_3 (forward flow), or EAD_4 (reverse flow). The
upload on /authz-info is not possible anymore over an unprotected
channel, but it remains possible over a protected channel when
performing dynamic update of access rights. This ensures that the
transport of the access token is always encrypted.
RH (p4): Include EDHOC EAD item. If access token already provisioned and
valid, client can indicate session ID in message. Indicates security
context to update keying material.
New Access tokens uploaded using existing security context, and then
updated.
RH (p5): Many editorial improvements and revised examples. Added details
for the case when the EDHOC reverse message flow is used, including what
the RS has to ensure when the EAD item includes either the access token
or the session_id identifying the token series. Also discussed what the
RS has to do when an access token become invalid (clean up of EDHOC
session and OSCORE Security Context).
RH (p6): Next steps
a) Mandate access token request and response encoded as CBOR, so ruling
out JSON encoding.
b) proof-of-possesion of private key of the Client at the AS; it needs
discussion and different approaches are possible
c) Access tokens for group audiences
d) privacy and security implications of using one EDHOC message flow or
the other, and related use of EAD_2 or EAD_4 when using the reverse
message flow.
Questions:
No questions.
Presented slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-ace-group-oscore-ace-profile-ietf-121-00
RH presenting
RH (p2): Fine-grained access control of resources hoste group members
RH (p3): Editorial updates. Clarifications in 2 sections,
RH (p4): Clarifications in section 4.,5. New section 8 on "Guidelines on
using Multiple Profiles". Use particular value of audience of hint for
desired profile to use.
RH (p5): There are quite unlikely ambiguous situations that lead C and
RS into troubles. The RS would not be able later on to understand which
access token to use for enforcing access control on an incoming request.
RH (p6): The previous issues are now prevented by construction, while
still keeping the AS agnostic of groups, group memberships, and group
managers. If C has ambiguous memberhips, C is responsible to change the
situation, e.g., by changing its OSCORE Sender ID in some of the groups
where it is a member of. Then C can proceed with requesting and
uploading the access token. Still, RS will perform checks vouched by the
Group Manager(s) involved to confirm that C does not have ambiguous
memberships at the moment.
RH (p7): On the topic of the RS storing multiple authentication
credentials per PoP key, this is now extended for practicality the
original recommendation from RFC 9200. Tim asked to check for possible
security impacts. We checked, that was mostly for limiting storage
overhead and complexity in evaluating access rights. That's still the
spirit here, but the original recommendation is here overly restricted
considering what this profile is about. We have proposed an updated
version of the recommendation, in the same spirit of the original one
but adapted. In parallel, also defined an analogous recommendation for
when using a different profile of ACE in parallel with the present one.
RH (p8): Overview of next steps:
Enable dynamic update of access rights
Consider interleaving of group rekyying
Consider group members that cannot reply with responses protected with
group OSCRORE
Setups with multiple application and security groups.
Questions:
No questions.
MT presenting
MT (p1): Updating the ACE framework with a set of updates (5 main
points). 1. Alternative workflow letting the AS upload the Access Token.
2. Definition of auth params for use in ACE, for various reasons. 3.
Enabling bidirectional Access control with a single Access Token. 4.
Amended profile requirements on transport profiles. 5. Deprecate payload
format for error responses, use problem details.
MT (p2): Editorial fixes and improvements. "Token series" term better
described. Fixing naming of audience-related parameters.
MT (p3): "access_token": added mandatory to implement features (making
SHA-256 mandatory to implement). "token_series_id": Defining
identifier of a token series.
CB: Still the case that we consider SHA256 to be around everywhere?
TH: Yes.
CB: Still valid today considering PQ?
TH: Yes, symmetric crypto makes hash functions less affected
CB: True, but I'm not certain that SHA256 is around everywhere
anymore...
MT: Can update if needed later.
MT (p3): "token_series_id" identifies a token series. Can be used to
requesting a token continuing the new series. Needed for some profiles
to allow update of access rights. Some other profiles already have
useable identifiers, so some profiles do not need this, but some do.
CB: Not just a hint, changing the behaviour?
MT: Enabling behaviour. Dynamic updates would be impossible otherwise
CB: Scope of identifier?
MT: Value is provided in Access Token response, client includes it in
future Access Token requests.
CB: Scoped to a specific client?
MT: Yes, and to a specific token series.
MT (p5): New parameters "to_rs", "from_rs"; Can be used to hold for
instance the nonces in the OSCORE ACE profile. Practically fixes things
that the alternative workflow "breaks".
MT (p6): Detailed examples and message flows
MT (p7): Next steps: Access Tokens for group audience. Alternative ACE
workflows regarding update of access rights. Fix for corner issue.
Support for bi-directional access control in single token.
Questions:
CB: About slide 6, expect there to be other forms of identifying RSs?
Providing "socket" for different ways of identifying resource servers.
MT: RS still identified by audience. "to_rs" is what the Client would
have given to the RS if the normal workflow was used.
CB: Why is this different? Why need to invent new way?
MT: What is the new way?
CB: to_rs and from_rs encodes CBOR maps with some data?
MT: Yes, N1, ID1 in to_rs and N2, ID2 in from_rs.
CB: Expect other things to be put in this byte string?
MT: Not for this profile. Params are byte strings in general, up to each
profile to define.
CB: How extensible is this? What will others plug in there?
MT: Not sure
CB: So that's why you keep it open?
MT: Yeah.
DR: Need other name than "alternative workflow". Reading section 4 the
reverse-scope thing... Intriguing to combine these multiple things in
one Access Token is interesting. How does that not require coordination
betwen the 2 ASs? I'd like to see this part as a separate draft, to not
burden this draft.
DR: Paragraph about "client might not be ACE aware". That is not enough,
needs to be expanded on. This is a "clueless client", make it clear that
it's not ACE aware but still has security and credentials etc. Idea is
to deliver a Token for this device to the RS, without making this Client
do anything specific. Neat idea. What is the cnf in there? Token has to
be client bound, how is this happening? What about confirmation claim?
MT: Thanks a lot. Would be great if you can post to the mailing list
DR: Clients need to prove they are the clients bound to the token, that
is a challenge.
MT presenting
MT (p2): DTLS profile supports RPK mode using asymmetric credentials as
raw public keys. Want to enable use of alternative formats for
authentication credentials.
MT (p3): Update 9202, Extend RPK mode to support also CCS. Define a new
certificate mode for X.509 and C509 public key certificates.
MT (p4): Using new CWT confirmation methods (kccs, x5bag x5chain etc.)
All needed params are already registered. Specifying the credentials in
the usual places. Difference is the type of the credentials. Hybrid
combinations are possible, can mix the modes.
MT (p5): Examples in "RPK mode". Showing token in credentials for client
and server.
MT (p6): Corresponding example for "Certificate mode".
MT (p7): Going over recent updates. Changed title. Minor editorial
fixes. Improved CBOR examples.
MT (p8): Clearer formulation on the combinations and hybrid settings.
Clarifications on using 'kccs'
MT (p9): Had certificate mode already, but only certs by value. We now
have also certs by reference (params are already registered). Appendix A
expanded with more examples for hybrid settings
MT (p10): Plan to add support for COSE_Keys by reference (using CWT
confirmation method 'ckt').
Ready for WGLC?
Questions:
TH: No questions. Will start 2 week adoption call next week.
FP: Have document published ace-key-groupcomm, ace-key-groupcomm-oscore
in validation state. ace-key-groupcomm-oscore coming up based on
feedback and changes to ace-key-groupcom. Asked Paul if we should wait
or implement the changes now. Paul said to go ahead and do the changes.