Re: [Ace] AD review draft-ietf-ace-key-groupcomm-16

[Marco Tiloca <[e-mail]>]

Hello Paul,

The authors have discussed your review comments and compiled detailed 
replies in line below.

Based on those, we will now proceed updating the Editor's copy on Github 
[1] towards version -17, also taking into account any follow-up feedback 
from your side.

Thanks,
/Marco

[1] https://github.com/ace-wg/ace-key-groupcomm


On 2023-09-01 15:53, Marco Tiloca wrote:
> Hi Paul,
>
> Thank you for your review, we will start working on it.
>
> When addressing your comments, we will also process a few more recent 
> points tracked as Github issues [0]. In particular:
>
> - Issues 148, 150, and 151 are about editorial fixes/improvements.
>
> - Issues 147 is about clarifications, while issue 149 is about fixes 
> in the IANA considerations.
>
> - Issue 146 is about relaxing the now-mandatory inclusion of one 
> parameter in a message.
>
>    This issue 146 was first brought up to the WG at the ACE interim 
> meeting on 2022-09-12, further elaborated on its Github entry, and 
> then confirmed at the ACE interim meeting on 2022-12-19.
>
>
> Best,
> /Marco
>
> [0] https://github.com/ace-wg/ace-key-groupcomm/issues
>
>
> On 2023-09-01 02:26, Paul Wouters wrote:
>>
>> 	
>> You don't often get email from [e-mail]. Learn why this 
>> is important <https://aka.ms/LearnAboutSenderIdentification>
>> 	
>>
>> Hi,
>>
>> Thanks for this document and my apologies for the long wait time.
>>
>> I think this document is mostly ready to go. I have a few questions 
>> and some comments on what I think are changes needed for the IANA 
>> Considerations section.
>>
>>
>>
>> 1) Race conditions with group rekey
>>
>> Section 2:
>>
>> When a group rekeys so an new member joining won't be able to read
>> old messages, how are race conditions prevented? eg one node wants to
>> send a message, but processes a group rekey, then sends the message it
>> had. Then the new member join is complete and that message can be read
>> by the new member.

==>MT

As you also noticed, a discussion on these aspects comes later in the 
security considerations, i.e., in Section 10.2.1 "Misalignment of Group 
Keying Material" (about which we give a specific reply to your comment 
further below).

At this point in the document, we should better clarify what we mean 
with "old messages". Those are messages exchanged in the group and 
protected with keying material older than the one provided to the 
joining node.

Clearly, once the joining node obtains the new keying material, the 
joining node becomes able to read any message protected with it, even if 
those messages were sent before the joining procedure was completed. 
However, the joining node will not be able to read "old messages", i.e., 
messages protected with keying material having a strictly lower version 
number num.

For the sake of simplicity, we preferred not to discuss and analyze 
different strategies (each with pros and cons) that the KDC can follow, 
e.g., fully rekeying the group first and then providing the new keying 
material to the joining node, or vice versa, or a hybrid approach. We 
can however clarify in: Sections 2 "Overview" (within the bullet point 3 
above Figure 2); in Section 6 "Group Rekeying Process"; and in Section 
10.2 "Update of Group Keying Material" (in the security considerations).

<==

>>
>> Section 6:
>>
>>         The KDC MUST increment the version number NUM of the current
>>         keying material, before distributing the newly generated keying
>>         material with version number NUM+1 to the group.
>>
>> So when the KDC increments the version, and starts distributing the new
>> keying material, any client requesting "num" will believe it is behind
>> and request a new copy? Wouldn't this cause duplicate rekeys?

==>MT

Trying to clarify, let's consider this general sequence of events.

1. The current keying material has version num=1
2. The KDC generates new keying material, with version num=2
3. The KDC starts rekeying the group and distributes the new keying 
material with version num=2
4. (the group rekeying is ongoing)
5. A group member that has not yet received the new keying material via 
the group rekeying sends a GET request to the KDC at ace-group/GROUPNAME/num
6. The response from the KDC specifies num=2
7. (maybe the group rekeying is still ongoing or maybe not, it doesn't 
really matter ...)

At step 5, since the group member has not already received the new 
keying material, the group member still has the old keying material with 
version num=1 and wrongly believes it to be the latest one, until 
receiving the response from the KDC at step 6. Therefore, at step 6, 
indeed the group member learns and believes to be behind, because it 
actually **is** behind.

The group member can now do two things:

* Assume that a group rekeying is ongoing, and just wait for receiving 
the group keying material through such a rekeying process; or
* Send a request to the KDC resource at ace-group/GROUPNAME, thus 
retrieving the new keying material with version num=2.

In either case, there is no "duplicate rekey".

In the first case, a rekeying is in fact already ongoing and no further 
one is expected to follow back-to-back.

In the second case, the request from the group member is not going to 
trigger yet another group rekeying (and, in general, scheduling group 
rekeying instances is a prerogative entirely of the KDC). That is, any 
group member can request the keying material from the KDC at any time, 
and will get the latest keying material as a result (nothing more will 
happen).

Therefore, we believe that no addition or change to the document should 
be required, as we cannot see text that contradicts the above or 
suggests anything different.

