Re: [core] I-D Action: draft-ietf-core-groupcomm-bis-09.txt

[Esko Dijk <[e-mail]>]

Hello John,



Many thanks for your detailed review. We’ve taken the comments and updated the text; below a point-by-point response.

The total results are in a Github PR here: https://github.com/core-wg/groupcomm-bis/pull/39/files . This will be merged very soon (weekend/Monday) so that we can submit the update on Monday, before the cut-off!




> Abstract says, "replaces RFC 7390". Replaces is not a formal IETF term, maybe change to obsoletes or "replaces and obsoletes" as in the introduction.

  *   Changed to "This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641."





> Figure 1 and Section 2.2.1.1 seems to be saying different things. 2.2.1.1 states that host subcomponent is mandatory and that IP multicast address and UDP port number are optional. Figure 1 states that IP multicast address and UDP port number are mandatory.

  *   This needs to be clarified indeed. The intention is as follows:



* Section 2.1.1 defines the CoAP group and its associated attributes of IP multicast address and UDP port number, which are always there as attributes. (No optionality.)

* Figure 1 represents this definition of the CoAP group, with the 2 mandatory attributes.

* Section 2.2.1.1 defines how CoAP groups are named; and the rules for the name are different. It uses the URI for the name. In the name, the actual IP multicast address may be optionally present.

  (It is not present if the URI uses a hostname instead of an IP literal. The IP multicast group can be derived only by resolving the hostname.)

  Also, the actual UDP port number may not be present. (If not present then the default 5683 is assumed.)



What would be the best way to make this clear? One option is to update 2.2.1.1 as follows, which we’ve done in the new version:



    A CoAP group is always defined by the two properties of IP multicast address and UDP port number (see Section 2.1.1).

    However, a CoAP group is for practical purposes identified and named by the authority component in the group URI. This component includes the host subcomponent and an optional UDP port number.

    The host subcomponent directly defines the IP multicast address of the CoAP group, in case the host consists of an IP literal.

    The host subcomponent indirectly defines the IP multicast address of the CoAP group, in case the host consists of a hostname: resolving the hostname to

    an IP address in this case produces the IP multicast address.



    It follows that the same CoAP group might have multiple names, which can be simultaneously and interchangeably used. For example, if the two hostnames group1.com and group1.alias.com both resolve

to the IP multicast address [ff15::1234], then the following authority components are all names for the same CoAP group.





> group1.com and alias.com are real domain names in use and not suitable for examples. I think you should use one of the example domains example.com, example.net, example.org, xample.edu, or .example

  *   We now consistently used .example for the hostnames used in the examples.





> ”However, using such experimental protocol is not a recommended approach.”

I don’t think something is not recommended just because it is an experimental RFC. What would the alternative be? To use something proprietary that is not even documented publicly.

  *   We've discussed this at the last CoRE interim and the consensus was that the experiment with the RFC 7390 protocol has been concluded. (As far as we know, it was not implemented/used.) It could still be used as is or as basis of a new, normative protocol.

To reflect this the text is now changed to:



[RFC7390] defined an experimental protocol for configuring memberships of CoAP groups for unsecured group communication, based on JSON-formatted configuration resources, and the experiment is concluded.





> “It has to be separately enforced by leveraging the resource properties or through dedicated access control credentials assessed by separate means.” feels a bit strong. For a very simple system with a single resource, I think it is ok to use group membership. “It should be separately enforced” is probably better.

  *   Rephrase as:



Therefore, access control to use resources in the application group should be separately enforced by leveraging the resource properties or through dedicated access control credentials assessed by separate means.





> "GROUPNAME" does not seem like a good name for the application group name as you define three types of groups with all might have “names". I suggest changing to APPNAME or something. In general, it might be good to use the work “group” less and the terms “CoAP group”, “multicast group”, “application group”, and “security group” more.

  *   In Section 2.2.1.2, we have replaced "GROUPNAME" with "APPNAME".

