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

[Paul Wouters <[e-mail]>]

Thanks for the feedback to my review. I'll await the publication of a new
draft version and then move the document further through the process.

Paul

On Fri, Sep 22, 2023 at 12:16 PM Marco Tiloca <[e-mail]> wrote:

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