<==

>>
>> I see this is partially addressed in the Security Considerations, but
>> I feel handling these race conditions is part of the actual protocol,
>> not merely a security consideration?

==>MT

Please see the reply to that later comment, as also considering to move 
up that text from the security considerations and have it earlier in the 
document.

<==

>>
>> 2) IV/counter re-use
>>
>> Section 4:
>>
>> Symmetric keys are shared between group members. How is it prevented that
>> same IVs/counters are used by different members of the group? (there is
>> some talk about Base IV and Partial IV, but that didn't seem to answer
>> my question

==>MT

We talk about "Partial IV" and "Base IV" only much later in Section 
6.2.1 "Point-to-Point Group Rekeying", when discussing specifically 
about how to protect group rekeying messages in the proposed rekeying 
protocol. That is, that section does not refer to the use of the group 
keying material to protect the communication between the group members.

Instead, with respect to the secure communication among the group 
members, the proper use of counters/IVs as well as avoiding the reuse of 
pairs (AEAD Key, AEAD Nonce) is strictly related to the particular 
secure communication protocol used in the group. While that protocol 
determines the specific group keying material, such a protocol and its 
security are out of the scope of this document, which defines only a 
common stub of ACE application profiles for the provisioning of group 
keying material with ACE.

That information is instead expected from an application profile of this 
document, and even such an application profile may take these aspects 
for granted, as already defined by the used secure communication 
protocol indicated by the application profile. To give two concrete 
examples:

* The application profile in draft-ietf-ace-key-groupcomm-oscore 
incarnates this document to support secure group communication for CoAP 
protected with Group OSCORE, and takes Group OSCORE "as is" per its 
definition in draft-ietf-core-oscore-groupcomm, which relies on 
constructions that ensure a proper, safe use of keys, sequence numbers, 
and IVs.

* The application profile in draft-ietf-ace-pubsub-profile incarnates 
this document to support secure group communication in CoAP Pub-Sub 
scenarios, protecting end-to-end the content of messages between 
publishers and subscribers using COSE. This application profile is 
directly specifying aspects such as handling of IVs, since it is also 
defining the actual protocol for end-to-end protection of messages 
between the group members.

If this was not clear enough, a possibility is to extend the text of one 
paragraph in Section 1 as follows:

OLD
 > Therefore, this document delegates details ... provided to group members.

NEW
 > Therefore, this document delegates details ... provided to group 
members. The actual protection of group communication can be defined in 
a further specification (e.g., as a self-standing secure communication 
protocol) that application profiles of this document can seamlessly rely 
and build on if they do not define it themselves.

<==

>>
>> 3) IANA port registration?
>>
>>         optionally together with a port number (which defaults to 
>> 5683 if omitted)
>>
>> Is this port going to be registered with IANA ?

==>MT

Quoting the full sentence for completeness:

 > The URI MUST specify addressing information intended to reach all the 
members in the group. For example, this can be a multicast IP address, 
optionally together with a port number (which defaults to 5683 if omitted).

We think that your comment can be referring to two different aspects.

A first one is about the exact port number 5683 (which is already 
registered), and we can improve the text by rephrasing it as follows.

NEW
 > The URI MUST specify addressing information intended to reach all the 
members in the group. For example, this can be a multicast IP address, 
optionally together with a port number that, if omitted, defaults to 
5683, i.e., the default port number for the "coap" URI scheme (see 
Section 6.1 of [RFC7252]).

The second aspect is about registering a new port number used as 
destination port number in the mentioned multicast request. We think it 
is not absolutely necessary to register such a well-known port number. 
Application profiles might have a reason for defining and registering a 
specific port number, and in such a case they are free to do so.

<==

>>
>> 4) PoP evidence with own nonce
>>
>> Section 4.5.1:
>>
>>         The PoP evidence is computed over the nonce specified in the
>>         'kdc_nonce' parameter and taken as PoP input, by means of the
>>         same method used when preparing the Join Response
>>
>> What is the point of the nonce here? Since the nonce comes from the 
>> same party that
>> uses the nonce, it doesn't "prove" anything, eg it could be a replay 
>> of a previously
>> observed/triggered nonce. Can you explain what the purpose of the 
>> nonce is?
>>
>> Similar in Section 4.9.1.1 where the Client updates its 
>> Authentication credential,
>> and uses its own nonce to prove possesion of the private key.

==>MT

TLDR; Good point. The following describes a simple fix, to always 
involve in the computation of the Proof-of-Possession evidence also a 
nonce from the other peer.

As discussed below, this review comment applies also to Section 4.3.1, 
but it actually does not apply to 4.9.1.1.

**Change 1 - Section 4.3.1, first part**

This part covers the Join Request, i.e., a POST request to 
ace-group/GROUPNAME

In this request, the joining node specifies a PoP evidence in the 
parameter 'client_cred_verify', to prove possession of its private key 
corresponding to its authentication credential conveyed in the parameter 
'client_cred'.

The PoP input is: (scope | N_S | N_C) , where:

