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 <marco.til...@ri.se> 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 paul.wout...@aiven.io. 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: +46 (0)70 60 46 501 > > RISE Research Institutes of Sweden AB > Box 1263 > 164 29 Kista (Sweden) > > Division: Digital Systems > Department: Computer Science > Unit: Cybersecurity > https://www.ri.se > > > -- > Marco Tiloca > Ph.D., Senior Researcher > > Phone: +46 (0)70 60 46 501 > > RISE Research Institutes of Sweden AB > Box 1263 > 164 29 Kista (Sweden) > > Division: Digital Systems > Department: Computer Science > Unit: Cybersecurity > https://www.ri.se > >
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
