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]