- 'scope' is as specified in another parameter of the same Join Request
- N_S is typically the latest 'kdc_challenge' that the joining node has 
obtained from the KDC, either as a response to the Token upload to 
/authz-info, or from an error response from this ace-group/GROUPNAME 
resource. Alternative methods rely, e.g., on TLS exporters as defined 
for a corner case in the application profile for Group OSCORE.
- N_C is a nonce generated by the joining node and included in the 
parameter 'cnonce' of this Join Request.

What needs to change here? (as useful in the following points ...)

OLD
 > 'cnonce', encoded as a CBOR byte string, and including a dedicated 
nonce N_C generated by the Client. This parameter MUST be present if the 
'client_cred' parameter is present.

NEW
 > 'cnonce', encoded as a CBOR byte string, and including a dedicated 
nonce N_C generated by the Client. This parameter MUST be present.

**Change 2 - Section 4.3.1, second part**

This part covers the Join Response, i.e., the response produced by the 
POST handler of ace-group/GROUPNAME

In this response, the KDC specifies a PoP evidence in the parameter 
'kdc_cred_verify', to prove possession of its private key corresponding 
to its authentication credential conveyed in the parameter 'kdc_cred'.

Currently, the PoP input is only a nonce generated at this point in time 
by the KDC, and specified in the 'kdc_nonce' parameter of this response.

What needs to change here?

OLD
 > The PoP input is: kdc_nonce

NEW
 > * The PoP input is: (N_C | kdc_nonce), where N_C is the nonce 
specified by the joining node in the 'cnonce' parameter of the Join 
Request (now to be always included there, per the "Change 1" explained 
above).
 > * After sending this successful Join Response, the KDC stores N_C as 
associated with this group member.

**Change 3 - Section 4.5.1**

This section covers the GET request-response exchange to 
ace-group/GROUPNAME/kdc-cred . A group member can send such a GET 
request to retrieve the latest authentication credential of the KDC.

In the response to this request, the KDC specifies a PoP evidence in the 
parameter 'kdc_cred_verify', to prove possession of its private key 
corresponding to its authentication credential conveyed in the parameter 
'kdc_cred'.

Currently, the PoP input is only a nonce generated at this point in time 
by the KDC, and specified in the 'kdc_nonce' parameter of this response.

What needs to change here?

OLD
 > The PoP input is: kdc_nonce

NEW
 > The PoP input is: (N_C | kdc_nonce), where N_C is the nonce specified 
by the joining node in the 'cnonce' parameter of the Join Request (now 
to be always included there, per the "Change 1" explained above) and 
that the KDC stored after having sent the corresponding Join Response at 
that point in time.

**No change - Section 4.9.1**

This section covers the POST request-response exchange to 
ace-group/GROUPNAME/nodes/NODENAME/cred . A group member can send such a 
POST request to upload its own, updated authentication credential.

In this request, the group member specifies a PoP evidence in the 
parameter 'client_cred_verify', to prove possession of its private key 
corresponding to its authentication credential conveyed in the parameter 
'client_cred'.

The PoP input is: (scope | N_S | N_C) , where:

- 'scope' is as specified in the original Join Request
- N_S is the value of 'kdc_challenge' the group member has received from 
the KDC, irrespective of how exactly.
- N_C is a nonce generated by the joining node at this point in time, 
and included in the parameter 'cnonce' of this request.

The text in Section 4.9.1 already says (emphasis mine):

 > In particular, the PoP evidence included in 'client_cred_verify' is 
computed in **the same way** considered in Section 4.3.1 and defined by 
the specific application profile (REQ14), with a newly generated N_C 
nonce and **the previously received N_S**.

Therefore, the raised issue does not apply in this section. The PoP 
input in fact includes not only a brand new N_C from the group member, 
but also a nonce N_S generated by the KDC and that the group member 
already knows from earlier steps. In other words, even though N_S is 
indeed not sent again on the wire (see Figure 32), it is used as part of 
the PoP input to compute the PoP evidence. This section should thus be 
ok as is.

<==

>>
>> COMMENTS:
>>
>>
>> Section 1:
>>
>>         If the application requires backward and forward security
>>
>> What is "backward security" ? I assume a new member not seeing old
>> msgs. Maybe explain that?

==>MT

Correct; this is later expanded in the security considerations of 
Section 10.2, but we can try to give the intuition here. Proposed 
rephrasing:

OLD
 > If the application requires backward and forward security, new keying 
material is generated and distributed to the group upon membership 
changes (rekeying).

NEW
 > New keying material is generated and distributed to the group upon 
membership changes (rekeying), if the application requires backward 
security (new group members must be prevented from accessing 
communications in the group prior to their joining) and forward security 
(former group members must be prevented from accessing communications in 
the group after their leaving).

<==

>>
>>
>> Section 2:
>>
>>         The full procedure can be separated
>>
>> The full procedure being "add member to group" ?

==>MT

