IANA, Please make the following changes to match the updated document (RFC 9838).
1) Update the title of the "Group-wide Policy Attributes" registry (https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#group-wide-policy-attributes) to "Group-Wide Policy Attributes". 2) The "Reserved for Private Use" ranges in the "GSA Attributes", "Group-wide Policy Attributes", and "Member Key Bag Attributes" registries do not reference this document (while the "Group Key Bag Attributes" registry does; see https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#group-key-bag-attributes). Please update the reference column of the three registries listed above to include this document as a reference for the "Reserved for Private Use" ranges. 3) For the "GSA Attributes" registry, please update the following: a) Update the "Unassigned" range to "4-16383" (originally "5-16383"). b) Update the registry title to "Group SA Attributes" (originally "GSA Attributes"). c) Update the title of the "GSA Attributes" column to "Group SA Attributes". For a visual of these updates, please see: https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html. Thank you! Madison Church RFC Production Center > On Oct 28, 2025, at 9:32 AM, Madison Church <[email protected]> > wrote: > > Hi Valery and Brian, > > Thank you for your replies! We have updated the document accordingly and have > noted both approvals on the AUTH48 status page (see > https://www.rfc-editor.org/auth48/rfc9838). Now that we have all author > approvals, we will send updates to IANA shortly. > > Updated files: > 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 > https://www.rfc-editor.org/authors/rfc9838-lastrfcdiff.html (side by side) > > Thank you! > > Madison Church > RFC Production Center > > >> On Oct 28, 2025, at 3:13 AM, Valery Smyslov <[email protected]> wrote: >> >> Hi Madison and Brian, >> >> thank you for this update. >> >> >> While re-reading the text, I found one more unfixed instance of incorrect >> use of "GSA": >> >> Section 4.4.2.2.1. >> >> CURRENT: >> When >> the lifetime expires, the GSA and all associated keys MUST be >> deleted. >> >> NEW: >> When >> the lifetime expires, the group SA and all associated keys MUST be >> deleted. >> >> >> I approve the publication provided that this is fixed. >> >> Thank you all for your patience and cooperation! >> >> Regards, >> Valery. >> >> >>> Hi Brian and Valery, >>> >>> Thank you for your replies! We have updated the document with Valery’s >>> “Perhaps 5” suggestion. That said, we >>> believe there are no further questions remaining. >>> >>> Once we receive approvals from both authors, we will send updates along to >>> IANA! >>> >>> 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 diff) >>> https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) >>> https://www.rfc-editor.org/authors/rfc9838-auth48diff.html (AUTH48 changes) >>> https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html (side by >>> side) >>> https://www.rfc-editor.org/authors/rfc9838-lastdiff.html (most recent >>> changes) >>> https://www.rfc-editor.org/authors/rfc9838-lastrfcdiff.html (side by side) >>> >>> Thank you! >>> Madison Church >>> RFC Production Center >>> >>> >>>> On Oct 23, 2025, at 10:47 AM, Brian Weis <[email protected]> wrote: >>>> >>>> Hi Valery, >>>> >>>> I’m quite happy with your “Perhaps 5” text. Let’s go with that. I think >>>> this might be the last wording issue. :-) >>>> >>>> Thanks, >>>> Brian >>>> >>>>> On Oct 22, 2025, at 10:09 PM, Valery Smyslov <[email protected]> wrote: >>>>> >>>>> 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]
