Hi Madison,
> On Oct 21, 2025, at 2:30 PM, Madison Church <[email protected]> > 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? > > > 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. > > 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. > 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 …" > 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 ... > > 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. 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]