Quoting the full paragraph in question (that's how Section 2 starts):

 > The full procedure can be separated in two phases: the first one 
follows the ACE Framework, between Client, AS and KDC; the second one is 
the key distribution between Client and KDC. After the two phases are 
completed, the Client is able to participate in the group communication, 
via a Dispatcher entity.

"Full procedure" does not refer to adding a member to a group. Per the 
document title, the "full procedure" is the "key provisioning for group 
communication using ACE".

Instead, "adding a member to a group" is only (a specific case of) the 
second phase, when a new node is added to the group and it is also 
provided with the necessary keying material.

Proposed rephrasing of the same paragraph:

**NEW**
 > At a high level, the key provisioning process is separated in two 
phases: the first one follows the ACE Framework between Client, AS, and 
KDC; the second one is the actual key distribution between Client and 
KDC. After the two phases are completed, the Client is able to 
participate in the group communication, via a Dispatcher entity.

<==

>>
>> The overview for "Dispatcher" does not make it clear whether it can read
>> the content to be dispatched from the client, or not.

==>MT

Quoting the definition of "Dispatcher"

 > * Dispatcher: entity through which the Clients communicate with the 
group, when sending a message intended to multiple group members. That 
is, the Dispatcher distributes such a one-to-many message to the group 
members as intended recipients. A single-recipient message intended to 
only one group member may be delivered by alternative means, with no 
assistance from the Dispatcher.
 >
 >    Examples of a Dispatcher are: the Broker in a pub-sub setting; a 
relayer for group communication that delivers group messages as multiple 
unicast messages to all group members; an implicit entity as in a 
multicast communication setting, where messages are transmitted to a 
multicast IP address and delivered on the transport channel.

Short answer: yes, it can. We can extend the definition above by adding 
the following note.

 > If it consists of an explicit entity such as a pub-sub Broker or a 
message relayer, the Dispatcher is comparable to an untrusted on-path 
intermediary, and as such it is able to read the messages sent by 
Clients in the group.

<==

>>
>> Section 4:
>>
>>         As most important operation after trasferring the access token to
>>         the KDC, the Client can perform a Join Request-Response exchange
>>         with the KDC, by specifying the group it requests to join
>>
>> Should "group" be "group(s)" ?

==>MT

No, it is correct as is. To quote the full paragraph (emphasis mine):

 > As most important operation after transferring the access token to 
the KDC, the Client can perform a Join Request-Response exchange with 
the KDC, by specifying **the group** it requests to join (see Section 
4.3.1.1). Then, the KDC verifies the access token and that the Client is 
authorized to join **the specified group**. If so, the KDC provides the 
Client with the keying material to securely communicate with the other 
members **of the group**.

The access token can indeed specify multiple groups that the client is 
authorized to join. However, the Join Request is specifically about 
joining one group.

<==

>>
>>         to join the specified group
>>
>> Should "group" be "group(s)" ?

==>MT

See the answer to the previous comment, also referring to the same 
paragraph.

<==

>>
>>
>>         /ace-group/GROUPNAME/creds : this resource is invariant once
>>         established, and contains the authentication credentials of all
>>         the members of the group with name GROUPNAME.
>>
>> How is this "invariant" when it changes depending on group members? Am
>> I misunderstanding the term "invariant" ?

==>MT

"Invariant" does not mean that the representation of the resource does 
not change. If we meant that, then that statement would be indeed wrong 
for all the resources for which we use it.

We actually refer to the resource path, and we can rephrase as below.

OLD
 > this resource is invariant once established

NEW
 > the path of this resource is invariant once the resource is established

For completeness, this applies to all the resources for which we are 
making that statement, i.e.:

* /ace-group
* /ace-group/GROUPNAME/creds
* /ace-group/GROUPNAME/kdc-cred
* /ace-group/GROUPNAME/policies
* /ace-group/GROUPNAME/num
* /ace-group/GROUPNAME/nodes/NODENAME/cred

<==

>>
>> Section 4.1
>>
>>         The KDC can provide a list of group names that exist. Can this
>>         access be restricted to a partial list depending on the client?

==>MT

This operation is intentionally meant to serve any authorized client, 
also to facilitate a possible group (re-)joining. In fact, this 
operation is permitted both to members and non-members of the groups 
indicated in the request to the KDC.

As long as the access token grants permission to access the KDC resource 
at /ace-group, then any node can send a FETCH request to that resource, 
and retrieve the names and joining URI of all the groups for which the 
current group identifier was specified in the request.

<==

>>
>> Section 4.3.1
>>
>>         Group members MUST stop using the keying material to protect
>>         outgoing messages and retrieve new keying material at the time
>>         indicated in this field.
>>
>> Don't you mean "retrieve new keying material before this time" and "start
>> using the new key material after this time"?

==>MT

This sentence can be confusing, as it's discussing two aspects blended 
together. Proposed rephrasing:

 > 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.

<==

>> Related in 4.8.1.1 it says:
>>
>>         In either case, if it wants to continue participating in the
>>         group communication, the node has to request the latest keying
>>         material from the KDC.
>>
>> and:
>>
>>         if the Client wants to be sure that it has the latest group 
>> keying
>>         material. If that is the case, the Client will receive from the
>>         KDC the same group keying material it already has in memory.
>>
>> Seems to suggest key material is not available before expiry time. 
>> That is,
>> there is always a downtime of a few RTTs when the keying material 
>> expired, as
>> clients cannot prefetch new keying material ahead of time ? I think 
>> it would
>> be a lot more robust if clients could prefetch the new key slightly 
>> before
>> the expiry time. Then adjust for group membership changes to ensure a 
>> rekey
>> is done if the leaving member could (or has) obtained the num+1 
>> keying material?

==>MT

That's not a suggestion that we want to give. It's ultimately up to the 
KDC to decide when to exactly produce the new group keying material, in 
order to distribute it through a group rekeying and make it available 
for manual fetching.

That can even happen after the expiration of the old group keying 
material, if it's acceptable or there are reasons to put on pause the 
secure communications in the group for a while, after the old keying 
material expires.

At the same time, there is no possible "prefetching": only one, latest 
version of the group keying material is available at the KDC. Retrieving 
it can be interpreted as a "prefetch", in the sense that "the new group 
keying material is available to retrieve before the old keying material 
reaches its expiration time".

On the comment:

 > Then adjust for group membership changes to ensure a rekey is done if 
the leaving member could (or has) obtained the num+1 keying material?

This does not require any adjustment. In the considered situation, as 
long as the application profile mandates forward security (like in the 
case of draft-ietf-ace-key-groupcomm-oscore), a group rekeying has to 
happen, in order to distribute a new version of the keying material with 
value num=2.

This can be clarified by extending a paragraph of Section 4.8.1.1 as 
follows:

OLD
 > In either case, if it wants to continue participating in the group 
communication, the node has to request the latest keying material from 
the KDC. To this end, the Client sends a CoAP GET request to the 
/ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as 
specified in Section 4.8.1.

NEW
 > In either case, if it wants to continue participating ..., formatted 
as specified in Section 4.8.1. The Client can request the latest keying 
material from the KDC before the keying material reaches its expiration 
time.

Also, we can make the following addition in Section 6 "Group Rekeying 
Process":

OLD
 > Reasons that can trigger a group rekeying are a change in the group 
membership, the current group keying material approaching its expiration 
time, or a regularly scheduled update of the group keying material.

NEW
 > Reasons that can trigger ... of the group keying material.
 >
 > The KDC can perform a group rekeying before the current group keying 
material expires, unless it is acceptable or there are reasons to 
temporarily pause secure communications in the group, following the 
expiration of the current keying material.

<==

>>
>> Section 4.8.2:
>>
>>         Not providing the Client with newly generated, individual keying
>>         material, but rather rekeying the whole group
>>
>> Doesn't this open up a denial of service possibility with a malicious 
>> client?
>> The Security Considerations do warn about this and that requests for 
>> rekeys
>> can be ignored by the KDC, so this is okay.

==>MT

Good. Note that a following paragraph in the same section says:

 > Note that this handler is not intended to accommodate requests from a 
group member to trigger a group rekeying, whose scheduling and execution 
is an exclusive prerogative of the KDC.

We can extend this paragraph, by adding a pointer to the security 
considerations, i.e.:

 > ... prerogative of the KDC (see also related security considerations 
in Section 10.2).

Furthermore, note that the quoted text is immediately preceded by:

 > However, application profiles of this specification MAY also extend 
this handler in order to achieve different akin outcomes (OPT12), for 
instance:

This is in fact what happens in the corresponding Section 9.2 "Request 
to Change Individual Keying Material" of the application profile 
draft-ietf-key-groupcomm-oscore for Group OSCORE, which says:

 > The Group Manager SHOULD perform a group rekeying only if already 
scheduled to occur shortly, e.g., according to an application-specific 
rekeying period or scheduling, or as a reaction to a recent change in 
the group membership. In any other case, the Group Manager SHOULD NOT 
rekey the OSCORE group when receiving a Key Renewal Request (OPT12).

<==

>>
>> What is "individual keying material" ? Is based on the security
>> association the client <-> KDC have based on the transport protocol?

==>MT

No, it is not related to the Client <-> KDC secure association; it is 
related to the membership of that Client to the secure group GROUPNAME, 
hence to the keying material and other information pertaining to that group.

Note that the Client <-> KDC secure association has nothing to do with 
the secure communication within the group; the former is based on 
whatever transport profile of ACE (e.g., RFC 9202, RFC 9203), while the 
latter is based on what is specified by an application profile of this 
document.

Consistent with the intended generality of this document, in the earlier 
Section 4.8.1 we say:

 > The specific format of 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 
Section 11.6.

To better clarify, we can add the following new entry to the terminology 
in Section 1.1:

 > * Individual keying material: information exclusively pertaining to a 
group member, as associated with its group membership and related to 
other keying material and parameters used in the group. For example, 
this can be a member identifier that is unique within the group. The 
specific nature and format of individual keying material used in a group 
is defined in application profiles of this specification. The individual 
keying material of a group member is not related to the secure 
association between that group member and the KDC.

<==

>>
>> Section 5:
>>
>>         A Client identified by NODENAME may be removed from a group
>>         identified by GROUPNAME where it is a member, due to the
>>         following reasons.
>>
>> I don't think the following list is a complete set of possible 
>> reasons. I would
>> rephrase this along the lines of "for example, for the following 
>> reasons".

==>MT

Correct. Proposed rephrasing:

 > A Client identified by NODENAME may be removed from a group 
identified by GROUPNAME where it is a member, for example due to the 
following reasons.

<==

>>
>> Section 6:
>>
>>         In case the KDC deletes the group, this also allows the KDC to
>>         send an unsolicited 4.04 (Not Found) response
>>
>> What does "this" refer to? Making the resource Observable ?

==>MT

Indeed. Proposed rephrasing:

 > 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 ...

<==

>>
>> Section 6.2.1:
>>
>>         COUNT, as a 1-byte unsigned integer associated with the used
>>         encryption key. Its value is set to 0 when starting to perform
>>         a new group rekeying instance, and is incremented after each
>>         use of the encryption key.
>>
>> This limits the key to only be used for 256 messages. Is that enough for
>> large groups of thousands of devices? Or are groups to be expected to be
>> smaller? Or should those groups anticipate this and switch to one-to-many
>> rekey methods? Wouldn't 2 bytes create a much larger safety margin at
>> a very little cost?

==>MT

Good point; 2 bytes is better. Then, we can update the text to be as 
follows.

 > - COUNT, as a 2-byte unsigned integer associated with the used 
encryption key. Its value is set to 0 when starting to perform a new 
group rekeying instance, and is incremented after each use of the 
encryption key.
 >
 > - NEW_NUM, as the version number of the new group keying material to 
distribute in this rekeying instance, left-padded with zeroes to exactly 
NONCE_SIZE - 2 bytes.

Also, after the paragraph

 > Then, the KDC computes a Partial IV as the byte string concatenation 
of COUNT and NEW_NUM, in this order. Finally, the AEAD nonce is computed 
as the XOR between the Base IV and the Partial IV.

it's also better to add the note:

 > In order to comply with the security requirements of AEAD encryption 
algorithms, the KDC MUST NOT use the same pair (encryption key, AEAD 
nonce). For example, this includes not using the same encryption key 
from the administrative keying material more than (2^16 - 1) times 
during the same rekeying instance.

<==

>>
>>
>> Section 10.2:
>>
>>         The KDC should renew the group keying material upon a
>>         group membership change. Since the minimum number of group
>>         members is one, the KDC should provide also a Client joining
>>         an empty group with new keying material never used before in
>>         that group. Similarly, the KDC should provide new group keying
>>         material also to a Client that remains the only member in the
>>         group after the leaving of other group members.
>>
>> Why are these "should"s not normative, eg SHOULDs ?

==>MT

Proposed rephrasing also addressing the comment:

 > Unless otherwise defined by an application profile of this 
specification, the KDC SHOULD renew the group keying material upon a 
group membership change. In particular, since the minimum number of 
group members is one, the KDC SHOULD provide also a Client joining an 
empty group with new keying material never used before in that group. 
Similarly, the KDC SHOULD provide new group keying material also to a 
Client that remains the only member in the group after the leaving of 
other group members.

<==

>>
>> Section 10.2.1
>>
>> This (finally) addresses my race condition questions....

==>MT

This relates to "race conditions" as to possible misalignment of group 
keying material among group members when a rekeying has been happening.

We can make the following changes to make this content more and earlier 
visible:

* This Section 10.2.1 can be moved up, when presenting the group 
rekeying in Section 6. For example, it can become a new Subsection 6.3. 
Note that its content is independent of the specific approach used to 
rekey the group.

* Early in Section 2, we can include a forward pointer about these 
considerations to be found in Section 6.

<==

>>
>>         In any case, the recipient should actively ask the KDC for the
>>         latest group keying material according to an application-defined
>>         policy, for instance after a given number of unsuccessfully
>>         decrypted incoming messages.
>>
>> Seeing that the KDC presumably is hard at work distributing new 
>> keying material,
>> would nodes sending more requests to the KDC not just make things worse?

==>MT

Interesting point, although it's not exactly about DoS (like discussed 
at the end of Section 10.2.0) since it's about requests to the KDC done 
in "good faith".