Throughout the document, we have ensured that "group" is always preceded by "CoAP", "application", or "security", or "OSCORE", unless: i) the group type has already been clarified earlier in the same sentence; or ii) what the sentence says refers to all the three types of group; or iii) is part of a combination of words, e.g., "group communication".





> The beginning “A security group is identified by a stable and invariant string used as a group name”.
How to identity the group in the management system is probably best left for implementation, or do you mean something Group OSCORE specific here? Is having a group name mandatory in general? Maybe I want to use an integer?

  *   Similarly to what we say in Section 2.2.1.2 for the application groups, we have rephrased as follows:



A security group can be named in many ways through different types of identifiers, such as name string, (integer) number, URI, or other types of strings. Such a group name is generally not related to other kinds of group identifiers that may be specific of the used security solution.





> The figures in Appendix D would look a lot nicer with aasvg.

  *   Agree, done.





> “For example, early discovery of devices and resources is a typical use case where the NoSec mode is relevant” seems like something people say to move the hard problem of secure credential management somewhere out of scope. Is there any _concrete_ examples of any secure actual deployments where this message flow makes sense? Otherwise, I think this part should be removed.



  *   We've updated the language in this section to make the example of early discovery concrete - with reference to the cBRSKI protocol. NEW:



For example, early link-local discovery of devices and resources as part of an onboarding protocol is a typical use case where the NoSec mode or equivalent unsecured mode is used. In such a discovery step, there may be a querying device that needs to discover nearby devices capable of helping it with the network onboarding process. But there are no mutual security relations configured on the querying device and its neighbor devices at the time it performs the early discovery. These relations are configured later in the process based on secure device identities. Alternatively, a new device to be onboarded may wait for advertisements of nearby devices able to help it do the network onboarding process. Also in this case, these messages cannot be secured initially because the new device does not yet have any security relation configured with devices that are already a member of the network. See {{I-D.ietf-anima-constrained-voucher}} for an example of an onboarding protocol that can use CoAP multicast for early link-local discovery.





> ”For sensitive and mission-critical applications”. I think the current IETF view should be at least ”Unless proven to be not sensitive”. Zero trust mandates encryption everywhere without exceptions and modern protocols like QUIC delivers that.



  *   We have rephrased in the suggested way. So that security is required by default, and NoSec mode MUST NOT be used, with the exception phrased like:

“some applications may rely on a limited use of the NoSec mode, when performing specific, well-defined steps that are proven to not require security or to not be able to attain it.”

See the draft’s version-diff for detailed changes.





> ”Group policies should”

”That is, it may”

Should these be capital MAY and SHOULD? Agree that rekeying policies is best left for the applications. Section 6.2.1 should mention that the security requirements can vary between applications and also depending on ”who” is joining or leaving the group.



  *   On the first quoted sentence, we have rephrased that paragraph as follows.



OLD

> Group policies should also take into account the time that the key management scheme requires to rekey the group, on one hand, and the expected frequency of group membership changes, i.e., nodes joining and leaving, on the other hand.



NEW

> Even though group policies vary depending on the specific applications and their security requirements, they SHOULD also take into account:

>

> * The expected amount of time that the key management scheme requires to rekey the group.

> * The expected frequency of group membership changes (i.e., nodes joining and leaving).

> * The identity of the specific CoAP endpoints as they join and leave the OSCORE group.



On the second quoted sentence, "... it MAY be desirable" does not seem to be a correct use of requirement language. To avoid ambiguity, we have replaced the two occurrences of "may" in the present Section 6.2.1 with "can".





> ”source authentication”

“SHOULD NOT accept group requests that can not be authenticated in some way”

“is indeed reachable at the claimed source address”

I think it would be good to explain better to the reader that there are two difference “source”. Group OSCORE does not give any guarantees about the source address, and ECHO does not give source authentication.

  *   We have clarified through the following changes.



* Section 5.1

   OLD

   > Group OSCORE ensures source authentication of all messages exchanged within the OSCORE group, by means of two possible methods.



   NEW

   > Group OSCORE ensures source authentication of all messages exchanged within the OSCORE group. That is, the recipient of a CoAP message protected with Group OSCORE is able to securely verify whether the CoAP endpoint that has generated and sent the message is indeed the alleged one. This is achieved by means of two possible methods.



