Re: [Ace] [Iot-directorate] Iotdir telechat review of draft-ietf-ace-key-groupcomm-17

[Marco Tiloca <[e-mail]>]

Hello Dave,

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=https%3A%2F%2F1drv.ms%2Fb%2Fs!Aqj-Bj9PNivcn95dv6L8FUsmfqCzfA%3Fe%3DeFgWDp&data=05%7C01%7Cmarco.tiloca%40ri.se%7C937156e3f6174c3fcc1408dbec61d542%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638363677158864870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lxoRVSM1jdpmgFgF%2FgPIbJd0kE2V3gKC3sD2YJ4ksiI%3D&reserved=0
>

==>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 it
> It 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 field
> So 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
>> name
> Why 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: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se