This applies pretty much to every possible access to the KDC, but 
especially to the operations referred by the comment and defined in 
Sections 4.3.2.1 and 4.8.1.1.

To clarify, we can point especially to the operations defined in 
Sections 4.3.2.1 and 4.8.1.1, and add the following text in Section 6.0 
"Group Rekeying Process".

 > In order to facilitate the completion of a group rekeying instance, 
the KDC MAY stop serving requests pertaining to the group in question 
until the group rekeying is completed. This especially applies to Key 
Distribution Requests (see Sections 4.3.2.1 and 4.8.1.1) and Join 
Requests (see Section 4.3.1.1). The KDC MAY reply to those requests with 
a 5.03 (Service Unavailable) error response, including the Max-Age CoAP 
Option to indicate after how long a new request can be sent (see 
Sections 5.9.3.4 and 5.10.5 of [RFC7252]).

<==

>> Maybe
>> it should also mention that it MUST first verify the signature of the 
>> node sending
>> the encrypted payload before deciding it might need to ask for the 
>> updated group
>> key material to prevent spoofed messages trying to trigger all 
>> clients to send
>> requests to the KDC to overload it ?  (I can also see that this is a 
>> very obvious
>> thing to do anyway, so perhaps this advise is meaningless)

==>MT

We understand that, in the sentence

 > it MUST first verify the signature of the node sending the encrypted 
