Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-key-groupcomm-17: (with COMMENT)

[Marco Tiloca <[e-mail]>]

Hello Roman,

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 -18 of the document.

Thanks,
/Marco

[PR] https://github.com/ace-wg/ace-key-groupcomm/pull/161

On 2023-11-18 00:46, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-ace-key-groupcomm-17: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C5ff64a69992349e291ac08dbe7c7686f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638358615879941733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=C5pPlP9PcO9Y4%2F5EQfWSIH8%2BhSOcDCamoEL8vrSaHIE%3D&reserved=0  
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7C5ff64a69992349e291ac08dbe7c7686f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638358615879941733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nFjixy8p0Ljocl6G2VzbisJF%2FULDZ1y%2BcjABa3MAXQM%3D&reserved=0
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> ** Section 1.1.  Per the definition of “Group name” and GROUPNAME.  The latter
> is defined as a “text string used in a URIs”.  The former has no definition
> beyond saying it is an identifier.  Is it not a text string?

==>MT

Right, we have revised the definition of both group name and node name 
as below.

NEW
 > Group name: the identifier of a group, as a text string. Once 
established, it is invariant.

NEW
 > Node name: the identifier of a node, as a text string. Once 
established, it is invariant.

<==

>
> ** 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.
>
> -- unlike group and node identifier, member identifier is not defined
>
> -- how is a member identifier an example of “keying material”?  Is it an
> identifier for a key?

==>MT

We have clarified by expanding one sentence as follows.

OLD
 > For example, this can be a member identifier that is unique within 
the group.

NEW
 > For example, this can be an identifier that the secure communication 
protocol employs to uniquely identify a node as a group member (e.g., a 
cryptographic key identifier uniquely associated with the group member 
in question).

<==

>
> ** Section 2.  Per the comment “Defined in the ACE framework” in Figure 2,
> which framework is this text referencing?  This document?  RFC9200?

==>MT

Yes, we have added a reference to RFC 9200.

<==

>
> ** Section 3.1.  Editorial
>     *  'scope', specifying the name of the groups that the Client
>        requests to access,
>
> Should this be “name_s_ of the groups ...”?  Otherwise, it reads as if there is
> a single name for a collection of groups.

==>MT

Yes, now fixed.

<==

>
> ** Section 3.1
>
>     *  'audience', with an identifier of the KDC.
>
> The definition of audience from Section 5.8.1 of RFC9200 points to RFC8693
> (OAuth’s definition of audience).  It says:
>
> ==[ snip ]==
> The logical name of the target service where the client intends to use the
> requested security token. This serves a purpose similar to the resource
> parameter but with the client providing a logical name for the target service.
> Interpretation of the name requires that the value be something that both the
> client and the authorization server understand. ==[ snip ]==
>
> Does the application profile have to specify the semantics of this audience
> value (just like the scope parameter)?

==>MT

No; we are intentionally keeping this as open as in RFC 9200. 
Practically, we expect the audience to be an identifier of the KDC.

<==

>
> ** Section 5.
>     2.  The node has been found compromised or is suspected so.
>
> What triggers this behavior in #2?  How does the KDC know about compromise?
> Can Clients tell it that?  Can a Client evict another Client?

==>MT

We have extended the quoted bullet point as follows.

NEW
 > 2.  The node has been found compromised or is suspected so. The KDC 
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). Additional mechanics, protocols, and 
interfaces at the KDC that can support this are out of the scope of this 
document.

<==

>
> ** Section 6.2.1.  Reading this text as normative guidance seemed odd since the
> parent section 6.2 stated that the specifics of one-to-many is effectively out
> of scope and this document only provides high level guidance.

==>MT

We have rephrased as below, to emphasize upfront that the section only 
describes one possible method. In the text after that, we think that it 
is appropriate to use normative language to describe how this particular 
method has to work if the KDC uses it.

OLD
 > Then, the KDC can protect the rekeying message as defined below. The 
used encryption algorithm which SHOULD be the same one used to protect 
communications in the group. The method defined below assumes that the 
following holds for the management keying material specified in the 
'mgt_key_material' parameter of the Join Response (see Section 4.3.1).
 >
 > * The included symmetric encryption keys are accompanied by a 
corresponding and unique key identifier assigned by the KDC.
 > * ...

NEW
 > The following describes one possible method for the KDC to protect 
the rekeying messages.
 >
 > The method assumes that the following holds for the management keying 
material specified in the 'mgt_key_material' parameter of the Join 
Response (see Section 4.3.1).
 >
 > * The encryption algorithm SHOULD be the same one used to protect 
communications in the group.
 > * The included symmetric encryption keys are accompanied by a 
corresponding and unique key identifier assigned by the KDC.
 > * ...

<==

>
> ** Section  10.
>     Security considerations are inherited from the ACE framework
>     [RFC9200], and from the specific transport profile of ACE used
>     between the Clients and the KDC, e.g., [RFC9202] and [RFC9203].
>
> And from application profiles too which specify the details of the keys and
> tokens?

==>MT

No, that would be a circular dependency and would require to know such 
application profiles in advance. (After all, the security considerations 
of RFC 9200 do not inherit those from its transport profiles, such as 
RFC 9202 and RFC 9203).

<==

>
> ** Section 10
>
>     Unless otherwise defined by an application profile of this
>     specification, the KDC SHOULD renew the group keying material upon a
>     group membership change.
>
> ...
>
>     Instead, the KDC might
>     rekey the group after a minimum number of group members have joined
>     or left within a given time interval, or after a maximum amount of
>     time since the last group rekeying was completed, or yet during
>     predictable network inactivity periods.
>
> The first sentence seems to be encouraging rekeying but subsequent text points
> out that this might not be reasonable.  Should the initial “SHOULD” text be
> harmonized with this other more nuanced guidance?

==>MT

We have rephrased as below, by mentioning exceptions upfront when using 
"SHOULD".

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

NEW
 > Unless otherwise defined by an application profile of this 
specification, the KDC SHOULD renew the group keying material upon a 
group membership change. As a possible exception, the KDC may not rekey 
the group upon the joining of a new group member, if the application 
does not require backward security. As another possible exception 
discussed more in detail later in this section, the KDC may rely on a 
rekeying policy that reasonably take into account the expected rate of 
group membership changes and the duration of a group rekeying.
 >
 > Since the minimum ...

<==

>
> ** Typos
> -- Section 1.  Typo. s/recommeded/recommended/
> -- Section 2.  Typo. s/membrs/members/
> -- Section 3.1. Typo. s/ specificaton/specification/
> -- Section 3.3.1.  Typo. s/acces/access/
> -- Section 4.  Typo. s/trasferring/transferring/

==>MT

Already fixed in https://github.com/ace-wg/ace-key-groupcomm/pull/156

<==

>
>
>

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