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

[Paul Wouters <[e-mail]>]

I still do not see a -17 version? Could you push it out?

Paul

On Fri, Sep 29, 2023 at 12:49 PM Paul Wouters <[e-mail]> wrote:

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