Hi Brian,
please see inline. Hi Valery, One reply is inline. On Oct 22, 2025, at 11:54 AM, Valery Smyslov <[email protected]> wrote: Hi Brian, please find my comments inline. Hi Madison, On Oct 21, 2025, at 2:30 PM, Madison Church <[email protected] editor.org> wrote: Hi Brian, Valery, and *Deb, *Deb - Please review and approve the added text to Section 1.2 (Group SA definition). This change may be viewed here: https://www.rfc- editor.org/authors/rfc9838-lastdiff.html. Brian and Valery - Thank you both for your detailed replies! We have incorporated the requested updates. See below for a few (final) proposed changes. Aside from the following, we believe there are no remaining inquiries that are outstanding. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to asking IANA to make their updates. Whew! The changes all look fine to me, thanks. I’ve added some replies your questions below, which should be addressed before approval. We spotted 4 additional instances of "GSA policy" and 2 additional instances of "GSA attributes" that were not included in the list of updates. Should these instances be updated to "group SA policy" and "group SA attributes" as well? Or should they remain as is? Oh, this is my fault, I somehow missed them :-( Section 4.4.1 1) Current: Depending on the employed security protocol, GSA policies may further be classified as Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) SA policy. Perhaps: Depending on the employed security protocol, group SA policies may further be classified as Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) SA policy. I believe that “GSA policies” is referring to “Group Policies” in Figure 14, so I would suggest the following. Perhaps 2: Depending on the employed security protocol, Group Policies may further be classified as Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) SA policy. No, this text clarifies the types of SAs that can be considered as "group SAs" and for which group SA policy can be provided. Thus, I think that Madison's proposal is correct. Along with the two preceding sentences the text is: Group policies are comprised of two types: group SA policy and group- wide (GW) policy. Group SA policy defines parameters for the Security Association of the group. Depending on the employed security protocol, group SA policies may further be classified as Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) SA policy. which gives all the context. Ok, that’s fine. But now I think that there’s a typo in this sentence, which is what tripped me up. The previous sentence refers to a plurality of security policies, and so should this one. Note the change below from “security protocol” to “security protocols”. Perhaps 3: Depending on the employed security protocols, Group Policies may further be classified as Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) SA policy. I have no problem with this change, but the text above still talks about "Group Policy" and not about "group SA policy". I believe this is a typo (since you agreed with my previous message). We classify Group Policies as "group SA policies" and "group-wide policy" above and then further classify the former as "Rekey SA policy" and "Data-Security SA policy". Thus, I think the text should be: Perhaps 4. Depending on the employed security protocols, group SA policies may further be classified as Rekey SA (GSA KEK) policies and Data-Security (GSA TEK) SA policies. (note, that I used plural form everywhere). Or instead: Perhaps 5. Depending on the employed security protocol, a group SA policy may be either a Rekey SA (GSA KEK) policy or a Data-Security (GSA TEK) SA policy. (Note that I used singular form everywhere and an "a" article to show that there may be two types of group SA policies). Which variant is better in your opinion? Of do you have a better one in mind? As for me, I slightly prefer the last variant. Regards, Valery. Thanks, Brian 2) Current (2 instances): The format of the substructures is defined in Section 4.4.2 (for GSA policy) and in Section 4.4.3 (for GW policy). The first octet of the substructure unambiguously determines its type; it is zero for GW policy and non-zero (actually, it contains a Security Protocol Identifier) for GSA policies. Perhaps: The format of the substructures is defined in Section 4.4.2 (for group SA policy) and in Section 4.4.3 (for GW policy). The first octet of the substructure unambiguously determines its type; it is zero for GW policy and non-zero (actually, it contains a Security Protocol Identifier) for group SA policies. I believe this is a correct change. I agree. Section 4.4.2 1) Current: Section 4.4.2.2 defines attributes used in GSA policy substructure. Perhaps: Section 4.4.2.2 defines attributes used in group SA policy substructure. The update seems correct. However, I would not object to also adding “the” before “group SA", which was missing in the original text i.e., Perhaps 2: … “used in the group SA …" I agree. Section 4.4.2.2 1) Current: Unlike security parameters distributed via transforms, which are expected not to change over time (unless the policy changes), the parameters distributed via GSA attributes may depend on the time the provision takes place, on the existence of others group SAs, or on other conditions. Perhaps: Unlike security parameters distributed via transforms, which are expected not to change over time (unless the policy changes), the parameters distributed via group SA attributes may depend on the time the provision takes place, on the existence of others group SAs, or on other conditions. This also seems correct. However, I think there’s a slight typo in the last line of the original text (“other” should not be plural). Perhaps 2: … existence of other group SAs ... Yes. 2) Current: This document creates a new IKEv2 IANA registry for the types of GSA attributes, which has been initially populated as described in Section 9. Perhaps: This document creates a new IKEv2 IANA registry for the types of group SA attributes, which has been initially populated as described in Section 9. This seems correct to me. Exactly. Thank you! Regards, Valery. P.S. I seem to realize how I missed these 6 cases - I simply searched the draft text for "GSA policy", "GSA attribute" and forgot that there may be plural form "policies" and the searched text may be also split by line break. Alas. Many thanks! Brian The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9838.txt https://www.rfc-editor.org/authors/rfc9838.pdf https://www.rfc-editor.org/authors/rfc9838.html https://www.rfc-editor.org/authors/rfc9838.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9838-diff.html (comprehensive changes) https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9838-auth48diff.html (all AUTH48 changes) https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9838-lastdiff.html (diff showing latest updates) https://www.rfc-editor.org/authors/rfc9838-lastrfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9838 Thank you! Madison Church RFC Production Center On Oct 21, 2025, at 1:44 AM, Valery Smyslov <[email protected]> wrote: Hi Brian, Hi Valery, These changes look fine to me, if everyone agrees that making this much change is acceptable. Certainly they clean up inconsistence regarding “GSA”. However, it strikes me that the document is now so populated with the term “group SA”, so it should probably be defined in Section 1.2. Possibly: NEW Group SA: A Data-Security SA or Rekey SA that is shared as part of Group policy. Good idea! I think it should be inserted between the "Rekey SA" definition and the "Group Security Association (GSA)" definition. And I also think that "Group policy" should be "group policy" to be consistent with other uses of this words. Thus (a detailed change request for Madison): OLD: Rekey SA: A single multicast SA between the GCKS and all of the GMs. This SA is used for multicast transmission of key management messages from the GCKS to all GMs. Group Security Association (GSA): A collection of Data-Security SAs and Rekey SAs necessary for a GM to receive key updates. A GSA describes the working policy for a group. Refer to the MSEC Group Key Management Architecture [RFC4046] for additional information. NEW: Rekey SA: A single multicast SA between the GCKS and all of the GMs. This SA is used for multicast transmission of key management messages from the GCKS to all GMs. Group SA: A Data-Security SA or Rekey SA that is shared as part of group policy. Group Security Association (GSA): A collection of Data-Security SAs and Rekey SAs necessary for a GM to receive key updates. A GSA describes the working policy for a group. Refer to the MSEC Group Key Management Architecture [RFC4046] for additional information. Regards, Valery. Hope that helps, Brian On Oct 17, 2025, at 12:43 AM, Valery Smyslov <[email protected]> wrote: Hi Deb, Brian, Madison, taking into consideration Deb’s opinion, I think that for the purpose of making the abbreviations unambiguous, the simplest change would be to just replace “GSA” with “group SA” for “GSA policy” (14 instances), “GSA transforms” (3 instances) and “GSA attributes” (10 instances), with no change to “GSA payload” as Brian rightly noticed that this is a correct term. I checked the draft and here the concrete instances to change I found: For "GSA Policy": 1) Section 4.4.1. (2 instances) CURRENT: Group policies are comprised of two types: GSA policy and GW policy. GSA policy defines parameters for the Security Association of the group. NEW: Group policies are comprised of two types: group SA policy and group- wide (GW) policy. Group SA policy defines parameters for the Security Association of the group. 2) Section 4.4.2. (4 instances) CURRENT: The GSA policy substructure contains parameters for a single SA that is used with this group. [...] Figure 15: GSA Policy Substructure Format [...] The GSA policy fields are defined as follows: [...] Section 4.4.2.1 describes using IKEv2 transforms in GSA policy substructure. NEW: The group SA policy substructure contains parameters for a single SA that is used with this group. [...] Figure 15: Group SA Policy Substructure Format [...] The group SA policy fields are defined as follows: [...] Section 4.4.2.1 describes using IKEv2 transforms in the group SA policy substructure. 3) Section 4.4.2.1. (3 instances) CURRENT: GSA policy is defined by the means of transforms in the GSA policy substructure. [...] Exactly one instance of each mandatory Transform Type and at most one instance of each optional Transform Type MUST be present in the GSA policy substructure. NEW: Group SA policy is defined by the means of transforms in the group SA policy substructure. [...] Exactly one instance of each mandatory Transform Type and at most one instance of each optional Transform Type MUST be present in the group SA policy substructure. 4) Section 4.4.2.2. (1 instance), see also 11) below. CURRENT: GSA attributes are generally used to provide GMs with additional parameters for the GSA policy. NEW: Group SA attributes are generally used to provide GMs with additional parameters for the group SA policy. 5) Section 4.4.2.2.1. (1 instance) CURRENT: A single attribute of this type MUST be included into any GSA policy substructure if multicast rekey is employed by the GCKS. NEW: A single attribute of this type MUST be included into any group SA policy substructure if multicast rekey is employed by the GCKS. 5) Section 4.4.2.2.2. (1 instance) CURRENT: In this case this attribute will be included into the GSA policy when the GM is registered. NEW: In this case this attribute will be included into the group SA policy when the GM is registered. 6) Section 4.4.2.2.3. (1 instance) CURRENT: The length of the attribute data is determined by the SPI Size field in the GSA policy substructure the attribute resides in (see Section 4.4.2), and the attribute data contains the SPI as it would appear on the network. NEW: The length of the attribute data is determined by the SPI Size field in the group SA policy substructure the attribute resides in (see Section 4.4.2), and the attribute data contains the SPI as it would appear on the network. 7) Section 4.5.4 (1 instance) CURRENT: In addition, if the GCKS plans to use the multicast Rekey SA for group rekey, then it MUST specify the key wrap algorithm in the GSA policy for the Rekey SA inside the GSA payload. NEW: In addition, if the GCKS plans to use the multicast Rekey SA for group rekey, then it MUST specify the key wrap algorithm in the group SA policy for the Rekey SA inside the GSA payload. For "GSA Transforms": 8) Section 4.4.2. (2 instances) CURRENT: | | ~ <GSA Transforms> ~ | | [...] GSA Transforms (variable): NEW: | | ~ <Group SA Transforms> ~ | | [...] Group SA Transforms (variable): 9) Section 4.4.2.1. (1 instance) CURRENT: 4.4.2.1. GSA Transforms NEW: 4.4.2.1. Group SA Transforms For "GSA Attributes": 10) Section 4.4.2. (2 instances) CURRENT: | | ~ <GSA Attributes> ~ | | [...] GSA Attributes (variable): NEW: | | ~ <Group SA Attributes> ~ | | [...] Group SA Attributes (variable): 11) Section 4.4.2.2. (4 instances), see also 4) above CURRENT: 4.4.2.2. GSA Attributes [...] GSA attributes are generally used to provide GMs with additional parameters for the GSA policy. [...] |Value| GSA Attributes |Format|Multi-Valued| Used in | [...] Table 5: GSA Attributes NEW: 4.4.2.2. Group SA Attributes [...] Group SA attributes are generally used to provide GMs with additional parameters for the group SA policy. [...] |Value| Group SA Attributes |Format|Multi-Valued| Used in | [...] Table 5: Group SA Attributes 12) Section 5 (2 instances) CURRENT: | GSA Attributes (Section 4.4.2.2) | [...] | GSA Attributes (Section 4.4.2.2) | NEW: | Group SA Attributes (Section 4.4.2.2) | [...] | Group SA Attributes (Section 4.4.2.2) | 13) Section 9.1 (2 instances) CURRENT: 3. IANA has created the "Group SA Attributes" registry. The registration policy for this registry is Expert Review [RFC8126]. The initial values of the registry are as follows: +===========+======================+======+======+============+ |Value |Group SA Attributes |Format|Multi-|Used in | | | | |Valued|Protocol | Is this acceptable? Brian, Deb, your opinion? And this would require to update IANA registries, since the name of one is changed... Regards, Valery. I may not be tracking this issue correctly (and please correct me if I get this wrong). I would make acronyms (like GSA) consistent within this specification. I would not worry, or consider what other specifications use an acronym for some other expansion (heck, I see GSA and think 'General Services Administration' - a US Fed organization). Deb On Thu, Oct 16, 2025 at 5:28 PM Brian Weis <mailto:[email protected]> wrote: HI Madison, Valery, Deb, On Oct 9, 2025, at 7:29 AM, Madison Church <mailto:[email protected]> wrote: Hi Valery, Thank you for your reply! Please see inline. On Oct 7, 2025, at 3:56 AM, Valery Smyslov <mailto:[email protected]> wrote: Hi Madison, thank you for this update, please see inline. Hi Valery and Brian, Thank you for your replies! We have posted updated files below. We believe that there is now only one outstanding item to address (see inline). I noticed that the following requesting change wasn't done: 54) Section 4.4.1 CURRENT: Group policies are comprised of two types: GSA policy and GW policy. Perhaps it is not consistent, but I think that we should re-expand GW here (and perhaps GSA too). GW is defined in the very beginning and is not used up to this point, thus I think it would be helpful for readers to remind what it is. NEW: Group policies are comprised of two types: group SA (GSA) policy and group-wide (GW) policy. While I admit that the proposed text re-expanded the terms that have already been expanded, the rationale for it is that this expansion was ~30 pages before, and terms were not used since that, so re-expansion may help readers to refresh their memory. I don't insist, but I think this is helpful. Brian, Deb, your opinion? I see no issue with re-expanding the terms, but if Madison thinks it isn’t needed then let’s leave it be. 1) Thank you for pointing this out! This was actually meant to be included in the followup questions sent on 10/2, but must have gotten lost due to the number of changes in the original thread. Apologies for missing this! While making updates to this document, we noticed that there seems to be two different expansions for GSA (Group Security Association and group SA). Is this intentional, or may we make this consistent by replacing instances of "group SA" with the abbreviation "GSA"? If yes, may we also make the following adjustment to the "NEW" text as shown below? This is a very good point and indeed a point for some confusion. It is not intentional, the reason is the lack of words in authors' vocabulary (mostly me to blame) :-) We have the following meanings: - GSA (Group Security Association) - a collection of individual Security Associations (both Data-Security SAs and Rekey SAs) as defined in Section 1.2 (we also have GSA (Group Security Association) payload - this is just a name of a payload). - as for "group SA", - in the document this is used to refer to an individual Security Association within GSA (an SA that belongs to a group). Perhaps this is a bad choice of words, but that is that. Unfortunately, the abbreviation is the same - GSA... I believe Brian is more experienced in the roots of these terms and can comment on this. As mentioned in Section 1,"GSA (Group Security Association)" matches the definition in RFC 3740 (The Multicast Group Security Architecture), so this is indeed the most correct use of the GSA acronym. Then RFC 4046 (Multicast Security (MSEC) Group Key Management Architecture) introduced the confusing “group SA (GSA)” acronym, which somehow snuck into this document. I note that GDOI (RFC 6407), the predecessor to G-IKEv2, does not use that term for “group SA”. Thus, we have: - GSA - Group Security Association - GSA policy - group Security Association policy. This is indeed confusing. Perhaps we can replace "GSA policy" with "group SA policy" for clarity (14 instances)? Brian, Deb, your opinion? But there are still "GSA transforms" (meaning group SA transforms) and "GSA Attributes" (group SA attributes)... Any ideas? There’s also the “GSA Payload”, but because it lists policy for a collection of SAs, which matches the intent of the original definition. Thank you for the helpful explanation! We will wait for Brian’s response/comments before making any updates to the expansion of GSA. Thank you! Madison Church RFC Production Center Perhaps: Group policies are comprised of two types: Group Security Association (GSA) policy and group-wide (GW) policy. Based on the distinction described above I think that the correct expanding here should be: NEW: Group policies are comprised of two types: group SA (GSA) policy and group-wide (GW) policy. Rationale - the GSA policy here describes a single SA within a GSA. This would be the simplest change, and I do not believe that implementors would be confused by the duplicate use of “GSA". If we were earlier on in the document process I might have suggested a term to more cleanly delineate this policy element, but not now. I think in all three cases Valery mentioned (GSA policy, GSA transforms, GSA Attributes) the term “GSA” does not modify the word following, but is an equal part of the name of the object being referenced, if that makes sense. As such, I don’t see any problem leaving them as is, and simply add Valery’s NEW text above. Thanks, Brian Regards, Valery. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. Updated files have been posted below (please refresh): https://www.rfc-editor.org/authors/rfc9838.txt https://www.rfc-editor.org/authors/rfc9838.pdf https://www.rfc-editor.org/authors/rfc9838.html https://www.rfc-editor.org/authors/rfc9838.xml Updated diff files: https://www.rfc-editor.org/authors/rfc9838-diff.html https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9838-auth48diff.html https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9838-lastdiff.html (most recent updates only) https://www.rfc-editor.org/authors/rfc9838-lastrfcdiff.html (side by side) For the AUTH48 status page, please see: https://www.rfc- editor.org/auth48/rfc9838. Thank you! Madison Church RFC Production Center
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