* Section 6.2.2

   OLD

   > Thus, both modes allow a recipient CoAP endpoint to verify that a message has actually been originated by a specific and identified member of the OSCORE group.



   NEW

   > Thus, both modes allow a recipient CoAP endpoint to verify that a message has actually been originated and sent by a specific and identified CoAP endpoint as a member of the OSCORE group.

   >

   > Note that Group OSCORE does not protect the addressing information about the CoAP endpoint that has sent the message, e.g., the source IP address and port number used when sending the message. Therefore, Group OSCORE does not provide authentication of such source addressing information.



* Section 6.2.3

   OLD

   > That is, upon receiving a group request protected with Group OSCORE, a server verifies whether the request is not a replay, and whether it originates from the alleged sender in the OSCORE group.



   NEW

   > That is, upon receiving a group request protected with Group OSCORE, a server verifies whether the request is not a replay, and whether it has been originated and sent by the alleged CoAP endpoint in the OSCORE group.



* Section 6.2.3

   OLD

   > In fact, requests and corresponding responses sent in the OSCORE group can be correctly generated only by legitimate members of the group.



   NEW

   > In fact, requests and corresponding responses sent in the OSCORE group can be correctly generated only by CoAP endpoints that are legitimate members of the group.



* Section 6.2.3

   OLD

   > Thus, recipient endpoints can verify a message to be originated by the alleged, identifiable sender in the OSCORE group.



   NEW

   > Thus, recipient endpoints can verify a message to have been originated and sent by the alleged, identifiable CoAP endpoint in the OSCORE group.



* Section 6.2.3



   OLD

   > In fact, source authentication is always ensured for exchanged CoAP messages, as verifiable to be originated by the alleged, identifiable sender in the OSCORE group.



   NEW

   > In fact, source authentication is always ensured for exchanged CoAP messages, as verifiable to have been originated and sent by the alleged, identifiable CoAP endpoint in the OSCORE group.



* Section 6.3



   OLD

   > SHOULD NOT accept group requests that cannot be authenticated in some way;



   NEW

   > SHOULD NOT accept group requests that cannot be authenticated in some way, i.e., for which it is not possible to securely assert that they have been originated and sent by the alleged, identifiable CoAP endpoint in the OSCORE group;



* Section 6.2.3



   OLD

   > By doing so, the server can assert that the alleged sender of the group request (i.e., the CoAP client associated with a certain authentication credential including the corresponding public key) is indeed reachable at the claimed source address, especially if this differs from the one used in previous group requests from the same (authenticated) device. Although responses including the Echo Option do still result in amplification, this is limited in volume compared to when all servers reply with a full response.



   NEW

   > By doing so, the server can assert that the alleged sender of the group request (i.e., the CoAP client associated with a certain authentication credential including the corresponding public key) is indeed reachable at the claimed source address of the group request, especially if such an address differs from the one used in previous group requests from the same (authenticated) device. Although responses including the Echo Option do still result in amplification, this is limited in volume compared to when all servers reply with a full response.

   >

   > Using the Echo Option does not provide authentication of source addressing information about the sender of a CoAP message. Also, using the Echo Option in itself does not provide source authentication of exchanged messages, which is achieved by means of Group OSCORE (see Section 6.2.2). Using the Echo Option together with Group OSCORE allows a CoAP server in the OSCORE group to assert the freshness of CoAP requests received from other members in the group.





> I think it should be stated that NoSec servers MUST NOT be accessible through the public Internet due to amplification attacks. A group of multicast servers may otherwise be accessible via a gateway from the Internet.



  *   Agreed. In Section 4 we've added:



    A CoAP server in NoSec mode MUST NOT be accessible through the public Internet.



In Section 6.1 we've added:



    The requirement in Section 4 on publicly accessible CoAP servers also aims to prevent amplification attacks.





