Thanks a lot for your review! Please find in line below our detailed replies to your comments.
A Github PR where we have addressed your comments is available at [PR].
Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews), and to submit the result as version -18 of the document.
Thanks,
/Marco
[PR] https://github.com/ace-wg/ace-key-groupcomm/pull/166
On 2023-11-23 21:21, Dave Thaler via
Datatracker wrote:
Reviewer: Dave Thaler Review result: Almost Ready See detailed comments in marked up PDF at https://eur05.safelinks.protection.outlook.com/ap/b-59584e83/?url="">
==>MT
We have editorially revised the document based on the separate marked up PDF.
<==
A summary of the non-trivial comments follows... Security issues: ---------------- Section 3.3:The KDC MUST store the 'kdcchallenge' value associated with the Client at least until it receives a Join Request from itIt seems to be that this can be used in a DOS attack, where a Client sends a bunch of token requests without join requests. Or even NON-attacks that just happen where a Client crashes after the token request and so never sends a join request... when can the KDC clean up state? This seems like a critical thing to discuss. Seems like you need the KDC to have a way to clean up stale state. For the intentional DoS attack, section 10.2 only mentions:The KDC needs to have a mechanism in place to detect DoS attacks from nodes repeatedly performing actions that might trigger a group rekeying.I’d recommend covering state-based DOS attacks as well such as mentioned above, with the same mitigation possible as already mentioned in 10.2.
==>MT
We do not think that this is actually a DoS vector or a source of inconvenience for the KDC.
While bearing in mind that the KDC is supposed to be equipped with plenty of resources and to be non constrained, the following also holds.
* A Client cannot just send "a bunch of tokens", since those have to be issued by the Authorization Server (AS) in the first place.
* At some point, an access token expires and the KDC deletes it. At that point in time, the KDC also terminates the secure association with the Client and deletes the 'kdcchallenge' value. (This point is something that we have now explicitly clarified, see below)
Therefore, the KDC will keep at most one kdcchallenge per access token, and only until the access token is deleted (e.g., when it expires). Note that the size of kdcchallenge is considerably smaller than the size of the access token and of the state to maintain the secure association with the Client. Hence, its contribution to a stale state at the KDC is negligible.
The KDC can thus operate as long as it is able to store access tokens altogether, irrespective of whether the Client actually sends a Join Request or not.
In order to clarify, we have rephrased the quoted paragraph of Section 3.3 as follows.
OLD
> The KDC MUST store the 'kdcchallenge' value associated with the Client at least until it receives a Join Request from it (see Section 4.3.1.1), to be able to verify the PoP evidence provided during the join process, and thus that the Client possesses its own private key.
NEW (emphasis mine)
> **While storing the access token**, the KDC MUST store the 'kdcchallenge' value associated with the Client at least until it receives a Join Request from it (see Section 4.3.1.1), to be able to verify the PoP evidence provided during the join process, and thus that the Client possesses its own private key. **The KDC deletes the 'kdcchallenge' value associated with the Client upon deleting the access token (e.g., upon its expiration, see Section 5.10.3 of [RFC9200]).**
<==
IoT Issues: ----------- Section 4.3.1:Group members MUST NOT use the keying material after the time indicated in this fieldSo this introduces a requirement that all Clients MUST have a clock and a clock synchronization (to UTC) mechanism? This seems burdensome for constrained nodes, so should be called out explicitly. Remote attestation (as specified in the RATS WG) on the other hand, allows alternative mechanisms that use nonces or handle distributors, to accommodate constrained nodes that either have no clock or no ability to synchronize it with UTC. In contrast, draft-ietf-ace-key-groupcomm does not seem amenable to such constrained nodes and as such I think it should be accompanied by an applicability statement (e.g., in the introduction or abstract) that says that this document is ONLT applicable to nodes with a clock that is synchronized to UTC, rather than implying it is usable by “constrained nodes” in general as the draft -17 abstract currently implies.
==>MT
We have defined an additional parameter 'exi' used in the Join Response, as well as in other responses from the KDC that convey group keying material (see below).
This parameter has the same high-level meaning of 'exi' used in RFC 9200 for access tokens, but here applied to the group keying material.
Section 4.3.1 is updated as follows:
OLD
> The response SHOULD contain the following parameter:
>
> * 'exp', with value the expiration time of the keying material for the group communication, encoded as a CBOR unsigned integer. This field contains a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in Section 2 of [RFC7519]. Group members MUST NOT use the keying material after the time indicated in this field, and they can retrieve the new group keying material from the KDC.
NEW (emphasis mine)
> The response SHOULD contain the **following parameters**:
>
> * 'exp', with value the expiration time of the keying material for the group communication, encoded as a CBOR unsigned integer. This field contains a numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds, analogous to what is specified for NumericDate in Section 2 of [RFC7519]. Group members MUST NOT use the keying material after the time indicated in this field, and they can retrieve the new group keying material from the KDC.
> * **'exi', with value the residual lifetime of the keying material for the group communication, encoded as a CBOR unsigned integer. If the 'exp' parameter is included, this parameter MUST also be included. This field contains a numeric value representing the residual lifetime of the keying material in seconds, i.e., the number of seconds between the current time at the KDC and the time when the keying material expires (as specified in the 'exp' parameter, if present). A Client determines the expiration time of the keying material by adding the seconds specified in the 'exi' parameter to its current time upon receiving the response containing the 'exi' parameter. The Client MUST NOT use the keying material after such an expiration time, and it can retrieve the new group keying material from the KDC.**
>
> **If a Client has a reliable way to synchronize its internal clock with UTC, and both the 'exp' and 'exi' parameters are present, then the Client MUST use the 'exp' parameter value as expiration time for the group keying material. Otherwise, the Client uses the 'exi' parameter value.**
>
> **When a Client relies on the 'exi' parameter, the expiration time that it computes is offset in the future with respect to the actual expiration time as intended by the KDC and specified in the 'exp' parameter (if present). Such an offset is the amount of time between when the KDC sends the response message including the 'exi' parameter and when the Client receives that message. That is, especially if the delivery of the response to the Client is delayed, the Client will believe the keying material to be valid for a longer time than the KDC actually means. However, before approaching the actual expiration time, the KDC is expected to rekey the group and distribute new keying material (see Section 6).**
Note that the text above uses "the response specifying the 'exi' parameter" instead of the "Join Response", even though Section 4.3.1 is exactly about the Join Response. This is intentional, so that the 'exi' parameter and its use become applicable also in the other two responses from the KDC that would also include 'exi' (see below).
We have mentioned the possible presence of the parameter 'exi' also in the text defining the responses to the following requests.
* The GET request to /ace-group/GROUPNAME , in Section 4.3.2
OLD
> The payload MAY also include the parameters 'ace_groupcomm_profile' and 'exp' parameters specified in Section 4.3.1.
NEW (emphasis mine)
> The payload MAY also include the parameters 'ace_groupcomm_profile'**, 'exp', and 'exi'** specified in Section 4.3.1. **If the ‘exp’ parameter is included, the 'exi' parameter MUST also be included. If the parameter 'exi' is included, its value specifies the residual lifetime of the group keying material from the current time at the KDC.**
* The GET request to /ace-group/GROUPNAME/nodes/NODENAME , in Sections 4.8.1 and 4.8.1.1
OLD (Section 4.8.1)
> The payload of the response is formatted as a CBOR map. The format for the group keying material is the same as defined in the response of Section 4.3.2.
NEW (Section 4.8.1) (emphasis mine)
> The payload of the response is formatted as a CBOR map, **which includes the same fields of the response defined in Section 4.3.2. In particular,** the format for the group keying material is the same as defined in the response of Section 4.3.2. **If the 'exp' parameter is included, the 'exi' parameter MUST also be included. If the parameter 'exi' is included, its value specifies the residual lifetime of the group keying material from the current time at the KDC.**
OLD (Section 4.8.1.1)
> Upon expiration of the keying material, according to what is indicated by the KDC with the 'exp' parameter (e.g., in a Join Response), or to a pre-configured value.
NEW (Section 4.8.1.1) (emphasis mine)
> Upon expiration of the keying material, according to what is indicated by the KDC with the 'exp' **and/or 'exi' parameter** (e.g., in a Join Response), or to a pre-configured value.
* Rekeying messages, in Section 6
OLD
> Each rekeying message ... 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.
NEW (emphasis mine)
> Each rekeying message ... **The CBOR map SHOULD also include the parameters 'exp' and 'exi'. If the ‘exp’ parameter is included, the 'exi' parameter MUST also be included. The CBOR map MAY include** the parameter 'mgt_key_material' specifying new administrative keying material for the target group members, if relevant for the used rekeying scheme.
* In Section 8
* We have added 'exi' to the set of ACE Groupcomm Parameters to register (Figure 39)
* We have added 'exi' to the set of the parameters that a Client MUST support
OLD
> A Client MUST support the following parameters.
>
> 'scope', 'gkty', 'key', 'num', 'exp', 'gid', 'gname', 'guri', 'creds', 'peer_identifiers', 'ace_groupcomm_profile', 'control_uri', 'rekeying_scheme'.
NEW (emphasis mine)
> A Client MUST support the following parameters.
>
> 'scope', 'gkty', 'key', 'num', 'exp', **'exi',** 'gid', 'gname', 'guri', 'creds', 'peer_identifiers', 'ace_groupcomm_profile', 'control_uri', 'rekeying_scheme'.
<==
Section 6.2:This yields an overall lower number of rekeying messages, thus potentially reducing the overall time required to rekey the group. On the other hand, it requires the KDC to provide and use additional administrative keying material to protect the rekeying messages, and to additionally sign them to ensure source authentication (see Section 6.2.1). Typically, this pays off in large-scale groups, where the introduced performance overhead is less than the one experienced by rekeying the group in a point-to-point fashion (see Section 6.1).Question: It may be less at the KDC, but would it be more overhead at the Clients which may be constrained nodes on battery power?
==>MT
We have revised the text in Section 6.2 as follows.
OLD
> This yields an overall lower number of rekeying messages, thus potentially reducing the overall time required to rekey the group. On the other hand, it requires the KDC to provide and use additional administrative keying material to protect the rekeying messages, and to additionally sign them to ensure source authentication (see Section 6.2.1). Typically, this pays off in large-scale groups, where the introduced performance overhead is less than the one experienced by rekeying the group in a point-to-point fashion (see Section 6.1).
NEW (emphasis mine)
> This yields an overall lower number of rekeying messages, thus potentially reducing the overall time required to rekey the group. On the other hand, it requires the KDC to provide and use additional administrative keying material to protect the rekeying messages, and to additionally sign them to ensure source authentication (see Section 6.2.1).
>
> **Compared to a group rekeying performed in a point-to-point fashion (see Section 6.1), a one-to-many group rekeying typically pays off in large-scale groups, due to the reduced time for completing the rekeying, a more efficient utilization of network resources, and a reduced performance overhead at the KDC. To different extents, it also requires individual group members to locally perform additional operations, in order to handle the administrative keying material and verify source authentication of rekeying messages. Therefore, one-to-many group rekeying schemes and their employment ought to ensure that the experienced performance overhead on the group members remains bearable also for resource-constrained devices.**
<==
Internationalization issues: ---------------------------- Section 1.1:* 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.Is this meant for human display, or *only* as part of a URI? If meant for human display, then how do you communicate what language it is in? Same question about NODENAME.
==>MT
GROUPNAME and NODENAME are URI path segments. As such, they adhere to the semantics defined for those in https://www.rfc-editor.org/rfc/rfc3986#section-3.3
As to "group name" and "node name", they do not reflect any particular language and they are simply text strings used as a name. Among other things, they appear in parameters of protocol messages (from this or other documents), can be value of link target attributes, or can be printed/displayed.
That said, and in alignment with the same constrained indicated by CBOR for the CBOR Text String major type (see https://www.rfc-editor.org/rfc/rfc8949.html#name-major-types ), we believe that it is sufficient to clarify that "group name" and "node name" are text strings encoded as UTF-8 [RFC3629].
We have rephrased their definition as follows:
OLD
> Group name: the invariant once established identifier of a group.
NEW
> Group name: the identifier of a group, as a text string encoded as UTF-8 [RFC3629]. Once established, it is invariant.
OLD
> Node name: the invariant once established identifier of a node.
NEW
> Node name: the identifier of a node, as a text string encoded as UTF-8 [RFC3629]. Once established, it is invariant.
<==
Section 4.1.2:* '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 "written in English" arguably violates IETF internationalization guidance. The "intended for software engineers" part is probably fine but not the "for device a network operators" part. One should not assume that device and network operators read English. Any text meant for human operator display should be localizable and have a language tag indicating what language the string is in.
==>MT
This point will be addressed by adopting the suggestion from the GENART Last Call review (see https://mailarchive.ietf.org/arch/msg/ace/GljJ5yj4BVylRYVQ96IieVqBrrg/ ) , and thus using the Problem Details format from RFC 9290 instead of the current custom error format.
In particular, RFC 9290 makes it possible to specify internationalization information, by means of the Standard Problem Detail entries "base-lang" and "base-rtl".
<==
Section 4.2.1:* 'gname', whose value is encoded as a CBOR array, containing zero or more group names. The elements of this array are encoded as text strings.In what language? (and if not required to be in English, then they cannot be guaranteed to be displayed correctly unless a language tag is also provided)
==>MT
Please see our response to the related comment above.
<==
URI issues: ------------- Section 4.1:Note that the root url-path "ace-group" used hereafter is a default nameWhy not use “.well-known/ace-group” and register it as a well-known path?
==>MT
We do not think that this is needed.
In fact, we are taking exactly the same approach that the ACE framework considers for its relevant resources, see Sections 5.8, 5.9, and 5.10.1 of RFC 9200.
As to discoverability, there are means in CoAP that take advantage of the well-known resource ./well-known/core at the KDC, which one can query by using appropriate target attributes for filtering.
<==
Clarity issues: --------------- Section 3.1 says including ‘scope’ in an Authorization Request is a MAY. Section 3.2 on the Authorization Response then says:Additionally, when included, the following parameter MUST have the corresponding values: * 'scope' has the same format and encoding of 'scope' in the Authorization Request, defined in Section 3.1. If this parameter is not present, the granted scope is equal to the one requested in Section 3.1.So what is the granted scope when scope was absent in the Authorization Request? Clarify.
==>MT
As defined in OAuth (RFC 6749), then inherited in ACE (RFC 9200), and in turn inherited in the present document, the AS would either rely on a default scope for the Client (if defined) or consider the Authorization Request malformed.
In particular, Section 3.3 of RFC 6749 says:
> If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined).
We are intentionally avoiding repetitions and restatements from RFC 9200, as it would be prone to possible misinterpretation and confusion.
<==
Furthermore, it then goes on to say:The proof-of-possession access token (in 'access_token' above) MUST contain the following parameters:[…]* a scope claim (see for example 'scope' registered in Section 8.14 of [RFC9200] for CWT). This claim specifies the same access control information as in the 'scope' parameter of the Authorization Response, if the parameter is present in the message, or as in the 'scope' parameter of the Authorization Request otherwise.Again, the Authorization Request section allows it to be absent. Is section 3.1 wrong, or is this text wrong?
==>MT
Regarding the Authorization Request in Section 3.1, please see our response to the previous comment, i.e., this document builds on ACE that in turn builds on OAuth.
The quoted text from Section 3.2 discusses a successful Authorization Response, which can either:
* Not include a 'scope' parameter, if the Authorization Request included the 'scope' parameter and the AS granted exactly that scope to the Client.
OR
* Include a 'scope' parameter, if:
* The 'scope' parameter was not included in the Authorization Request and the AS used the default scope for the Client.
OR
* The 'scope' parameter was included in the Authorization Request, but the AS granted a different scope than the requested one.
In either case, the AS has granted a scope to the Client, and that scope is always specified in the 'scope' claim of the Access Token. As discussed above, that scope is either:
* Present in the 'scope' parameter of the Authorization Response, if the 'scope' parameter in the Authorization Request was absent or specified a different scope.
OR
* Absent in the 'scope' parameter of the Authorization Response but present in the 'scope' parameter of the Authorization Request, i.e., the AS granted exactly the requested scope.
<==
Section 4.3.1:If, regardless the reason, the KDC replies with a 4.00 (Bad Request) error response, this response MAY have Content-Format set to application/ace-groupcomm+cbor and have a CBOR map as payload.Does this mean Content-Format normally has some other value, since this is only a MAY? I.e., it’s not obvious to me what the alternative is to this MAY.
==>MT
That was not the intent of the sentence.
If a 4.00 response is sent, this can be plain and simple without telling much, or it can instead have a payload (e.g., formatted as a CBOR map). In the latter case, the response has a Content-Format aligned with the payload, e.g., application/ace-groupcomm+cbor when the payload is a CBOR map that specifies the parameters mentioned in the following sentences.
We have rephrased the paragraph as follows.
OLD
> If, regardless the reason, the KDC replies with a 4.00 (Bad Request) error response, this response MAY have Content-Format set to application/ace-groupcomm+cbor and have a CBOR map as payload. For instance, the CBOR map can include a 'sign_info' parameter formatted as 'sign_info_res' defined in Section 3.3.1, with the 'cred_fmt' element set to the CBOR simple value "null" (0xf6) if the Client sent its own authentication credential and the KDC is not set to store authentication credentials of the group members.
NEW
> If, regardless the reason, the KDC replies with a 4.00 (Bad Request) error response, the payload of the response MAY be a CBOR map. For instance, the CBOR map can include a 'sign_info' parameter formatted as 'sign_info_res' defined in Section 3.3.1, with the 'cred_fmt' element set to the CBOR simple value "null" (0xf6) if the Client sent its own authentication credential and the KDC is not set to store authentication credentials of the group members. When the response payload is a CBOR map including such parameters, the error response has Content-Format set to application/ace-groupcomm+cbor.
The use of a different payload, with different semantics and parameters, would require a different Content-Format that is up to other specifications/applications to define.
<==
* If the application requires backward security or if the used application profile prescribes so, the KDC MUST generate new group keying material and securely distribute it to the current group members (see Section 6).How does the KDC know whether this is the case? Clarify or provide a “(see <reference> for more details)” if explained elsewhere.
==>MT
As mentioned in the text, this information can come from the used application profile of this specification. In such a case, the KDC enforcing that application profile is also aware of those requirements.
If this information comes more generally from the "application", then it's about configuring application policies at the KDC, as appropriate to the particular network/application scenario. This can also possibly differ on a per-group basis.
The details of how such configuration are performed are out of the scope of this specification. We have expanded the following two paragraphs as follows.
OLD (Section 4.3.1)
> If the application requires backward security or if the used application profile prescribes so, the KDC MUST generate new group keying material and securely distribute it to the current group members (see Section 6).
NEW (Section 4.3.1) (emphasis mine)
> **If backward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then** the KDC MUST generate new group keying material and securely distribute it to the current group members (see Section 6).
OLD (Section 5)
> 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 Section 6).
NEW (Section 5) (emphasis mine)
> **If forward security is prescribed by application policies installed at the KDC or by the used application profile of this specification, then** the KDC MUST generate new group keying material and securely distribute it to all the current group members except the leaving node (see Section 6).
<==
Section 4.6.1:In addition to what is defined in Section 4.1.2, the handler verifies that the Client is a current member of the group.To confirm: Since this statement does not appear in the preceding sections, does that mean those requests do not require the Client to be a member of the group?
==>MT
These details are correct throughout the document. Most resources at the KDC are intended only for group members. The exceptions are:
* /ace-group/GROUPNAME/creds , to retrieve the authentication credential of (some) current group members.
* /ace-group/GROUPNAME/kdc-cred , to retrieve the authentication credential of the KDC.
* /ace-group/GROUPNAME , for joining the group.
* /ace-group , for retrieving group names of certain groups, whose identifiers are specified in the request.
Regarding the last resource, when processing the TSVART review we noted that it's better to clarify that it is indeed intended also for nodes that are not members of any group at the KDC.
That is, in the bullet point about /ace-group in Section 4.1 "Interface at the KDC", we have added the following text:
> 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).
This is tracked in a different Github branch, see https://github.com/ace-wg/ace-key-groupcomm/commit/73c9f7e6b4aab628a185b3ff0d7acc960910a5eb
<==
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
Attachment:
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