payload before deciding it might need to ask for the updated group key 
material ...

the subject "it" is a group member that receives a protected message, 
fails to verify the message, and decides to ask the KDC for the current 
group keying material.

First of all, we cannot just generally talk of signed group messages and 
verification of their signatures in this document. The exact protection 
of messages within the group is up to the security protocol used by an 
application profile of this document, and their protection does not 
necessarily rely on signatures.

For example, when considering exactly the application profile 
draft-ietf-ace-key-groupcomm-oscore and therefore the security protocol 
Group OSCORE: i) messages protected with the group mode are signed, and 
indeed the signature verification happens before decryption; ii) 
messages protected with the pairwise mode are not signed (although still 
providing source authentication through their tags).

The quoted text specifically talks about decryption. If a signature is 
included in the message, it should be verified first and (several) 
failed verifications are not a sufficient trigger to ask for the current 
group keying material (although they can be a trigger for asking for the 
current authentication credential of the sender group member). However, 
this is ultimately about the secure communication protocol defining in 
which order the different message processing steps occur, and it's not 
something we can really dictate in this document.

<==

>>
>> Section 11:
>>
>> The IANA section mentions the IESG as Change Controller, but it is 
>> prefered to use
>> IETF instead. (IANA will bug you about this later if not changed)

==>MT

