I approve that definition/change. Deb
On Tue, Oct 21, 2025 at 5: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. > > 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. > > 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. > > > 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. > > > 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. > > 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. > > 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]
