|
Hello Joerg,
Thanks a lot for your review! Please find in line below our detailed replies to your comments.
A Github PR where we have addressed your comments is available at [PR].
Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews) and to submit the result as version -27 of the document.
Thanks,
/Marco
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
From: Joerg Ott via Datatracker <noreply@xxxxxxxx>
Sent: Sunday, July 27, 2025 10:04 PM To: tsv-art@xxxxxxxx <tsv-art@xxxxxxxx> Cc: core@xxxxxxxx <core@xxxxxxxx>; draft-ietf-core-oscore-groupcomm.all@xxxxxxxx <draft-ietf-core-oscore-groupcomm.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> Subject: draft-ietf-core-oscore-groupcomm-26 ietf last call Tsvart review Document: draft-ietf-core-oscore-groupcomm
Title: Group Object Security for Constrained RESTful Environments (Group OSCORE) Reviewer: Joerg Ott Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. Let me note up front that, for this tsv-art review, I am not able to read all accompanying documentation to understand all subtleties and mechanisms that may be provided elsewhere or obvious to those deep into OSCORE. The present I-D defines additions to security contexts in an OSCORE environment for the purpose of enabling secure multicast-based group communication paired with point-to-point messaging between group members. As such, the document mostly defines security mechanisms and only touches transport aspects in a few places. This tsv-art review naturally focuses on the latter. Section 8.1, 2nd para "Typically, the sender endpoint sends the message protected in pairwise mode over unicast [...]." This may be read to suggest that such requests could also be sent via multicast, which may not (or may?) be desirable. The two remaining paragraphs in section 8.1 don't help resolving this issue (actually, to me, they seem to create more questions than they answer). ==>MT
Indeed, the quoted sentence intentionally suggests that a message protected with the pairwise mode may be sent over multicast in order to reach multiple servers.
In fact, this was anticipated in the last two paragraphs of the earlier Section 8.0:
> The pairwise mode cannot be used to protect messages intended for multiple recipients, as the keying material used for the pairwise mode is shared only between two endpoints.
>
> However, a sender can use the pairwise mode to protect a message sent to (but not intended for) multiple recipients, if interested in a response from only one of them. For instance, this is useful to support the address discovery service defined in Section
8.1, when a single 'kid' value is indicated in the payload of a request sent to multiple recipients, e.g., over multicast.
As to the mentioned "address discovery service", its principles are further discussed in the last paragraph of Section 8.1, while its details are intentionally left out of scope.
<==
Section 12.1: "Communications that the Group Manager has with joining endpoints MUST be secured. Specific details on how to secure such communications are out of the scope of this document." Should one have the (normative?) reference to ietf-ace-key-groupcomm-oscore earlier and more explicit? ==>MT
Thank you for the comment, we have moved the text about draft-ietf-ace-key-groupcomm-oscore to have that reference earlier, i.e., in Section 12.0 "The Group Manager".
We believe that it is appropriate to have the reference to draft-ietf-ace-key-groupcomm-oscore as informative, since that document specifies just a possible realization of the Group Manager and different ones might be specified in the future.
<==
Section 12.2, 2nd para states that "when possible, the delivery of rekeying messages should use a reliable transport [...]" This seems to suggest that an unreliable -- and possibly non-congestion controlled -- transport is fine, too. This appears risky if rapid membership changes occur or are suggested in some way as this could cause floods of rekeying messages. Especially since (4th para), "The Group Manager MUST rekey the group without undue delay when one or more endpoints leave the group." ==>MT
It is indeed suggested that both reliable and unreliable transports can be used, with a preference for the former ones where both are usable to deliver a rekeying message for a given group rekeying scheme.
That said, using an unreliable transport is **not** an excuse to avoid the enforcement of congestion control. In fact, we do assume that unreliable transports available to use also come with corresponding mechanisms and considerations about congestion control
to adopt. Complying with constraints due to congestion control is certainly **not** an "undue delay" for the Group Manager.
In Section 12.2 "Management of Group Keying Material", we have extended the second paragraph as below (emphasis mine):
> When possible, the delivery of rekeying messages should use a reliable transport, in order to reduce chances of group members missing a rekeying instance. **The use of an unreliable transport MUST NOT forego enforcing congestion control as appropriate for
that transport.**
<==
Since member may be evicted is they are suspicious, could such suspicion be caused by an adversary and thereby mount a flooding or denial of service attack? ==>MT
The short answer is "no". The suspicion cannot be "caused by an adversary".
The Group Manager is expected to determine that a group member has to be evicted either through its own means or based on information that it obtains from a trusted source (e.g., an Intrusion Detection System or an issuer of authentication credentials).
In Section 12.2 "Management of Group Keying Material", we have extended the fourth paragraph as below (emphasis mine):
> An endpoint may leave the group at own initiative, or may be evicted from the group by the Group Manager, e.g., in case the endpoint is compromised, or is suspected to be compromised **(as determined by the Group Manager through its own means or based on
information that it obtains from a trusted source such as an Intrusion Detection System or an issuer of authentication credentials)**. In either case, ...
<==
Let me finally not that the group manager is defined as an abstract concept, well, a function, to exercised by some entity inside or outside the group. This is a good abstraction but I am wondering where rendezvous mechanisms, which may or may not have transport and security implications, are defined. Would the group manager be (auto)configured? ==>MT
Rendez-vous mechanisms and Group Manager configuration are very much out of the scope of this document.
Just for information, there is ongoing work related to both aspects, with particular reference to the realization of a Group Manager specified in draft-ietf-ace-key-groupcomm-oscore:
* As to the rendez-vous with the Group Manager, the document draft-tiloca-core-oscore-discovery describes a method to discover OSCORE groups and the responsible Group Managers. Then the document draft-ietf-ace-key-groupcomm-oscore describes actual interactions
with the Group Manager for (candidate) group members, e.g., to join the group.
* As to configuring the Group Manager, it can certainly be auto-configured or rely on a hardcoded configuration. Alternatively, the document draft-ietf-ace-oscore-gm-admin specifies a REST administrative interface at the Group Manager, which an authorized administrator
can use to create, (re-configure), and delete OSCORE groups.
None of the concrete items above is _the_ method to necessarily use.
We believe that these aspects are very much out of the scope of this document, hence we have not even included references to draft-tiloca-core-oscore-discovery and draft-ietf-ace-oscore-gm-admin.
<==
The group manager also appears
as a single point of failure and neither this document not the referenced draft-ietf-ace-key-groupcomm-oscore-17 appears to discuss such aspects. Here, I may just miss the overarching context but it might appear useful to include some minimalist material to this end. As I wrote above, this may all be discussed or handled elsewhere. ==>MT
Conceptually, the Group Manager is a single entity. However, this does not mean that the Group Manager has to practically be realized as a single, physically-centralized entity such as a single host running a single process.
We do not want to go into details on how it is implemented, the same way that OAuth (RFC 6749) or ACE (RFC 9200) do not specify it for the authorization server.
<==
Nits: Section 12. intro: "According to a hierarchical approach, ..." -- reword? ==>MT
Since "According to a hierarchical approach" is not really necessary and can be confusing, we have removed those words and kept the rest of the sentence as-is, i.e.:
> The Gid value assigned to a group is associated with a dedicated space for the values of Sender ID and Recipient ID of the members of that group.
<==
Section 12.2. 1st para: should -> SHOULD ? ==>MT
Good point. We have updated the text to use "SHOULD", also providing a rationale for possible exceptions that can apply.
OLD
> When establishing the new Security Context, the Group Manager should preserve the current value of the Sender ID of each group member.
NEW (emphasis mine)
> When establishing the new Security Context, the Group Manager **SHOULD** preserve the current value of the Sender ID of each group member **in order to ensure an efficient key rollover. Exceptions can apply if there are compelling reasons for making available
again some of the Sender ID values currently used.**
<==
Best, Jörg |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