> Editorial

  …



  *   We have made those and more editorial fixes throughout the document.



Best regards,

Esko / co-authors





From: core <[e-mail]> On Behalf Of John Mattsson
Sent: Tuesday, September 19, 2023 10:44
To: [e-mail]
Subject: [core] I-D Action: draft-ietf-core-groupcomm-bis-09.txt



Review of draft-ietf-core-groupcomm-bis-09



Hi,



Below is my review of draft-ietf-core-groupcomm-bis-09. The document seems “ready with issues”.



  *   Abstract says, "replaces RFC 7390". Replaces is not a formal IETF term, maybe change to obsoletes or "replaces and obsoletes" as in the introduction.



  *   Figure 1 and Section 2.2.1.1 seems to be saying different things.

2.2.1.1 states that host subcomponent is mandatory and that IP multicast address and UDP port number are optional. Figure 1 states that IP multicast address and UDP port number are mandatory.



  *   group1.com and alias.com are real domain names in use and not suitable for examples. I think you should use one of the example domains example.com, example.net, example.org, xample.edu, or .example



  *   ”However, using such experimental protocol is not a recommended approach.”

I don’t think something is not recommended just because it is an experimental RFC. What would the alternative be? To use something proprietary that is not even documented publicly.



  *   “It has to be separately enforced by leveraging the resource properties or through dedicated access control credentials assessed by separate means.” feels a bit strong. For a very simple system with a single resource, I think it is ok to use group membership. “It should be separately enforced” is probably better.



  *   "GROUPNAME" does not seem like a good name for the application group name as you define three types of groups with all might have “names". I suggest changing to APPNAME or something. In general, it might be good to use the work “group” less and the terms “CoAP group”, “multicast group”, “application group”, and “security group” more.



  *   The beginning “A security group is identified by a stable and invariant string used as a group name”.
How to identity the group in the management system is probably best left for implementation, or do you mean something Group OSCORE specific here? Is having a group name mandatory in general? Maybe I want to use an integer?



  *   The figures in Appendix D would look a lot nicer with aasvg.



  *   “For example, early discovery of devices and resources is a typical use case where the NoSec mode is relevant” seems like something people say to move the hard problem of secure credential management somewhere out of scope. Is there any _concrete_ examples of any secure actual deployments where this message flow makes sense? Otherwise, I think this part should be removed.



  *   ”For sensitive and mission-critical applications”. I think the current IETF view should be at least ”Unless proven to be not sensitive”. Zero trust mandates encryption everywhere without exceptions and modern protocols like QUIC delivers that.



  *   ”Group policies should”

”That is, it may”

Should these be capital MAY and SHOULD? Agree that rekeying policies is best left for the applications. Section 6.2.1 should mention that the security requirements can vary between applications and also depending on ”who” is joining or leaving the group.



  *   ”source authentication”

“SHOULD NOT accept group requests that can not be authenticated in some way”

“is indeed reachable at the claimed source address”

I think it would be good to explain better to the reader that there are two difference “source”. Group OSCORE does not give any guarantees about the source address, and ECHO does not give source authentication.



  *   I think it should be stated that NoSec servers MUST NOT be accessible through the public Internet due to amplification attacks. A group of multicast servers may otherwise be accessible via a gateway from the Internet.



Editorial

----------------



  *   Several abbreviations like UML, HVAC should be spelled out.



  *   "TCP, TLS and WebSockets"

            "named, created, discovered and maintained"

            "manages, renews and provides "

            "specific, narrow and well"

            "GET, FETCH or POST"

            ... and more



IETF uses the Oxford comma.



  *   OLD "commmunication"

            NEW "communication"



  *   OLD "Different types of group"

            NEW "Different types of groups"



  *   OLD "can not"

            NEW "cannot"



  *   OLD "amplication"

            NEW "amplification"



  *   OLD "interecting"

            NEW "interacting"



  *   OLD "i.e,"

            NEW "i.e.,"



  *   OLD "e.g,"

            NEW "e.g.,"



Cheers,

John