From 4c59e2ad309e010d23579978760a235ec58b326b Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 17:23:00 +0200 Subject: [PATCH 01/18] Acknowledgments --- draft-ietf-ace-key-groupcomm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 472c34f..15d3af3 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -2724,7 +2724,7 @@ RFC EDITOR: PLEASE REMOVE THIS SECTION. # Acknowledgments {: numbered="no"} -The following individuals were helpful in shaping this document: {{{Christian Amsüss}}}, {{{Carsten Bormann}}}, {{{Rikard Höglund}}}, {{{Ben Kaduk}}}, {{{Watson Ladd}}}, {{{John Preuß Mattsson}}}, {{{Daniel Migault}}}, {{{Jim Schaad}}}, {{{Ludwig Seitz}}}, {{{Göran Selander}}}, {{{Cigdem Sengul}}}, {{{Peter van der Stok}}}, and {{{Paul Wouters}}}. +The following individuals were helpful in shaping this document: {{{Christian Amsüss}}}, {{{Carsten Bormann}}}, {{{Vidhi Goel}}}, {{{Rikard Höglund}}}, {{{Ben Kaduk}}}, {{{Watson Ladd}}}, {{{John Preuß Mattsson}}}, {{{Daniel Migault}}}, {{{Jim Schaad}}}, {{{Ludwig Seitz}}}, {{{Göran Selander}}}, {{{Cigdem Sengul}}}, {{{Peter van der Stok}}}, and {{{Paul Wouters}}}. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home (Grant agreement 952652); and by the EIT-Digital High Impact Initiative ACTIVE. From 73c9f7e6b4aab628a185b3ff0d7acc960910a5eb Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 17:36:40 +0200 Subject: [PATCH 02/18] Clarification: /ace-group can be accessible also for non group members --- draft-ietf-ace-key-groupcomm.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 15d3af3..a91e174 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -503,6 +503,8 @@ If request messages sent to the KDC as well as success response messages from th A Client can access this resource in order to retrieve a set of group names, each corresponding to one of the specified group identifiers. This operation is described in {{retrieval-gnames}}. + Clients may be authorized to access this resource even without being members of any group at the KDC, and even if they are not authorized to become group members (e.g., when authorized to be external signature verifiers). + * /ace-group/GROUPNAME : one such sub-resource to /ace-group is hosted for each group with name GROUPNAME that the KDC manages, and contains the symmetric group keying material for that group. A Client can access this resource in order to join the group with name GROUPNAME, or later as a group member to retrieve the current group keying material. These operations are described in {{ssec-key-distribution-exchange}} and {{ssec-key-material-retrieval}}, respectively. From 5278dc8d6c97533bf38baa7c6a1677d3bccc3604 Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 17:41:00 +0200 Subject: [PATCH 03/18] s/update/updated --- draft-ietf-ace-key-groupcomm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index a91e174..6aab829 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -633,7 +633,7 @@ Note that the KDC only verifies that the node is authorized by the AS to access #### Retrieve Group Names {#retrieval-gnames} -In case the joining node only knows the group identifier of the group it wishes to join or about which it wishes to get update information from the KDC, the node can contact the KDC to request the corresponding group name and group-membership resource URI. The node can request several group identifiers at once. It does so by sending a CoAP FETCH request to the /ace-group endpoint at the KDC formatted as defined in {{ace-group-fetch}}. +In case the joining node only knows the group identifier of the group it wishes to join or about which it wishes to get updated information from the KDC, the node can contact the KDC to request the corresponding group name and group-membership resource URI. The node can request several group identifiers at once. It does so by sending a CoAP FETCH request to the /ace-group endpoint at the KDC formatted as defined in {{ace-group-fetch}}. {{fig-ace-group-fetch}} gives an overview of the exchanges described above, and {{fig-ace-group-fetch-2}} shows an example. From 3c8ce8059965da37e647678198e7168edd0868ef Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 17:45:16 +0200 Subject: [PATCH 04/18] Extended example of FETCH request to /ace-group/GROUPNAME/creds --- draft-ietf-ace-key-groupcomm.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 6aab829..22f650d 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -1168,16 +1168,16 @@ Uri-Path: "g1" Uri-Path: "pub-key" Content-Format: "application/ace-groupcomm+cbor" Payload: - { "get_creds": [true, [], [ ID3 ]] } + { "get_creds": [true, [], [ ID2, ID3 ]] } Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation): - { "creds": [ AUTH_CRED_3 ], - "peer_roles": [ "receiver" ], - "peer_identifiers": [ ID3 ] } +{ "creds": [ AUTH_CRED_2, AUTH_CRED_3, ], + "peer_roles": [ ["sender", "receiver"], "receiver" ], + "peer_identifiers": [ ID2, ID3 ] } ~~~~~~~~~~~ {: #fig-public-key-2 title="Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members"} From 414a01d89f112f0a253e5eab42c5d4f42e4e1eba Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 17:46:38 +0200 Subject: [PATCH 05/18] Editorial --- draft-ietf-ace-key-groupcomm.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 22f650d..490e745 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -1175,9 +1175,9 @@ Response: Header: Content (Code=2.05) Content-Format: "application/ace-groupcomm+cbor" Payload (in CBOR diagnostic notation): -{ "creds": [ AUTH_CRED_2, AUTH_CRED_3, ], - "peer_roles": [ ["sender", "receiver"], "receiver" ], - "peer_identifiers": [ ID2, ID3 ] } + { "creds": [ AUTH_CRED_2, AUTH_CRED_3, ], + "peer_roles": [ ["sender", "receiver"], "receiver" ], + "peer_identifiers": [ ID2, ID3 ] } ~~~~~~~~~~~ {: #fig-public-key-2 title="Example of Authentication Credential Request-Response to Obtain the Authentication Credentials of Specific Group Members"} From 91fd85d4c7a0ff346ba833e52c1a22edf3187df3 Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 17:50:08 +0200 Subject: [PATCH 06/18] s/acts as/acts as a --- draft-ietf-ace-key-groupcomm.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 490e745..5e9b812 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -513,7 +513,7 @@ If request messages sent to the KDC as well as success response messages from th * /ace-group/GROUPNAME/creds : the path of this resource is invariant once the resource is established. This resource contains the authentication credentials of all the members of the group with name GROUPNAME. - This resource is created only in case the KDC acts as repository of authentication credentials for group members. + This resource is created only in case the KDC acts as a repository of authentication credentials for group members. A Client can access this resource in order to retrieve the authentication credentials of other group members, in addition to when joining the group. That is, the Client can retrieve the authentication credentials of all the current group members, or a subset of them by specifying filter criteria. These operations are described in {{sec-key-retrieval-all}} and {{sec-key-retrieval}}, respectively. @@ -1691,7 +1691,7 @@ In either case, the KDC performs the following actions. * The KDC removes the Client from the list of current members of the group. -* In case of forced eviction, i.e., for cases 2 and 3 above, the KDC deletes the authentication credential of the removed Client, if it acts as repository of authentication credentials for group members. +* In case of forced eviction, i.e., for cases 2 and 3 above, the KDC deletes the authentication credential of the removed Client, if it acts as a repository of authentication credentials for group members. * If the removed Client is registered as an observer of the group-membership resource at /ace-group/GROUPNAME, the KDC removes the Client from the list of observers of that resource. @@ -1719,7 +1719,7 @@ Distributing the new group keying material requires the KDC to send multiple rek Each rekeying message MUST have Content-Format set to application/ace-groupcomm+cbor and its payload formatted as a CBOR map, which MUST include at least the information specified in the Key Distribution Response message (see {{gid-get}}), i.e., the parameters 'gkty', 'key', and 'num' defined in {{gid-post}}. The CBOR map MAY include the parameter 'exp', as well as the parameter 'mgt_key_material' specifying new administrative keying material for the target group members, if relevant for the used rekeying scheme. -A rekeying message may include additional information, depending on the rekeying scheme used in the group, the reason that has triggered the rekeying process, and the specific target group members. In particular, if the group rekeying is performed due to one or multiple Clients that have joined the group and the KDC acts as repository of authentication credentials of the group members, then a rekeying message MAY also include the authentication credentials that those Clients use in the group, together with the roles and node identifier that the corresponding Client has in the group. It is RECOMMENDED to specify this information by means of the parameters 'creds', 'peer_roles', and 'peer_identifiers', like done in the Join Response message (see {{gid-post}}). +A rekeying message may include additional information, depending on the rekeying scheme used in the group, the reason that has triggered the rekeying process, and the specific target group members. In particular, if the group rekeying is performed due to one or multiple Clients that have joined the group and the KDC acts as a repository of authentication credentials of the group members, then a rekeying message MAY also include the authentication credentials that those Clients use in the group, together with the roles and node identifier that the corresponding Client has in the group. It is RECOMMENDED to specify this information by means of the parameters 'creds', 'peer_roles', and 'peer_identifiers', like done in the Join Response message (see {{gid-post}}). The complete format of a rekeying message, including the encoding and content of the 'mgt_key_material' parameter, has to be defined in separate specifications aimed at profiling the used rekeying scheme in the context of the used application profile of this specification. As a particular case, an application profile of this specification MAY define additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme in {{point-to-point-rekeying}} (OPT14). @@ -1761,7 +1761,7 @@ Rekeying messages can be protected at the application layer, by using COSE and t If a particular rekeying message is intended to a single target group member, the KDC may alternatively protect the message using the security association with that group member, and deliver the message like when using the "Point-to-Point" group rekeying scheme (see {{point-to-point-rekeying}}). -* Through a pub-sub communication model - In this case, the KDC acts as publisher and publishes each rekeying message to a specific "rekeying topic", which is associated with the group and is hosted at a broker server. Following their group joining, the group members subscribe to the rekeying topic at the broker, thus receiving the group rekeying messages as they are published by the KDC. +* Through a pub-sub communication model - In this case, the KDC acts as a publisher and publishes each rekeying message to a specific "rekeying topic", which is associated with the group and is hosted at a broker server. Following their group joining, the group members subscribe to the rekeying topic at the broker, thus receiving the group rekeying messages as they are published by the KDC. In order to make such message delivery more efficient, the rekeying topic associated with a group can be further organized into subtopics. For instance, the KDC can use a particular subtopic to address a particular set of target group members during the rekeying process, as possibly aligned to a similar organization of the administrative keying material (e.g., a key hierarchy). @@ -2065,7 +2065,7 @@ Furthermore, the following security considerations apply. When a group member receives a message from a certain sender for the first time since joining the group, it needs to have a mechanism in place to avoid replayed messages and to assert their freshness, e.g., {{Section B.1.2 of RFC8613}} or {{Section 10 of I-D.ietf-core-oscore-groupcomm}}. Such a mechanism aids the recipient group member also in case it has rebooted and lost the security state used to protect previous group communications with that sender. -By its nature, the KDC is invested with a large amount of trust, since it acts as generator and provider of the symmetric keying material used to protect communications in each of its groups. While details depend on the specific communication and security protocols used in the group, the KDC is in the position to decrypt messages exchanged in the group as if it was also a group member, as long as those are protected through commonly shared group keying material. +By its nature, the KDC is invested with a large amount of trust, since it acts as a generator and provider of the symmetric keying material used to protect communications in each of its groups. While details depend on the specific communication and security protocols used in the group, the KDC is in the position to decrypt messages exchanged in the group as if it was also a group member, as long as those are protected through commonly shared group keying material. A compromised KDC would thus put the attacker in the same position, which also means that: From 04d4de9e1dd3f65efe89124939f670ede3fdd07a Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 17:52:03 +0200 Subject: [PATCH 07/18] Editorial --- draft-ietf-ace-key-groupcomm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 5e9b812..12bea42 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -1729,7 +1729,7 @@ The possible, temporary misalignment of the keying material stored by the differ ## Point-to-Point Group Rekeying {#point-to-point-rekeying} -This approach consists in the KDC sending one individual rekeying message to each target group member. In particular, the rekeying message is protected by means of the security association between the KDC and the target group member in question, as per the used application profile of this specification and the used transport profile of ACE. +A point-to-point group rekeying consists in the KDC sending one individual rekeying message to each target group member. In particular, the rekeying message is protected by means of the security association between the KDC and the target group member in question, as per the used application profile of this specification and the used transport profile of ACE. This is the approach taken by the basic "Point-to-Point" group rekeying scheme, that the KDC can explicitly signal in the Join Response (see {{gid-post}}), through the 'rekeying_scheme' parameter specifying the value 0. From 7bbe27aebdbfd76b8ded27141803fff44b0d27e1 Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 17:54:29 +0200 Subject: [PATCH 08/18] Editorial --- draft-ietf-ace-key-groupcomm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 12bea42..c300696 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -1781,7 +1781,7 @@ Further details depend on the specific rekeying scheme used in the group. When using a group rekeying scheme relying on one-to-many rekeying messages, the actual data content of each rekeying message is prepared according to what the rekeying scheme prescribes. -Then, the KDC can protect the rekeying message as defined below. The used encryption algorithm which SHOULD be the same one used to protect communications in the group. The method defined below assumes that the following holds for the management keying material specified in the 'mgt_key_material' parameter of the Join Response (see {{gid-post}}). +Then, the KDC can protect the rekeying message as defined below. The used encryption algorithm SHOULD be the same one used to protect communications in the group. The method defined below assumes that the following holds for the management keying material specified in the 'mgt_key_material' parameter of the Join Response (see {{gid-post}}). * The included symmetric encryption keys are accompanied by a corresponding and unique key identifier assigned by the KDC. From 1540818c9f01ebe774f351d1d1ab32d7488a8b7a Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 18:04:58 +0200 Subject: [PATCH 09/18] Acknowledgments --- draft-ietf-ace-key-groupcomm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 472c34f..da6a8f3 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -2724,7 +2724,7 @@ RFC EDITOR: PLEASE REMOVE THIS SECTION. # Acknowledgments {: numbered="no"} -The following individuals were helpful in shaping this document: {{{Christian Amsüss}}}, {{{Carsten Bormann}}}, {{{Rikard Höglund}}}, {{{Ben Kaduk}}}, {{{Watson Ladd}}}, {{{John Preuß Mattsson}}}, {{{Daniel Migault}}}, {{{Jim Schaad}}}, {{{Ludwig Seitz}}}, {{{Göran Selander}}}, {{{Cigdem Sengul}}}, {{{Peter van der Stok}}}, and {{{Paul Wouters}}}. +The following individuals were helpful in shaping this document: {{{Christian Amsüss}}}, {{{Carsten Bormann}}}, {{{Thomas Fossati}}}, {{{Rikard Höglund}}}, {{{Ben Kaduk}}}, {{{Watson Ladd}}}, {{{John Preuß Mattsson}}}, {{{Daniel Migault}}}, {{{Jim Schaad}}}, {{{Ludwig Seitz}}}, {{{Göran Selander}}}, {{{Cigdem Sengul}}}, {{{Peter van der Stok}}}, and {{{Paul Wouters}}}. The work on this document has been partly supported by VINNOVA and the Celtic-Next project CRITISEC; by the H2020 project SIFIS-Home (Grant agreement 952652); and by the EIT-Digital High Impact Initiative ACTIVE. From f25853c477a1f82439194ce61c1fdc1ecd04ac1f Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 18:12:55 +0200 Subject: [PATCH 10/18] Point to RFC 9237 in CDDL definitions --- draft-ietf-ace-key-groupcomm.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index da6a8f3..626c580 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -336,6 +336,8 @@ The Authorization Request sent from the Client to the AS is defined in {{Section As defined in {{RFC9200}}, other additional parameters can be included if necessary. ~~~~~~~~~~~~~~~~~~~~ CDDL +;# include rfc9237 + gname = tstr permissions = uint .bits roles @@ -347,7 +349,7 @@ roles = &( Verifier: 4 ) -scope_entry = AIF_Generic +scope_entry = AIF-Generic scope = << [ + scope_entry ] >> ~~~~~~~~~~~~~~~~~~~~ @@ -1856,6 +1858,8 @@ The resulting tagged CBOR byte string is used as value of the 'scope' claim of t {{cddl-ex-0-ext}} and {{cddl-ex-ext}} build on the examples in {{ssec-authorization-response}}, and show the corresponding extended scopes. ~~~~~~~~~~~~~~~~~~~~ CDDL +;# include rfc9237 + gname = tstr permissions = uint .bits roles @@ -1867,7 +1871,7 @@ roles = &( Verifier: 4 ) -scope_entry = AIF_Generic +scope_entry = AIF-Generic scope = << [ + scope_entry ] >> From bae81ff88d0caf4d58434cd1c1f8383c9d24de5b Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 18:33:03 +0200 Subject: [PATCH 11/18] Fixed CCDL notation when wrapping into a CBOR byte string --- draft-ietf-ace-key-groupcomm.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 626c580..7768e33 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -351,7 +351,10 @@ roles = &( scope_entry = AIF-Generic -scope = << [ + scope_entry ] >> +scope_entries = [ + scope_entry ] + +scope = bstr .cbor scope_entries + ~~~~~~~~~~~~~~~~~~~~ {: #cddl-ex-0 title="Example of scope using the AIF format"} @@ -362,7 +365,9 @@ role = tstr scope_entry = [ gname , ? ( role / [ 2*role ] ) ] -scope = << [ + scope_entry ] >> +scope_entries = [ + scope_entry ] + +scope = bstr .cbor scope_entries ~~~~~~~~~~~~~~~~~~~~ {: #cddl-ex title="Example of scope using the textual format, with the group name and role identifiers encoded as text strings"} @@ -1873,7 +1878,9 @@ roles = &( scope_entry = AIF-Generic -scope = << [ + scope_entry ] >> +scope_entries = [ + scope_entry ] + +scope = bstr .cbor scope_entries extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope) ~~~~~~~~~~~~~~~~~~~~ @@ -1886,7 +1893,9 @@ role = tstr scope_entry = [ gname , ? ( role / [ 2*role ] ) ] -scope = << [ + scope_entry ] >> +scope_entries = [ + scope_entry ] + +scope = bstr .cbor scope_entries extended_scope = #6.TAG_FOR_THIS_SEMANTICS(scope) ~~~~~~~~~~~~~~~~~~~~ From 88e62933c490588fb590536e116e23ec1cdcbf38 Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 18:45:23 +0200 Subject: [PATCH 12/18] Mentioned RFC 8610 in Section 1.1 "Terminology" --- draft-ietf-ace-key-groupcomm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 7768e33..2c45618 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -140,7 +140,7 @@ Readers are expected to be familiar with: * The terms and concepts described in CoAP {{RFC7252}}. Unless otherwise indicated, the term "endpoint" is used here following its OAuth definition, aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. This document does not use the CoAP definition of "endpoint", which is "An entity participating in the CoAP protocol". -* The terms and concepts described in CBOR {{RFC8949}} and COSE {{RFC9052}}{{RFC9053}}{{RFC9338}}. +* The terms and concepts described in CDDL {{RFC8610}}, CBOR {{RFC8949}}, and COSE {{RFC9052}}{{RFC9053}}{{RFC9338}}. A principal interested to participate in group communication as well as already participating as a group member is interchangeably denoted as "Client" or "node". From 2a3065a526818cb688914ca10c27ffe5e5874e23 Mon Sep 17 00:00:00 2001 From: crimson Date: Thu, 26 Oct 2023 18:49:51 +0200 Subject: [PATCH 13/18] Simplified definition of some terms --- draft-ietf-ace-key-groupcomm.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 2c45618..f2b5575 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -154,15 +154,15 @@ A principal interested to participate in group communication as well as already Furthermore, this document uses "names" or "identifiers" for groups and nodes. Their different meanings are summarized below. -* Group name: the invariant once established identifier of a group. It is used in the interactions between Client, AS, and RS to identify a group. A group name is always unique among the group names of the existing groups under the same KDC. +* Group name: The identifier of a group. Once established, it is invariant. It is used in the interactions between Client, AS, and RS to identify a group. A group name is always unique among the group names of the existing groups under the same KDC. -* GROUPNAME: the invariant once established text string used in URIs. GROUPNAME uniquely maps to the group name of a group, although they do not necessarily coincide. +* GROUPNAME: The text string used in URIs to identify a group. Once established, it is invariant. GROUPNAME uniquely maps to the group name of a group, although they do not necessarily coincide. * Group identifier: the identifier of the group keying material used in a group. Unlike group name and GROUPNAME, this identifier changes over time, when the group keying material is updated. -* Node name: the invariant once established identifier of a node. It is used in the interactions between Client and RS, as well as to identify a member of a group. Within the same group, a node name is always unique among the node names of all the current members of that group. +* Node name: The identifier of a node. Once established, it is invariant. It is used in the interactions between Client and RS, as well as to identify a member of a group. Within the same group, a node name is always unique among the node names of all the current members of that group. -* NODENAME: the invariant once established text string used in URIs to identify a member of a group. Its value coincides with the node name of the associated group member. +* NODENAME: The text string used in URIs to identify a member of a group. Once established, it is invariant. Its value coincides with the node name of the associated group member. This document additionally uses the following terminology: From 1f0999fbb4f49aa0c54fbeb5c04a207481d18cfe Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 27 Oct 2023 11:45:28 +0200 Subject: [PATCH 14/18] Use the problem-details format from RFC 9290 --- draft-ietf-ace-key-groupcomm.md | 101 ++++++++++++++++++++++---------- 1 file changed, 69 insertions(+), 32 deletions(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index f2b5575..68883be 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -52,6 +52,7 @@ normative: RFC9053: RFC9200: RFC9237: + RFC9290: RFC9338: I-D.ietf-core-oscore-groupcomm: COSE.Algorithms: @@ -600,15 +601,49 @@ If the request is not formatted correctly (e.g., required fields are not present If the request includes unknown or non-expected fields, the handler MUST silently ignore them and continue processing the request. Application profiles of this specification MAY define optional or mandatory payload formats for specific error cases (OPT4). -Some error responses from the KDC can have Content-Format set to application/ace-groupcomm+cbor. In such a case, the payload of the response MUST be a CBOR map, which includes the following fields. +Some error responses from the KDC can convey error-specific information according to the problem-details format defined in {{RFC9290}}. Such error responses MUST have Content-Format set to application/concise-problem-details+cbor. The payload of these error responses MUST be a CBOR map specifying a Concise Problem Details data item (see {{Section 2 of RFC9290}}). The CBOR map is formatted as follows. -* 'error', with value a CBOR integer specifying the error occurred at the KDC. The value is taken from the "Value" column of the "ACE Groupcomm Errors" registry defined in {{iana-ace-groupcomm-errors}} of this specification. This field MUST be present. +* It MUST include the Custom Problem Detail entry 'ace-groupcomm-error' registered in {{iana-custom-problem-details}} of this document. -* 'error_description', with value a CBOR text string specifying a human-readable diagnostic description of the error occurred at the KDC, written in English. The diagnostic text is intended for software engineers as well as for device and network operators, in order to aid debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the KDC. This field MAY be present, and it is unlikely relevant in an unattended setup where human intervention is not expected. + This entry includes only one field, namely 'error-id'. The map key for 'error-id' is the CBOR unsigned integer with value 0. The value of 'error-id' is a CBOR integer specifying the error occurred at the KDC. This value is taken from the 'Value' column of the "ACE Groupcomm Errors" registry defined in {{iana-ace-groupcomm-errors}} of this document. -The 'error' and 'error_description' fields are defined as OPTIONAL to support for Clients (see {{params}}). A Client supporting the 'error' parameter and able to understand the specified error may use that information to determine what actions to take next. + The CDDL notation {{RFC8610}} of the 'ace-groupcomm-error' entry is given below. -{{error-types}} of this specification defines an initial set of error identifiers, as possible values for the 'error' field. Application profiles of this specification inherit this initial set of error identifiers and MAY define additional value (OPT5). +~~~~~~~~~~~ CDDL + ace-groupcomm-error = { + &(error-id: 0) => int + } +~~~~~~~~~~~ + +* It MAY include further Standard Problem Detail entries or Custom Problem Detail entries (see {{RFC9290}}). + + In particular, it can include the Standard Problem Detail entry 'detail' (map key -2), whose value is a CBOR text string that specifies a human-readable, diagnostic description of the error occurred at the KDC. The diagnostic text is intended for software engineers as well as for device and network operators, in order to aid debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the KDC. The 'detail' entry is unlikely relevant in an unattended setup where human intervention is not expected. + +An example of error response using the problem-details format is shown in {{fig-exapmle-error-response}}. + +~~~~~~~~~~~ +Response: + +Header: Service Unavailable (Code=5.03) +Content-Format: application/concise-problem-details+cbor +Payload: +{ + / title / -1: "No available node identifiers", + / detail / -2: "Things will change after a + group rekeying; try later", + / response-code / -4: 163, / 5.03 / + / ace-groupcomm-error/ TBD: { + / error-id / 0: 4 / "No available node identifiers" /, + } +} +~~~~~~~~~~~ +{: #fig-exapmle-error-response title="Example of Error Response with Problem Details"} + +Note to RFC Editor: In the figure above, please replace "TBD" with the unsigned integer assigned as key value to the Custom Problem Detail entry 'ace-groupcomm-error' (see {{iana-custom-problem-details}}). Then, please delete this paragraph. + +The problem-details format in general and the Custom Problem Detail entry 'ace-groupcomm-error' in particular are OPTIONAL to support for Clients. A Client supporting the entry 'ace-groupcomm-error' and able to understand the specified error may use that information to determine what actions to take next. + +{{error-types}} of this specification defines an initial set of error identifiers, as possible values for the 'error-id' field. Application profiles of this specification inherit this initial set of error identifiers and MAY define additional value (OPT5). ## /ace-group @@ -774,11 +809,11 @@ If the KDC manages the group members' authentication credentials, the handler ch * The KDC checks the authentication credential to be valid for the group identified by GROUPNAME. That is, it checks that the authentication credential has the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. - If this verification fails, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 2 ("Authentication credential incompatible with the group configuration"). + If this verification fails, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 2 ("Authentication credential incompatible with the group configuration"). * The KDC verifies the PoP evidence contained in the 'client_cred_verify' field. Application profiles of this specification MUST specify the exact approaches used to verify the PoP evidence, and MUST specify which of those approaches is used in which case (REQ14). - If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 3 ("Invalid Proof-of-Possession evidence"). + If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 3 ("Invalid Proof-of-Possession evidence"). If no authentication credential is included in the 'client_cred' field, the handler checks if an authentication credential is already associated with the received access token and to the group identified by GROUPNAME (see also {{ssec-key-distribution-exchange}}). Note that the same joining node may use different authentication credentials in different groups, and all those authentication credentials would be associated with the same access token. @@ -1038,7 +1073,7 @@ The GET handler returns the symmetric group keying material for the group identi The handler expects a GET request. -In addition to what is defined in {{kdc-if-errors}}, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members"). +In addition to what is defined in {{kdc-if-errors}}, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members"). If all verifications succeed, the handler replies with a 2.05 (Content) response containing the symmetric group keying material. The payload of the response is formatted as a CBOR map which MUST contain the parameters 'gkty', 'key', and 'num' specified in {{gid-post}}. @@ -1331,7 +1366,7 @@ This resource implements the GET handler. The handler expects a GET request. -In addition to what is defined in {{kdc-if-errors}}, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members"). +In addition to what is defined in {{kdc-if-errors}}, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members"). If all verifications succeed, the handler replies with a 2.05 (Content) response containing the list of policies for the group identified by GROUPNAME. The payload of the response is formatted as a CBOR map including only the parameter 'group_policies' defined in {{gid-post}} and specifying the current policies in the group. If the KDC does not store any policy, the payload is formatted as a zero-length CBOR byte string. @@ -1381,7 +1416,7 @@ This resource implements the GET handler. The handler expects a GET request. -In addition to what is defined in {{kdc-if-errors}}, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members"). +In addition to what is defined in {{kdc-if-errors}}, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members"). If all verifications succeed, the handler returns a 2.05 (Content) message containing an integer that represents the version number of the symmetric group keying material. This number is incremented on the KDC every time the KDC updates the symmetric group keying material, before the new keying material is distributed. This number is stored in persistent storage. @@ -1429,7 +1464,7 @@ This resource implements the GET, PUT, and DELETE handlers. In addition to what is defined in {{kdc-if-errors}}, each of the handlers performs the following two verifications. -* The handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members"). +* The handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members"). * The handler verifies that the node name of the Client is equal to NODENAME used in the url-path. If the verification fails, the handler replies with a 4.03 (Forbidden) error response. @@ -1508,9 +1543,9 @@ The PUT handler processes requests from a Client that asks for new individual ke The handler expects a PUT request with empty payload. -In addition to what is defined in {{kdc-if-errors}} and at the beginning of {{node-subresource}}, the handler verifies that this operation is consistent with the set of roles that the Client has in the group (REQ11). If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 1 ("Request inconsistent with the current roles"). +In addition to what is defined in {{kdc-if-errors}} and at the beginning of {{node-subresource}}, the handler verifies that this operation is consistent with the set of roles that the Client has in the group (REQ11). If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 1 ("Request inconsistent with the current roles"). -If the KDC is currently not able to serve this request, i.e., to generate new individual keying material for the requesting Client, the KDC MUST reply with a 5.03 (Service Unavailable) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 4 ("No available node identifiers"). +If the KDC is currently not able to serve this request, i.e., to generate new individual keying material for the requesting Client, the KDC MUST reply with a 5.03 (Service Unavailable) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 4 ("No available node identifiers"). If all verifications succeed, the handler replies with a 2.05 (Content) response containing newly generated, individual keying material for the Client. The payload of the response is formatted as a CBOR map. The specific format of newly-generated individual keying material for group members, or of the information to derive it, and corresponding CBOR label, MUST be specified in the application profile (REQ27) and registered in {{iana-reg}}. @@ -1575,7 +1610,7 @@ The DELETE handler removes the node identified by NODENAME from the group identi The handler expects a DELETE request with empty payload. -In addition to what is defined in {{kdc-if-errors}}, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 0 ("Operation permitted only to group members"). +In addition to what is defined in {{kdc-if-errors}}, the handler verifies that the Client is a current member of the group. If the verification fails, the KDC MUST reply with a 4.03 (Forbidden) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 0 ("Operation permitted only to group members"). If all verification succeeds, the handler performs the actions defined in {{sec-node-removal}} and replies with a 2.02 (Deleted) response with empty payload. @@ -1601,13 +1636,13 @@ An example of PoP input to compute 'client_cred_verify' using CBOR encoding is g It is REQUIRED of the application profiles to define the specific formats of authentication credentials that are acceptable to use in the group (REQ6). -In addition to what is defined in {{kdc-if-errors}} and at the beginning of {{node-subresource}}, the handler verifies that this operation is consistent with the set of roles that the node has in the group. If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 1 ("Request inconsistent with the current roles"). +In addition to what is defined in {{kdc-if-errors}} and at the beginning of {{node-subresource}}, the handler verifies that this operation is consistent with the set of roles that the node has in the group. If the verification fails, the KDC MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 1 ("Request inconsistent with the current roles"). If the KDC cannot retrieve the 'kdcchallenge' associated with this Client (see {{token-post}}), the KDC MUST reply with a 4.00 (Bad Request) error response, which MUST also have Content-Format application/ace-groupcomm+cbor. The payload of the error response is a CBOR map including a newly generated 'kdcchallenge' value. This is specified in the 'kdcchallenge' parameter. In such a case the KDC MUST store the newly generated value as the 'kdcchallenge' value associated with this Client, replacing the currently stored value (if any). -Otherwise, the handler checks that the authentication credential specified in the 'client_cred' field is valid for the group identified by GROUPNAME. That is, the handler checks that the authentication credential is encoded according to the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. If that cannot be successfully verified, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 2 ("Authentication Credential incompatible with the group configuration"). +Otherwise, the handler checks that the authentication credential specified in the 'client_cred' field is valid for the group identified by GROUPNAME. That is, the handler checks that the authentication credential is encoded according to the format used in the group, is intended for the public key algorithm used in the group, and is aligned with the possible associated parameters used in the group. If that cannot be successfully verified, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 2 ("Authentication credential incompatible with the group configuration"). -Otherwise, the handler verifies the PoP evidence contained in the 'client_cred_verify' field of the request, by using the authentication credential specified in the 'client_cred' field, as well as the same way considered in {{gid-post}} and defined by the specific application profile (REQ14). If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 3 ("Invalid Proof-of-Possession evidence"). +Otherwise, the handler verifies the PoP evidence contained in the 'client_cred_verify' field of the request, by using the authentication credential specified in the 'client_cred' field, as well as the same way considered in {{gid-post}} and defined by the specific application profile (REQ14). If the PoP evidence does not pass verification, the handler MUST reply with a 4.00 (Bad Request) error response. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 3 ("Invalid Proof-of-Possession evidence"). If all verifications succeed, the handler performs the following actions. @@ -1708,7 +1743,7 @@ In either case, the KDC performs the following actions. - If the evicted Client is observing its associated sub-resource at /ace-group/GROUPNAME/nodes/NODENAME (see {{node-get}}), the KDC sends an unsolicited 4.04 (Not Found) error response, which does not include the Observe option and indicates that the observed resource has been deleted (see {{Section 3.2 of RFC7641}}). - The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 5 ("Group membership terminated"). + The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 5 ("Group membership terminated"). * If the application requires forward security or the used application profile requires so, the KDC MUST generate new group keying material and securely distribute it to all the current group members except the leaving node (see {{sec-group-rekeying}}). @@ -1742,7 +1777,7 @@ When taking this approach in the group identified by GROUPNAME, the KDC can prac * The KDC SHOULD make the /ace-group/GROUPNAME resource Observable {{RFC7641}}. Thus, upon performing a group rekeying, the KDC can distribute the new group keying material through individual notification responses sent to the target group members that are also observing that resource. - In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME resource), relying on CoAP Observe as discussed above also allows the KDC to send an unsolicited 4.04 (Not Found) response to each observer group member, as a notification of group termination. The response MUST have Content-Format set to application/ace-groupcomm+cbor and is formatted as defined in {{key-distr}}. The value of the 'error' field MUST be set to 6 ("Group deleted"). + In case the KDC deletes the group (and thus deletes the /ace-group/GROUPNAME resource), relying on CoAP Observe as discussed above also allows the KDC to send an unsolicited 4.04 (Not Found) response to each observer group member, as a notification of group termination. The response MUST have Content-Format set to application/concise-problem-details+cbor and is formatted as defined in {{kdc-if-errors}}. Within the Custom Problem Detail entry 'ace-groupcomm-error', the value of the 'error-id' field MUST be set to 6 ("Group deleted"). * If a target group member specified a URI in the 'control_uri' parameter of the Join Request upon joining the group (see {{gid-post}}), the KDC can provide that group member with the new group keying material by sending a unicast POST request to that URI. @@ -1920,10 +1955,6 @@ Note that the media type application/ace-groupcomm+cbor MUST be used when these | Name | CBOR | CBOR Type | Reference | | | Key | | | +-----------------------+------+---------------------+------------+ -| error | TBD | int | [RFC-XXXX] | -+-----------------------+------+---------------------+------------+ -| error_description | TBD | tstr | [RFC-XXXX] | -+-----------------------+------+---------------------+------------+ | gid | TBD | array | [RFC-XXXX] | +-----------------------+------+---------------------+------------+ | gname | TBD | array of tstr | [RFC-XXXX] | @@ -2000,10 +2031,6 @@ A Client SHOULD support the following parameter. * 'get_creds'. That is, not supporting this parameter would yield the inconvenient and undesirable behavior where: i) the Client does not ask for the other group members' authentication credentials upon joining the group (see {{ssec-key-distribution-exchange}}); and ii) later on as a group member, the Client only retrieves the authentication credentials of all group members (see {{sec-key-retrieval-all}}). -A Client MAY support the following optional parameters. Application profiles of this specification MAY define that Clients must or should support these parameters instead (OPT15). - -* 'error', 'error_description'. - The following conditional parameters are relevant only if specific conditions hold. It is REQUIRED of application profiles of this specification to define whether Clients must, should, or may support these parameters, and under which circumstances (REQ30). * 'client_cred' and 'client_cred_verify'. These parameters are relevant for a Client that has an authentication credential to use in a joined group. @@ -2024,7 +2051,7 @@ The following conditional parameters are relevant only if specific conditions ho # ACE Groupcomm Error Identifiers {#error-types} -This specification defines a number of values that the KDC can include as error identifiers, in the 'error' field of an error response with Content-Format application/ace-groupcomm+cbor. +This specification defines a number of values that the KDC can use as error identifiers. These are used in error responses with Content-Format application/concise-problem-details+cbor, as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see {{kdc-if-errors}}). ~~~~~~~~~~~ +-------+---------------------------------------------+ @@ -2048,7 +2075,7 @@ This specification defines a number of values that the KDC can include as error ~~~~~~~~~~~ {: #fig-ACE-Groupcomm-Error-Identifiers title="ACE Groupcomm Error Identifiers" artwork-align="center"} -A Client supporting the 'error' parameter (see {{kdc-if-errors}} and {{params}}) and able to understand the specified error may use that information to determine what actions to take next. If it is included in the error response and supported by the Client, the 'error_description' parameter may provide additional context. +If a Client supports the problem-details format {{RFC9290}} and the Custom Problem Detail entry 'ace-groupcomm-error' defined in {{kdc-if-errors}}, and is able to understand the error specified in the 'error-id' field therein, then the Client may use that information to determine what actions to take next. If the Concise Problem Details data item specified in the error response includes the 'detail' entry and the Client supports it, such an entry may provide additional context. In particular, the following guidelines apply, and application profiles of this specification can define more detailed actions for the Client to take when learning that a specific error has occurred. @@ -2070,6 +2097,8 @@ In particular, the following guidelines apply, and application profiles of this Security considerations are inherited from the ACE framework {{RFC9200}}, and from the specific transport profile of ACE used between the Clients and the KDC, e.g., {{RFC9202}} and {{RFC9203}}. +When using the problem-details format defined in {{RFC9290}} for error responses, then the privacy and security considerations from {{Sections 4 and 5 of RFC9290}} also apply. + Furthermore, the following security considerations apply. ## Secure Communication in the Group {#sec-cons-communication} @@ -2223,6 +2252,16 @@ IANA is asked to register the following entry in the "Interface Description (if= * Reference: {{&SELF}} +## Custom Problem Detail Keys Registry {#iana-custom-problem-details} + +IANA is asked to register the following entry in the "Custom Problem Detail Keys" registry within the "CoRE Parameters" registry group. + +* Key Value: TBD +* Name: ace-groupcomm-error +* Brief Description: Carry {{&SELF}} problem details in a Concise Problem Details data item. +* Change Controller: IETF +* Reference: {{kdc-if-errors}} of {{&SELF}} + ## ACE Groupcomm Parameters {#iana-reg} This specification establishes the "ACE Groupcomm Parameters" IANA registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group. @@ -2442,7 +2481,7 @@ This section lists the requirements on application profiles of this specificatio * OPT4: Optionally, specify possible or required payload formats for specific error cases. -* OPT5: Optionally, specify additional identifiers of error types, as values of the 'error' field in an error response from the KDC. +* OPT5: Optionally, specify additional identifiers of error types, as values of the 'error-id' field within the Custom Problem Detail entry 'ace-groupcomm-error' (see {{kdc-if-errors}}). * OPT6: Optionally, specify the encoding of 'creds\_repo' if the default is not used (see {{gid-post}}). @@ -2462,8 +2501,6 @@ This section lists the requirements on application profiles of this specificatio * OPT14: Optionally, specify additional information to include in rekeying messages for the "Point-to-Point" group rekeying scheme (see {{sec-group-rekeying}}). -* OPT15: Optionally, specify if Clients must or should support any of the parameters defined as optional in this specification (see {{params}}). - # Extensibility for Future COSE Algorithms # {#sec-future-cose-algs} As defined in {{Section 8.1 of RFC9053}}, future algorithms can be registered in the "COSE Algorithms" registry {{COSE.Algorithms}} as specifying none or multiple COSE capabilities. From 0997a9f8a8370e1bba57edd787ee7eb384d96a7f Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 27 Oct 2023 11:55:05 +0200 Subject: [PATCH 15/18] Nits --- draft-ietf-ace-key-groupcomm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 68883be..1324f10 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -643,7 +643,7 @@ Note to RFC Editor: In the figure above, please replace "TBD" with the unsigned The problem-details format in general and the Custom Problem Detail entry 'ace-groupcomm-error' in particular are OPTIONAL to support for Clients. A Client supporting the entry 'ace-groupcomm-error' and able to understand the specified error may use that information to determine what actions to take next. -{{error-types}} of this specification defines an initial set of error identifiers, as possible values for the 'error-id' field. Application profiles of this specification inherit this initial set of error identifiers and MAY define additional value (OPT5). +{{error-types}} of this specification defines an initial set of error identifiers, as possible values for the 'error-id' field. Application profiles of this specification inherit this initial set of error identifiers and MAY define additional values (OPT5). ## /ace-group From dc91aba3cc04e2668b8c4e08c87da964c00307aa Mon Sep 17 00:00:00 2001 From: crimson Date: Sun, 5 Nov 2023 13:56:22 +0100 Subject: [PATCH 16/18] Simplified example of error response with Problem Details --- draft-ietf-ace-key-groupcomm.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 1324f10..1019a51 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -631,7 +631,6 @@ Payload: / title / -1: "No available node identifiers", / detail / -2: "Things will change after a group rekeying; try later", - / response-code / -4: 163, / 5.03 / / ace-groupcomm-error/ TBD: { / error-id / 0: 4 / "No available node identifiers" /, } From c220b92c9517f00fe59db1bf8d0ed2b5666d66ab Mon Sep 17 00:00:00 2001 From: crimson Date: Sun, 5 Nov 2023 13:57:36 +0100 Subject: [PATCH 17/18] Nits --- draft-ietf-ace-key-groupcomm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 1019a51..f851f9a 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -631,7 +631,7 @@ Payload: / title / -1: "No available node identifiers", / detail / -2: "Things will change after a group rekeying; try later", - / ace-groupcomm-error/ TBD: { + / ace-groupcomm-error / TBD: { / error-id / 0: 4 / "No available node identifiers" /, } } From c0b795c51d92bfff0dcd1a6960e119b7e537b633 Mon Sep 17 00:00:00 2001 From: crimson Date: Fri, 15 Dec 2023 18:37:04 +0100 Subject: [PATCH 18/18] Changelog appendix --- draft-ietf-ace-key-groupcomm.md | 42 ++++++++++++++++++++++++++++++--- 1 file changed, 39 insertions(+), 3 deletions(-) diff --git a/draft-ietf-ace-key-groupcomm.md b/draft-ietf-ace-key-groupcomm.md index 472c34f..3966d44 100644 --- a/draft-ietf-ace-key-groupcomm.md +++ b/draft-ietf-ace-key-groupcomm.md @@ -2495,13 +2495,49 @@ RFC EDITOR: PLEASE REMOVE THIS SECTION. ## Version -17 to -18 ## {#sec-17-18} -* Consistent use of leading slash in URI paths. +* Provided more details when early introducing "backward security" and "forward security". + +* Clarified definition and semantics of "group name" and "node name". + +* Clarified definition of "individual keying material". + +* Clarified definition of "Dispatcher". + +* Enforced consistent use of leading slash in URI paths. + +* Fixed CDDL definitions and examples in CBOR diagnostic notation. + +* RFC 9290 is used instead of the custom format for error responses. + +* Clarified which operations are limited to group members and which are allowed also to non group members. + +* Improved examples of message exchange. + +* Added ASCII-art diagrams with examples of group rekeying. + +* Clarified for how long nonces are stored at the KDC. + +* Clarified that the KDC might not have to store the 'cnonce' from a Join Request. * Consistency fix: Clients always support the 'cnonce' parameter. -* The KDC might not have to store the 'cnonce' from a Join Request. +* Added new parameter 'exi' providing the residual lifetime of the current group keying material. -* Fixes and editorial improvements. +* Clarified text about the KDC knowledge of compromised nodes. + +* Clarified the impact on performance of a one-to-many group rekeying. + +* Mentioned explicit exceptions to a group rekeying at each group membership change. + +* Explained reasons for delaying a rekeying and halting communications. + +* Fixes in current IANA registrations. + +* Added integer abbreviation values for registrations in new IANA registries. + +* IANA registration of two CoRE if= values: "ace.group" and "ace.groups". + +* Editorial fixes and improvements. ## Version -16 to -17 ## {#sec-16-17}