Yes, let's use "IETF".

<==

>>
>> Under which collection/grouping should the a "ACE Groupcomm" 
>> registries appear ?
>> Under https://www.iana.org/assignments/ace/ace.xhtml 
>> <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Face%2Face.xhtml&data=05%7C01%7Cmarco.tiloca%40ri.se%7C90f845f51ae441a280f808dbaa821350%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638291247875827690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Vh6usMKEgwgUsG%2FxjgtT493TD7%2Fh3o9jI6ZKH0%2B2b6k%3D&reserved=0> 
>> or under a sub-registry ace-groupcomm ?
>> Either way, it should be clarified to IANA.

==>MT

Correct, the plan is to have all the new 7 registries added to the 
registry group "Authentication and Authorization for Constrained 
Environments (ACE)" at https://www.iana.org/assignments/ace/ace.xhtml

The proposal to fix this is also already compiled in 
https://github.com/ace-wg/ace-key-groupcomm/issues/149

<==

>>
>>         It should be noted that, in addition to the expert review, some
>>         portions of the registry require a specification, potentially
>>         a Standards Track RFC, to be supplied as well.
>>
>> Possibly rephrase as:
>>
>>         Values in this registry are covered by different registration 
>> policies as indicated

==>MT

We plan to add the suggested phrase to prepare the reader about the 
different ranges coming later on.

At the same time, the original text (also used in other document) covers 
a different point, which also comes back in following comments and 
related replies from our side.

<==

>>
>> Section 11.10 describes this as well, but it does indicate how/when 
>> different policies apply.
>> (likely based on the Value field?)
>>
>> Section 11.11 doesn't list the maximum/minimum values (or limiting 
>> size of the value)

==>MT

Correct; these IANA sections have different and inconsistent level of 
details about what they say.

The proposal to fix this is also already compiled in 
https://github.com/ace-wg/ace-key-groupcomm/issues/149 , and further 
elaborated in replies to comments below.

<==

>>
>> Section 11.13:
>>
>>         The IANA Registries established in this document are defined 
>> as expert review.
>>
>> It's a bit contentious whether a registry can be Standards Track PLUS 
>> Expert Review. To
>> avoid issues around this, I would remove this entire sentence.

==>MT

We are defining 7 new IANA registries.

* "ACE Groupcomm Parameters"
* "ACE Groupcomm Key Types"
* "ACE Groupcomm Profiles"
* "ACE Groupcomm Policies"
* "Sequence Number Synchronization Methods"
* "ACE Groupcomm Errors"
* "ACE Groupcomm Rekeying Schemes"

Considering also the clarifications in 
https://github.com/ace-wg/ace-key-groupcomm/issues/149 and depending on 
the specifically considered value range, each registry uses the policy:

* "Standards Action With Expert Review"; or
* "Specification Required"; or
* "Expert Review"

It is true that RFC 8126 does not define a single policy "Standards 
Action With Expert Review". However, its Section 4.12 says (emphasis mine):

 > In some situations, it is necessary to define multiple registration 
policies.
 > ...
 > Thus, a particular registry might want to use a policy such as "RFC 
Required" or "IETF Review" sometimes, with a designated expert checking 
a "Specification Required" policy at other times.
 > ...
 > Such combinations will commonly use one of {**Standards Action**, 
IETF Review, RFC Required} in combination with one of {Specification 
Required, **Expert Review**}.

Based on the above, we believe that the current text is appropriate and 
legitimate.

Also, as long as it is done appropriately, this is quite common 
practice; see, above all, selected value ranges of several COSE 
registries at https://www.iana.org/assignments/cose/cose.xhtml

<==

