Hi Madison, Brian, Deb, thank you for this update, Please see inline (I trimmed the message slightly and also added few items I think I need to reply to from previous message).
> Hi Brian, > > Thank you for your reply! See inline for responses. > > > On Sep 26, 2025, at 11:44 AM, Brian Weis <[email protected]> wrote: > > > > HI Madison, > > > >> On Sep 26, 2025, at 6:48 AM, Madison Church <[email protected]> > >> wrote: > >> > >> Hi Valery and Brian, *Debbie, > >> > >> Thank you both for your replies and patience as we incorporate your > >> requested changes! We have updated the > document and have a few followup questions/comments inline (for easy > readability, we have only included > outstanding questions in this thread). > >> > >>>> I'm not sure I understand the visual effect of <aside> element (I guess > >>>> this is an xml2rfc v3 feature). > >>>> Can you point me to RFCs that use this element? > >>>> > >>>> And do you have some parts of this document in mind that > >>>> this element can be useful for? > >> > >> 1) Depending on author preference, we will occasionally use <aside> for > >> text marked as "Note:". The output > yields a visual of indented text with a vertical line on the left. For > example, RFCs 9800 [1] and 9801 [2] utilize the > <aside> element frequently. > >> > >> As for areas in this document that may benefit from the <aside>, the last > >> sentence of Section 1 (Introduction > and Overview) contains a note. > >> > >> [1]: https://www.rfc-editor.org/rfc/rfc9800.txt > >> [2]: https://www.rfc-editor.org/rfc/rfc9801.txt > > > > Thanks for the additional information and examples. I wouldn’t see any harm > > using this new feature for the > following notes, but am interested to hear Valery's thoughts since he’s more > in tune with the culture of the working > group and understanding how they would react to its use. > > > > 1. Section 1: "(Note: For clarity ….”. I agree (and I think no parentheses are needed in this case): > > 2. Section 1: “Also note that GCKS ….”, but removing the “Also” and > > changing “note” to “NOTE:”. OK, but I think it must be "Note:" (with a capital letter, but not all-uppercase) for consistency. And I think the sentence needs some editing: NEW: Note: GCKS may also be a GM (as shown in Figure 2). (I'm not sure about the need of the article in front of GCKS, sorry). > > 3. Section 2.3.1 “Note that due ….” I agree, but with no "that": NEW: Note: due to the similarities between IKE_AUTH and GSA_AUTH, most IKEv2 extensions to the IKE_AUTH exchange (like secure password authentication [RFC6467]) can also be used with the GSA_AUTH exchange. > > 4. Section 6.1. “Note that while …." I'd rather not to use <aside> here. Rationale: despite the "note" is used, the sentence actually is a continuation of the discussion of using implicit IV in multicast SAs. > Noted! We will wait for Valery’s review before making any updates regarding > the use of <aside>. Tables 2, 7, 9, and 10 have some notes below. I think that we can also use <aside> for these notes. Brian, your opinion? > 4) Thank you for pointing this out! We will ask IANA to update these > registries. We will also ask them to correct the "Unassigned" range in Table > 13 (as mentioned in mail from 9/24). I checked the IANA page and found no changes. I hope IANA will update the page before the publication is approved so that we can check :-) > 5) Understood! As of right now, the document is cited as [IPSEC-IKEV2-QR-ALT] > in the text. Would you like to update to use [RFC9867]? Yes! And draft-ietf-ipsecme-ikev2-qr-alt-10 (RFC-to-be 9867) should also reference this document as RFC9838 (as noted at https://www.rfc-editor.org/auth48/rfc9867). I re-read the document and noticed few more issues (the numeration of the issue continues). Some of the issues with the original text, some with the new text. Some of them are really nits, but still. 49) Section 1. CURRENT: The data communications within the group (e.g., IP multicast packets) are protected by a key pushed to the GMs by the Group Controller/Key Server (GCKS). Is it OK that "GM" is first used without expansion? It was expanded in the previous text version, but currently is first expanded only in Section 1.2 in the body of the document. It is also expanded in the Abstract, but I don't know if this matters. In contract, "GSA" and "GCKS" are expanded both in the Abstract and in Section 1 (and also in Section 1.2). Can we make this consistent? 50) Section 2.3.4, 2nd list item. CURRENT: * The GCKS could store the list of transforms with the goal of migrating the group policy from the current set of transforms to a different one once all of the GMs indicate that they can support transforms from the new set. This text was changed from using "list of Transforms" to list of "transforms". I think this is by mistake - in this case the meaning is not the list of some transformations, but the list of the Transform substructures that identified these transformations. The second and third use of lowercase "transforms" is correct. NEW: * The GCKS could store the list of Transforms with the goal of migrating the group policy from the current set of transforms to a different one once all of the GMs indicate that they can support transforms from the new set. 51) Section 2.4 CURRENT: The GCKS is responsible for rekeying the secure group per the group policy. Rekeying is an operation whereby the GCKS provides replacement TEK(s) and KEK, deleting TEK(s), and/or excluding GMs. I believe it should be: NEW: The GCKS is responsible for rekeying the secure group per the group policy. Rekeying is an operation whereby the GCKS provides replacement TEK(s) and/or KEK, deleting TEK(s), and/or excluding GMs. Rationale: GCKS may rekey either TEK(s) or KEK or both. 52) Section 2.4.1.1., Figure 10 CURRENT: | Next Payload | MjVer | MnVer | Exchange Type | Flags | H A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | Message ID | r | NEW: | Next Payload | MjVer | MnVer | Exchange Type | Flags | h A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | Message ID | r | Rationale - since we change everywhere "IKE Header" to "IKE header", we should also for consistency change this figure, where "IKE Hdr" is present vertically on the right (to make this "IKE hdr"). 53) Section 4 CURRENT: Several new payloads are defined: Group Identification (IDg) (Section 4.2), Security Association - GM Supported Transforms (SAg) (Section 4.3), GSA (Section 4.4), and Key Download (KD) (Section 4.5). It is inconsistent that IDg, KD and SAg payloads are mentioned in both in their full and abbreviated forms, while GSA payload is only mentioned abbreviated. Previous text used both forms for all payloads and I think this is right. NEW: Several new payloads are defined: Group Identification (IDg) (Section 4.2), Security Association - GM Supported Transforms (SAg) (Section 4.3), Group Security Association (GSA) (Section 4.4), and Key Download (KD) (Section 4.5). 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. 55) Section 4.4.1 CURRENT: Specifying multiple GSA TEKs allows multiple related data streams (e.g., video, audio, and text) to be associated with a session, but each are protected with an individual Security Association policy. I believe there is a typo and it should be (it is SA that protects stream, not policy): NEW: Specifying multiple GSA TEKs allows multiple related data streams (e.g., video, audio, and text) to be associated with a session, but each are protected with an individual Security Association. 56) Section 4.4.2.1.3 CURRENT: This document defines a new Transform ID for this Transform Type: 32-bit Unspecified Numbers (2). In previous two paras existing Transform IDs are shown in double quotes. I think that for consistency the new Transform ID be shown similarly. NEW: This document defines a new Transform ID for this Transform Type: "32-bit Unspecified Numbers" (2). 57) Section 5, notes for Table 9, note (2). CURRENT: (2): For a Data-Security SA, exactly one SA_KEY attribute MUST be present. For a Rekey SA, at least one SA_KEY attribute MUST be present in all cases and more of these attributes MAY be present in a GSA_REKEY pseudo-exchange. Despite we discussed this text and I proposed the current text, after re-reading it I think that it may be ambiguous. Perhaps we can make it more accurate: NEW: (2): For a Data-Security SA, exactly one SA_KEY attribute MUST be present. For a Rekey SA, exactly one SA_KEY attribute MUST be present in the GSA_AUTH and the GSA_REGISTRATION exchange, while in the GSA_REKEY pseudo-exchange, at least one SA_KEY attribute MUST be present and more of these attributes MAY be present. (I'm not quite sure about articles). 58) Section 9.1, Table 16. This table still has unswapped columns for name and value. Other tables have "value" column first. 59) Section 4.4.1 CURRENT: The first octet of the substructure unambiguously determines its type; it is zero for GW policy and non-zero (actually, it is a security Protocol ID) for GSA policies. NEW: 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. "Security Protocol Identifier" is the official name for protocol identifiers. 60) Section 2.3.3. CURRENT: Proposals for Rekey SA are identified by new Protocol ID GIKE_UPDATE with the value 6. NEW: Proposals for Rekey SA are identified by new Security Protocol Identifier GIKE_UPDATE with the value 6. "Security Protocol Identifier" is the official name for protocol identifiers. 61) Sections 4.7.1, 4.7.2, 4.7.3, 4.7.4 All these sections contain the same text: CURRENT: The Protocol ID and SPI Size fields in the Notify payload MUST be zero. Since "SPI Size" is a name of a field (as well as "Protocol ID") I wonder whether it should be prepended with "the" here? Apologize in advance if this is not needed, using articles is not my strong point... NEW (perhaps): The Protocol ID and the SPI Size fields in the Notify payload MUST be zero. 62) Section 4.4.2 CURRENT: The GSA policy substructure contains parameters for the SA that are used with this group. NEW: The GSA policy substructure contains parameters for the SA that is used with this group. Rationale: it is SA that used with this group, and parameters are for this SA. 63) Section 4.4.2.1.2 CURRENT: More key wrap algorithms may be defined in the future. The requirement is that these algorithms MUST be able to wrap key material of size up to 256 bytes. NEW: More key wrap algorithms may be defined in the future. The requirement is that these algorithms must be able to wrap key material of size up to 256 bytes. Rationale: I don't think that using RFC2119 language is justified here. This is not a requirement for implementations, it is a requirement for future specifications. 64) Section 4.5.1 CURRENT: The type is unambiguously determined by the first byte of the key bag substructure; for a Member Key Bag, it is zero and for a Group Key Bag, it is a protocol number, which is always non-zero. NEW: The type is unambiguously determined by the first byte of the key bag substructure; for a Member Key Bag, it is zero and for a Group Key Bag, it contains a Security Protocol Identifier, which is always non-zero. For rationale see issue 59 above. 65) Section 4.5.1 CURRENT: For a Group Key Bag, the protocol number along with the SPI (see Figure 20) identify the SA that is associated with the keys in this bag. NEW: For a Group Key Bag, the Protocol along with the SPI (see Figure 18) identify the SA that is associated with the keys in this bag. Two issues here - the figure number is incorrect (must be 18 instead of 20) and the, since the figure is referenced, the SPI and the Protocol are the names of the fields in this figure (thus "Protocol" instead of "protocol number") 66) Section 4.5.4 CURRENT: In G-IKEv2, the key wrap algorithm MUST be negotiated in the IKE_SA_INIT exchange so that the GCKS is able to send encrypted keys to the GM in the GSA_AUTH exchange. 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 payload. I think it should be amended for clarity. NEW: In G-IKEv2, the key wrap algorithm MUST be negotiated in the IKE_SA_INIT exchange so that the GCKS is able to send encrypted keys to the GM in the GSA_AUTH exchange. 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. 67) Section 8.1 CURRENT: G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT protocols, inheriting all the security considerations documented in Section 5 of [RFC7296], including authentication, confidentiality, on-path attack protection, protection against replay/reflection attacks, and denial- of-service protection. The GSA_AUTH and GSA_REGISTRATION exchanges also take advantage of those protections. NEW: G-IKEv2 registration procedure uses IKEv2 initial exchanges, inheriting all the security considerations documented in Section 5 of [RFC7296], including authentication, confidentiality, on-path attack protection, protection against replay/reflection attacks, and denial- of-service protection. The GSA_REGISTRATION exchange also takes advantage of those protections. Rationale: "IKE_SA_INIT protocols" is a bit weird naming, since IKE_SA_INIT is the name of an IKEv2 exchange. In contrast, RFC 7296 uses the name "initial exchanges" when referring to the IKE_SA_INIT + IKE_AUTH exchanges that are meant here. Then, since we already said about the initial registration, second sentence should only mention the GSA_REGISTRATION exchange. 68) Section 9.2, Table 19 CURRENT: +=======+=========================+==========+===========+ | Value | Next Payload Type | Notation | Reference | +=======+=========================+==========+===========+ | 33 | Security Association | SA | [RFC7296] | | +-------------------------+----------+-----------+ | | Security Association - | SAg | RFC 9838 | | | GM Supported Transforms | | | +-------+-------------------------+----------+-----------+ Shouldn't for consistency "RFC 9838" be shown in square brackets and with no space in between too? NEW: +=======+=========================+==========+===========+ | Value | Next Payload Type | Notation | Reference | +=======+=========================+==========+===========+ | 33 | Security Association | SA | [RFC7296] | | +-------------------------+----------+-----------+ | | Security Association - | SAg | [RFC9838] | | | GM Supported Transforms | | | +-------+-------------------------+----------+-----------+ Thank you! Regards, Valery. > 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) > > Thank you! > > Madison Church > RFC Production Center > > > Everything else looks fine to me. > > > > Thanks, > > Brian > > > >> > >>>> 40) Not all new IANA registries added to > >>>> https://www.iana.org/assignments/ikev2-parameters/ikev2- > parameters.xhtml > >>>> are properly filled in. In particular, the "Reserved for Private Use" > >>>> ranges in the "GSA Attributes", > >>>> the "Group-wide Policy Attributes" and the "Member Key Bag Attributes" > >>>> registries do not > >>>> reference to this document (while the "Group Key Bag Attributes" > >>>> registry does). > >> > >> 4) Thank you for pointing this out! We will ask IANA to update these > >> registries. We will also ask them to correct > the "Unassigned" range in Table 13 (as mentioned in mail from 9/24). > >> > >>>> I also have a proposal. The draft references > >>>> draft-ietf-ipsecme-ikev2-qr-alt-10, > >>>> which is currently in the RFC Editor queue in the state "AUTH48". > >>>> While it is only informatively referenced, I think that it would be > >>>> better if it is referenced > >>>> as RFC and not as I-D. Can you please make this possible (I think it > >>>> would require adding > >>>> draft-ietf-ipsecme-ikev2-qr-alt-10 to C532 cluster). > >> > >> 5) Understood! As of right now, the document is cited as > >> [IPSEC-IKEV2-QR-ALT] in the text. Would you like to > update to use [RFC9867]? > >> > >> 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 > >> > >> 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) > >> > >> For the AUTH48 status page, please see: > >> https://www.rfc-editor.org/auth48/rfc9838. > >> > >> Thank you! > >> > >> Madison Church > >> RFC Editor > >> > >>>> Regards, > >>>> Valery. > >>>> > >>>> > >>>>> Thank you. > >>>>> > >>>>> Madison Church and Karen Moore > >>>>> RFC Production Center > >>>>> > >>>>> > >>>>> On Sep 11, 2025, at 7:14 PM, RFC Editor via auth48archive > >>>>> <[email protected]> wrote: > >>>>> > >>>>> *****IMPORTANT***** > >>>>> > >>>>> Updated 2025/09/11 > >>>>> > >>>>> RFC Author(s): > >>>>> -------------- > >>>>> > >>>>> Instructions for Completing AUTH48 > >>>>> > >>>>> Your document has now entered AUTH48. Once it has been reviewed and > >>>>> approved by you and all coauthors, it will be published as an RFC. > >>>>> If an author is no longer available, there are several remedies > >>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >>>>> > >>>>> You and you coauthors are responsible for engaging other parties > >>>>> (e.g., Contributors or Working Group) as necessary before providing > >>>>> your approval. > >>>>> > >>>>> Planning your review > >>>>> --------------------- > >>>>> > >>>>> Please review the following aspects of your document: > >>>>> > >>>>> * RFC Editor questions > >>>>> > >>>>> Please review and resolve any questions raised by the RFC Editor > >>>>> that have been included in the XML file as comments marked as > >>>>> follows: > >>>>> > >>>>> <!-- [rfced] ... --> > >>>>> > >>>>> These questions will also be sent in a subsequent email. > >>>>> > >>>>> * Changes submitted by coauthors > >>>>> > >>>>> Please ensure that you review any changes submitted by your > >>>>> coauthors. We assume that if you do not speak up that you > >>>>> agree to changes submitted by your coauthors. > >>>>> > >>>>> * Content > >>>>> > >>>>> Please review the full content of the document, as this cannot > >>>>> change once the RFC is published. Please pay particular attention to: > >>>>> - IANA considerations updates (if applicable) > >>>>> - contact information > >>>>> - references > >>>>> > >>>>> * Copyright notices and legends > >>>>> > >>>>> Please review the copyright notice and legends as defined in > >>>>> RFC 5378 and the Trust Legal Provisions > >>>>> (TLP – https://trustee.ietf.org/license-info). > >>>>> > >>>>> * Semantic markup > >>>>> > >>>>> Please review the markup in the XML file to ensure that elements of > >>>>> content are correctly tagged. For example, ensure that <sourcecode> > >>>>> and <artwork> are set correctly. See details at > >>>>> <https://authors.ietf.org/rfcxml-vocabulary>. > >>>>> > >>>>> * Formatted output > >>>>> > >>>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>>> formatted output, as generated from the markup in the XML file, is > >>>>> reasonable. Please note that the TXT will have formatting > >>>>> limitations compared to the PDF and HTML. > >>>>> > >>>>> > >>>>> Submitting changes > >>>>> ------------------ > >>>>> > >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all > >>>>> the parties CCed on this message need to see your changes. The parties > >>>>> include: > >>>>> > >>>>> * your coauthors > >>>>> > >>>>> * [email protected] (the RPC team) > >>>>> > >>>>> * other document participants, depending on the stream (e.g., > >>>>> IETF Stream participants are your working group chairs, the > >>>>> responsible ADs, and the document shepherd). > >>>>> > >>>>> * [email protected], which is a new archival mailing list > >>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>> list: > >>>>> > >>>>> * More info: > >>>>> > >>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >>>>> > >>>>> * The archive itself: > >>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>>>> > >>>>> * Note: If only absolutely necessary, you may temporarily opt out > >>>>> of the archiving of messages (e.g., to discuss a sensitive matter). > >>>>> If needed, please add a note at the top of the message that you > >>>>> have dropped the address. When the discussion is concluded, > >>>>> [email protected] will be re-added to the CC list and > >>>>> its addition will be noted at the top of the message. > >>>>> > >>>>> You may submit your changes in one of two ways: > >>>>> > >>>>> An update to the provided XML file > >>>>> — OR — > >>>>> An explicit list of changes in this format > >>>>> > >>>>> Section # (or indicate Global) > >>>>> > >>>>> OLD: > >>>>> old text > >>>>> > >>>>> NEW: > >>>>> new text > >>>>> > >>>>> You do not need to reply with both an updated XML file and an explicit > >>>>> list of changes, as either form is sufficient. > >>>>> > >>>>> We will ask a stream manager to review and approve any changes that seem > >>>>> beyond editorial in nature, e.g., addition of new text, deletion of > >>>>> text, > >>>>> and technical changes. Information about stream managers can be found > >>>>> in > >>>>> the FAQ. Editorial changes do not require approval from a stream > >>>>> manager. > >>>>> > >>>>> > >>>>> Approving for publication > >>>>> -------------------------- > >>>>> > >>>>> To approve your RFC for publication, please reply to this email stating > >>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >>>>> as all the parties CCed on this message need to see your approval. > >>>>> > >>>>> > >>>>> Files > >>>>> ----- > >>>>> > >>>>> The files are available here: > >>>>> https://www.rfc-editor.org/authors/rfc9838.xml > >>>>> https://www.rfc-editor.org/authors/rfc9838.html > >>>>> https://www.rfc-editor.org/authors/rfc9838.pdf > >>>>> https://www.rfc-editor.org/authors/rfc9838.txt > >>>>> > >>>>> Diff file of the text: > >>>>> https://www.rfc-editor.org/authors/rfc9838-diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) > >>>>> > >>>>> Diff of the XML: > >>>>> https://www.rfc-editor.org/authors/rfc9838-xmldiff1.html > >>>>> > >>>>> > >>>>> Tracking progress > >>>>> ----------------- > >>>>> > >>>>> The details of the AUTH48 status of your document are here: > >>>>> https://www.rfc-editor.org/auth48/rfc9838 > >>>>> > >>>>> Please let us know if you have any questions. > >>>>> > >>>>> Thank you for your cooperation, > >>>>> > >>>>> RFC Editor > >>>>> > >>>>> -------------------------------------- > >>>>> RFC9838 (draft-ietf-ipsecme-g-ikev2-23) > >>>>> > >>>>> Title : Group Key Management using IKEv2 > >>>>> Author(s) : V. Smyslov, B. Weis > >>>>> WG Chair(s) : Yoav Nir, Tero Kivinen > >>>>> > >>>>> Area Director(s) : Deb Cooley, Paul Wouters > >>>>> > >>>>> > >>>>> -- > >>>>> auth48archive mailing list -- [email protected] > >>>>> To unsubscribe send an email to [email protected] > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