>>
>>
>>         Specifications are needed for the first-come, first-serve range
>>         if they are expected to be used outside of closed environments
>>         in an interoperable way.
>>
>> I think for all non-private use entries, this is "expected", so I 
>> would remove the part
>> starting at "if they are expected ....".

==>MT

This does not seem to be the case; see a longer reasoning in the 
response to the following comment.

In short, registrations with policy "First-Come-First-Serve" (or "Expert 
Review") do not necessarily need a specification (see Section 4.4 of RFC 
8126).

Given that baseline, in this document we have an additional expectation 
that we are raising, since it is otherwise not to be assumed.

Also, the quoted sentence is used in other RFCs, such as in 
https://datatracker.ietf.org/doc/html/rfc9203#section-9.7

<==

>>
>>         When specifications are not provided, the description provided
>>         needs to have sufficient information to identify what the point
>>         is being used for.
>>
>> That feels a little odd to me. Not sure this makes much sense, since 
>> even FSFC needs
>> a specification. Private use is well, private use. So which 
>> registration cases would
>> there be that can leave out a specification?

==>MT

Based on RFC 8126, the first registration policy requiring a 
specification is, in fact, "Specification Required" defined in 
https://www.rfc-editor.org/rfc/rfc8126.html#section-4.6.

Instead (emphasis mine):

* https://www.rfc-editor.org/rfc/rfc8126.html#section-4.4

    > For the **First Come First Served policy** ... There is no 
substantive review of the request, other than to ensure that it is 
well-formed and doesn't duplicate an existing assignment.  However, 
**requests must include a minimal amount of clerical information**, such 
as a point of contact (including an email address, and sometimes a 
postal address) and a brief description of how the value will be used.

* https://www.rfc-editor.org/rfc/rfc8126.html#section-4.5

    > For the **Expert Review policy**, review and approval by a 
designated expert (see Section 5) is required. While **this does not 
necessarily require formal documentation**, information needs to be 
provided with the request for the designated expert to evaluate. ... The 
required documentation and review criteria, giving clear guidance to the 
designated expert, should be provided when defining the registry.

In this document, we are defining also registries with "Expert Review" 
policy, so the quoted text in Section 11.13 should be correct.

Also, the quoted sentence is used in other RFCs, such as in 
https://datatracker.ietf.org/doc/html/rfc9203#section-9.7

<==

>>
>> NITS:
>>
>>   ** Downref: Normative reference to an Informational RFC: RFC 7967
>>   ** Downref: Normative reference to an Informational RFC: RFC 9053
>>
>> These downrefs are okay.

==>MT

Ok.

<==

>>
>>   == Outdated reference: A later version (-19) exists of
>>      draft-ietf-core-oscore-groupcomm-14
>>
>>   == Outdated reference: draft-ietf-cose-countersign has been 
>> published as
>>      RFC 9338
>>
>>   -- Possible downref: Normative reference to a draft: ref.
>>      'I-D.ietf-cose-countersign'
>>
>>   == Outdated reference: draft-ietf-ace-mqtt-tls-profile has been 
>> published
>>      as RFC 9431
>>
>>   == Outdated reference: A later version (-12) exists of
>>      draft-ietf-core-coap-pubsub-10
>>
>>   == Outdated reference: A later version (-09) exists of
>>      draft-ietf-core-groupcomm-bis-07
>>
>>   == Outdated reference: A later version (-06) exists of
>>      draft-ietf-cose-cbor-encoded-cert-04
>>
>>   == Outdated reference: A later version (-13) exists of
>>      draft-tiloca-core-oscore-discovery-11
>>
>> These need updating (because of my long time to do my AD review. 
>> Again my apologies)
>>

==>MT

Ok. (draft-ietf-cose-countersign has also been published as RFC 9338)

<==

>> typoes/grammer:
>>
>> for those that aim to  -> for those that aim for
>>
>> trasferring -> transfering
>>
>> consistently with the roles it has in the group -> consistent with 
>> the roles it has in the group.
>>
>> the handler reply with a -> the handler replies with a
>>
>> Due to different reasons - >  [remove entirely]
>>
>> ameliorate -> [pick a different more common term for this]
>>

==>MT

All to be fixed as proposed, except for the following ones:

* > trasferring -> transfering

    While "trasferring" is certainly a typo to fix, "transferring" is 
correct but "transfering" is wrong, both in American and British 
English. See:
    - https://whichiscorrect.com/transfering-or-transferring/
    - https://oneminuteenglish.org/en/transfering-or-transferring/

* > ameliorate -> [pick a different more common term for this]

    We can change it to: "A possible way to limit the impact of this 
issue ..."

<==

>> This sentence does not parse:
>>
>>         As long as both sides get the new group keying material, updating
>>         group the keying material in the middle of a transfer will not
>>         cause any issue.
>>

==>MT

It should read:

"As long as both sides get the new group keying material, updating the 
group keying material in the middle of a transfer will not cause any issue."

<==

>> retro-compatibility  -> backwards compatibility ?

==>MT

Yes, or actually "backward compatibility"

<==

>>
>>
>> Paul
>

==>MT

Thanks a lot again for this review!

<==

> -- 
> 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

-- 
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