Hi Madison and Karen, thank you, please find my answers inline. I have not yet reviewed all the changes (via diff) and have not check whether IANA Considerations section matches IANA page. The amount of changes is significant, so I plan to do this after you process this message.
Note that my co-author (Brian Weis) may express his own opinion on some topics. > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are > also in the source file. > > 1) <!-- [rfced] Because this document obsoletes RFC 6407, please review > the errata reported for RFC 6407 > (https://www.rfc-editor.org/errata_search.php?rfc=6407) and let > us know if you confirm our opinion that none of them are relevant > to the content of this document. > --> Confirmed. > 2) <!-- [rfced] Please note that the title of the document has been updated to > expand abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). > > Original: > Group Key Management using IKEv2 > > Current: > Group Key Management Using the Internet Key Exchange > Protocol Version 2 (IKEv2) > --> This is OK. > 3) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> multicast security IPsec GDOI MSEC > 4) <!-- [rfced] Please review whether any of the notes in this document > should be in the <aside> element. It is defined as "a container for > content that is semantically less important or tangential to the > content that surrounds it" > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > --> 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? > 5) <!--[rfced] As the full titles of RFCs 3740, 5374, and 6407 are > included in Section 1, we removed the titles from the following > text in Section 1.2. Please let us know of any objections. > > Original: > The following key terms are used throughout this document (mostly > borrowed from the Multicast Group Security Architecture [RFC3740], > Multicast Extensions to the Security Architecture [RFC5374], and the > Group Domain of Interpretation (GDOI) [RFC6407]). > > Current: > The following key terms are used throughout this document (mostly > borrowed from [RFC3740], [RFC5374], and [RFC6407]). > --> Fine with me, thank you.. > 6) <!-- [rfced] Should the following sentence be rephrased as shown below > to clarify "IKE SA"? > > Current: > G-IKEv2 MAY also use TCP transport for registration (unicast) IKE SA, > as defined in TCP Encapsulation of IKEv2 and IPsec [RFC9329]. > > Perhaps: > G-IKEv2 MAY also use TCP transport for the registration (unicast) of IKE > SA, > as defined in TCP Encapsulation of IKEv2 and IPsec [RFC9329]. > --> No, this makes it meaningless. I seem to guess what the problem with the sentence is (the lack of article, as my usual problem), but in this case the correct change would be: NEW: G-IKEv2 MAY also use TCP transport for the IKE SA used for registration (which is unicast), as defined in TCP Encapsulation of IKEv2 and IPsec [RFC9329]. > 7) <!-- [rfced] Please review Table 1 in Section 2.2. We note that there > is some variation between the payload names used in this table > and those used in RFC 7296. For example, in RFC 7296, "HDR" is > "IKE header (not a payload)" and "SK" is "Encrypted and > Authenticated". Please let us know if we should update this table > to match what appears in RFC 7296. I think that the description of HDR should match that in RFC 7296 ("IKE header (not a payload)". Regarding SK I prefer the description to be: NEW: "Encrypted and Authenticated (also known as Encrypted)" The reason is that this payload is almost always referred to as "Encrypted" (even in RFC7296), while it is officially named "Encrypted and Authenticated". This document also refers to this payload to as "Encrypted", thus we should only clarify that these names define the same payload. > In addition, we note the following variations in Table 1 and the > running text. Should the payload for "IDg" be updated as "Group > Identification" to match Table 18 (i.e., the "IKEv2 Payload Types" > IANA registry)? Please let us know how we may make these > consistent. > > IDg: Identification - Group (Table 1) vs. Yes, please change the name in the Table 1 of to match that in the Table 18. CURRENT: Identification - Group NEW: Group Identification > Group Identification (IDg) vs. This is the correct payload name. > Group ID (IDg) vs. I found a single occurrence of "Group ID (IDg)" - in Section 2.2 below Table 1: CURRENT: Group ID (IDg): NEW: Group Identification (IDg): > group IDg vs. I found a single occurrence of "group IDg" - in Section 2.3.2: CURRENT: The group member SHOULD notify the GCKS by sending IDg and the Notify type NO_PROPOSAL_CHOSEN or REGISTRATION_FAILED as shown below. In this case, the GCKS MUST remove the GM from the group IDg. Please, update this text as follows: NEW: The group member SHOULD notify the GCKS by sending IDg and the Notify type NO_PROPOSAL_CHOSEN or REGISTRATION_FAILED as shown below. In this case, the GCKS MUST remove the GM from the group denoted in IDg. > group ID I found a single occurrence of "group ID" - in Section 4.7.1: Please, update this para as follows: CURRENT: INVALID_GROUP_ID (45) is a new error type notification that indicates that the group ID sent during the registration process is invalid. NEW: INVALID_GROUP_ID (45) is a new error type notification that indicates that the IDg payload sent during the registration process denotes invalid group. > --> > 8) <!--[rfced] In the following, should "Data-Security SAs" be singular > since "TEK" is singular? Also, are all of these items optional > (option A), or are only the Rekey SA and Group-wide policy > optional (option B)? > > Original: > This policy describes the optional Rekey SA (KEK), > Data-Security SAs (TEK), and optional Group-wide (GW) > policy. > > Perhaps A: > This policy describes the Rekey SA (KEK), > Data-Security SA (TEK), and Group-wide (GW) > policy, which are all optional. > > or > Perhaps B: > This policy describes the Data-Security SA (TEK), optional > Rekey SA (KEK), and optional Group-wide (GW) policy. > --> I propose the following text instead: NEW: This policy describes one or more Data-Security SAs (TEK), zero or one Rekey SA (KEK), and zero or one Group-wide (GW) policy. I realize that TEK is still in a singular form, but I hope this is acceptable. Let me know if this must be changed by all means. > 9) <!-- [rfced] How may we update the sentence below to clarify the second > and third instances of "Transforms"? > > Original: > * The GCKS could store the list of Transforms, with the goal of > migrating the group policy to a different Transforms when all of > the group members indicate that they can support that Transforms. > > Perhaps A: > * The GCKS could store the list of Transforms with the goal of > migrating the group policy to a different Transform when all of > the group members indicate that they can support that Transform. > > or > Perhaps B: > * The GCKS could store the list of Transforms with the goal of > migrating the group policy to a different Transforms list when all of > the group members indicate that they can support that Transforms list. > --> I propose the following clarification: 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 group members indicate that they can support transforms from the new set. > 10) <!--[rfced] How may we clarify this sentence. Should "KEK" be plural > like "TEKs"? Does the GCKS delete the TEKs and/or exclude the > group members as shown below? > > Original: > Rekeying is an operation whereby the GCKS provides > replacement TEKs and KEK, deleting TEKs, and/or > excluding group members. > > Perhaps: > Rekeying is an operation whereby the GCKS provides > replacement TEKs and KEKs, deletes TEKs, and/or > excludes group members. > --> There may be several TEKs (one or more), but only one KEK. Perhaps: NEW: Rekeying is an operation whereby the GCKS provides replacement TEK(s) and KEK, deleting TEK(s), and/or excluding group members. > 11) <!--[rfced] Should "a Data-Security SAs" be singular or plural in this > sentence (e.g., "a new Data-Security SA" or "new Data-Security > SAs")? > > Original: > The GSA may contain a new Rekey SA and/or a new Data- > Security SAs Section 4.4. > > Perhaps: > The GSA may contain a new Rekey SA and/or a new Data- > Security SA (Section 4.4). > --> There may be zero or more Data-Security SAs but no more than one Rekey SA, and at list one SA of any type must be present. Perhaps: NEW: The GSA may contain a new Rekey SA and/or new Data- Security SA(s) Section 4.4. > 12) <!-- [rfced] FYI: We updated "that with" to "with the" as follows. > > Original: > The RESERVED field in the reconstructed Encrypted Payload header > MUST be set to the value of the RESERVED field in the Encrypted > Fragment payload header from the first fragment (that with > Fragment Number equal to 1). > > Current: > The RESERVED field in the reconstructed Encrypted Payload header > MUST be set to the value of the RESERVED field in the Encrypted > Fragment payload header from the first fragment (with the > Fragment Number equal to 1). > --> This change is fine, thank you. > 13) <!-- [rfced] We added parentheses to this sentence for ease of > reading. Please let us know of any objections. > > Original: > If the message includes Delete payload for existing Data-Security SA, > then after installing a new Data-Security SA the old one, identified > by the Protocol and SPI fields in the Delete payload, MUST be silently > deleted after waiting DEACTIVATION_TIME_DELAY interval regardless of > its expiration time. > > Current: > If the message includes a Delete payload for an existing Data-Security SA, > then after installing a new Data-Security SA, the old one (identified by > the > Protocol and SPI fields in the Delete payload) MUST be silently deleted > after > waiting the DEACTIVATION_TIME_DELAY interval regardless of its expiration > time. > --> This change is fine, thank you. > 14) <!-- [rfced] We have updated this sentence to use "AES CCM" (per > RFC 4309) rather than "AES-CCM". Please let us know any > objections. > > Original: > Several counter-based modes of operation have been specified for ESP > (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], > ChaCha20-Poly1305 [RFC7634], AES-GMAC [RFC4543]) and AH (e.g., AES- > GMAC [RFC4543]). > > Current: > Several counter-based modes of operation have been specified for ESP > (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES CCM [RFC4309], > ChaCha20-Poly1305 [RFC7634], and AES-GMAC [RFC4543]) and AH (e.g., AES- > GMAC [RFC4543]). > --> Hmm, obviously, I should have no objections to this as RFC 4309 uses this form but actually this is a big surprise for me: the lack of consistency in naming :-) And a number of RFCs related to IPsec (I suspect there are others too) actually use "AES-CCM" form (RFC8247, RFC7321). Thus, I have no position and rely on AD's decision on this. > 15) <!--[rfced] Please clarify what "literature" refers to here. > > Original: > Group management algorithms providing forward and backward access > control other than LKH have been proposed in the literature, > including OFT [OFT] and Subset Difference [NNL]. > > Perhaps: > Group management algorithms providing forward and backward access > control other than LKH have been proposed in other specifications, > for example, OFT [OFT] and Subset Difference [NNL]. > --> I think we may change it to: NEW: Group management algorithms providing forward and backward access control other than LKH have also been proposed, for example, OFT [OFT] and Subset Difference [NNL]. > 16) <!-- [rfced] May we update "if they are take place" for clarity in the > sentence below? > > Original: > For the unicast IKE SA (used for the GM registration and for the > GSA_INBAND_REKEY exchanges, if they are take place) the GSK_w is > computed as follows: > > Perhaps: > For the unicast IKE SA (used for the GM registration and for > GSA_INBAND_REKEY exchanges if they appear), the GSK_w is > computed as follows: > --> Yes, thank you. > 17) <!--[rfced] Is "null termination" correct, or should it be "NUL > termination"? > > Current: > where the string "Key Wrap for G-IKEv2" is 20 ASCII characters > without null termination. > --> This text is borrowed verbatim from RFC 7296 (Section 2.15), thus I believe should remain unchanged. > 18) <!-- [rfced] We have replaced "it" with "GM" for clarity and removed > "this GM" to avoid redundancy. Please let us know if this is not > correct. > > Original: > This situation may only happen at the time the GM is registering to > the group, when the GCKS is providing it with its personal key and the > other > keys from the key tree that are needed for this GM. > > Current: > This situation may only happen at the time the GM is registering to > the group, when the GCKS is providing the GM with its personal key and the > other keys from the key tree that are needed. > --> I'm fine with this change, thank you. > 19) <!-- [rfced] In this sentence, is GSK_e used for the Encryption > Algorithm and GSK_a for the Integrity Algorithm (option A), or > are GSK_e and GSK_a used for both the Encryption Algorithm and > the Integrity Algorithm (option B)? > > Original: > where GSK_e and GSK_a are the keys used for the Encryption Algorithm > and the Integrity Algorithm transforms for the corresponding SA and > GSK_w is a default KWK for this SA. > > Perhaps A: > where GSK_e and GSK_a are the keys used for the Encryption Algorithm and > the Integrity Algorithm transforms, respectively, for the corresponding > SA and GSK_w is a default KWK for this SA. > > or > Perhaps B: > where GSK_e and GSK_a are the keys used for both the Encryption Algorithm > and the Integrity Algorithm transforms for the corresponding SA and > GSK_w is a default KWK for this SA. > --> Option A is correct. > 20) <!-- [rfced] FYI - We have updated the following sentence to reduce > the repetition of "payload" and to match use in Table 1. Please > let us know any objections. > > Original: > The Security Association - GM Supported Transforms Payload (SAg) > payload declares which Transforms a GM is willing to accept. > > Current: > The Security Association - GM Supported Transforms (SAg) payload > declares which Transforms a GM is willing to accept. > --> No objections, thank you. > 21) <!-- [rfced] Should "Last Substruc" be "Last Substruct" or "Last > Substructure" in the sentence below? Or is "Last Substruc" > correct here? > > Original: > The "Last Substruc" field in each Transform Substructure is set to 3 > except for the last Transform Substructure, where it is set to 0. > > Perhaps: > The "Last Substructure" field in each Transform Substructure is set > to 3 except for the last Transform Substructure, where it is set to 0. > --> The original text is correct. It refers to the field name (weird, I agree), defined in RFC 7296, Section 3.3.2. > 22) <!-- [rfced] May we restructure the text below as follows for readability? > > Current: > This transform ID defines the following properties. Sequence numbers > are 32-bit in size and are transmitted in the Sequence Number field of AH > and > ESP packets. The value of sequence numbers is not guaranteed to be unique > for > the duration of an SA, thus they are not suitable for replay protection. > This > transform ID MUST be used by the GCKS in case of multi-sender multicast > Data-Security SAs utilizing protocols ESP or AH to inform the GMs that the > replay protection is not expected to be possible. The GCKS MAY also use > this > transform ID for single-sender multicast Data-Security SAs if replay > protection is not needed (e.g. it is done on application level). > > > Perhaps: > This transform ID defines the following properties: > > * Sequence numbers are 32 bits in size and are transmitted in the Sequence > Number field of AH and ESP packets. > > * The value of sequence numbers is not guaranteed to be unique for > the duration of an SA, thus they are not suitable for replay > protection. > > * This transform ID MUST be used by the GCKS in the case of multi-sender > multicast Data-Security SAs utilizing protocols ESP or AH to inform > the GMs that the replay protection is not expected to be possible. > > * The GCKS MAY also use this transform ID for single-sender multicast > Data-Security SAs if replay protection is not needed (e.g., it is done > on the application level). > --> Actually, only two first bullet define the properties, the last two just explain how to use this transform ID. I propose instead the following variants. Option A - split para and do not add list: NEW (Option A): This transform ID defines the following properties. Sequence numbers are 32 bits in size and are transmitted in the Sequence Number field of AH and ESP packets. The value of sequence numbers is not guaranteed to be unique for the duration of an SA, thus they are not suitable for replay protection. This transform ID MUST be used by the GCKS in case of multi-sender multicast Data-Security SAs utilizing protocols ESP or AH to inform the GMs that the replay protection is not expected to be possible. The GCKS MAY also use this transform ID for single-sender multicast Data-Security SAs if replay protection is not needed (e.g., it is done on the application level). Option B - use list for properties only: NEW (Option B): This transform ID defines the following properties: * Sequence numbers are 32 bits in size and are transmitted in the Sequence Number field of AH and ESP packets. * The value of sequence numbers is not guaranteed to be unique for the duration of an SA, thus they are not suitable for replay protection. This transform ID MUST be used by the GCKS in case of multi-sender multicast Data-Security SAs utilizing protocols ESP or AH to inform the GMs that the replay protection is not expected to be possible. The GCKS MAY also use this transform ID for single-sender multicast Data-Security SAs if replay protection is not needed (e.g., it is done on the application level). I have no preferences, but perhaps option B looks a bit neater. > 23) <!--[rfced] May we rephrase this sentence as shown below for clarity > (i.e., remove "in these cases" to reduce redundancy)? Note that > we included the lead-in sentence for context. > > Lead-in sentence: > A single attribute of this type is included into the GSA KEK policy > substructure if the initial Message ID of the Rekey SA is non-zero. > > Original: > Note, that it is always the case if GMs join the group after some > multicast rekey operations have already taken place, so in these > cases this attribute will be included into the GSA policy when the > GM is registered. > > Perhaps: > Note that this is always the case if GMs join the group after some > multicast rekey operations have already taken place, so this > attribute will be included into the GSA policy when the GM is > registered. > --> I think it can be rephrased for clarity: NEW: Note that it is always true if a GM joins the group after some multicast rekey operations have already taken place in this group. In this case this attribute will be included into the GSA policy when the GM is registered. > 24) <!-- [rfced] We have rephrased the sentence below as follows for > clarity. Please let us know any objections. > > Original: > The GM MAY store these values and if later the GM starts receiving > messages with one of these SPIs without seeing a rekey message over > the current Rekey SA, this may be used as an indication, that the > rekey message got lost on its way to this GM. > > Current: > The GM MAY store these values. Later on, if the GM starts receiving > messages with one of these SPIs without seeing a rekey message over > the current Rekey SA, then it may be used as an indication that > the rekey message got lost on its way to this GM. > --> This change is OK, thank you. > 25) <!-- [rfced] Is the space in the parentheses intentional in the text > below, or should "( octet)" be updated as "(0 octet)" per the > description? Note that there are two instances (Sections 4.4.3 > and 4.5.3). > > Original: > * RESERVED ( octet) - MUST be zero on transmission, MUST be ignored > on receipt. > --> This is a typo, it must be: NEW: * RESERVED (1 octet): MUST be zero on transmission and MUST be ignored on receipt. in both places ("1 octet" is the size of the field). I also noticed that in Section 4.4.3 the style of field descriptions differs from that in other places - in Section 4.4.3 a description starts on the same line as the field name, while in all other places it starts on the next line. Can we make this consistent across the document? > 26) <!--[rfced] "Length" vs. "Payload Length" > > a) We note that Figure 16 uses "Payload Length" whereas > Figures 17, 18, 19, 20, and 21 use "Length". Is this > variance okay, or is an update needed to Figure 16 > for consistency? Thank you for bringing this to my attention. This variance is OK (but see below). Figure 16 depicts a payload, generic payload header is defined in Section 3.2 of RFC 7296 and the length there is denoted as "Payload Length". Other figures (except for 19) define various substructures inside payloads that are not payloads themselves and use more generic "Length" name for the field. However, Figure 19 also depicts a payload, but this is related to the next item... > b) In Section 4.5, we note "Length" in Figure 19 but "Payload > Length" in the description. We updated the description to > reflect "Length" as shown below. If that is not correct, > please let us know. > > Original: > Next Payload, C, RESERVED, and Payload Length fields: > Comprise the IKEv2 Generic Payload Header and are defined in > Section 3.2 of [RFC7296]. > > Current: > Next Payload, C, RESERVED, and Length fields: > Comprise the IKEv2 Generic Payload Header and are defined in > Section 3.2 of [RFC7296]. > --> Since Figure 19 depicts a payload, the correct name of the field is "Payload Length". Please, revert the above change and also change the name in the figure from "Length" to "Payload Length": NEW: | Next Payload |C| RESERVED | Payload Length | > 27) <!-- [rfced] May we rephrase the following text to simplify the > sentence structure? Also, does "the following SPI" refer to the > SPI in Figure 20? > > Original: > For this reason two types of key bags are defined - Group Key Bag > and Member Key Bag. The type is unambiguously determined by the first > byte of the key bag substructure - for member key bag it is zero and > for group key bag it represents the protocol number, which along with > the following SPI, identify the SA associated with the keys in the > bag. > > Perhaps: > For this reason, two types of key bags are defined: Group Key Bag and > Member Key Bag. The type is unambiguously determined by the first byte of > the key bag substructure; for a Member Key Bag, it is zero. The Group Key > Gag is represented by the protocol number, and the protocol number along > with the SPI (see Figure 20) identify the SA that is associated with > the keys in the bag. > --> I think that this text hides the point that the first byte of key bag substructure allows to distinguish between member key bag and group key bag (and there is also a typo "Group Key Gag"). Instead, I propose the following change (based on your text): NEW: For this reason, two types of key bags are defined: Group Key Bag and Member Key Bag. 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. 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. > 28) <!-- [rfced] Please review Table 7 and let us know if the format appears > as intended. Specifically, are the "Multi-Valued" and "Used in Protocol" > columns correctly formatted? > --> The format is correct and is intentional. The idea is that we actually have 2 lines for SA_KEY - in case in is used in GIKE_UPDATE it is multi-valued, in case it is used in AH and ESP - it is single-valued. The same format is used in Table 15. We discussed this with IANA and they created the table with exactly this format. > 29) <!-- [rfced] FYI - We rephrased the text below for better sentence > flow. Please let us know of any objections. > > Original: > If the key bag is for a Rekey SA (GIKE_UPDATE protocol), then in the > GSA_AUTH, GSA_REGISTRATION and GSA_INBAND_REKEY exchanges exactly one > SA_KEY > attribute MUST be present. > > Current: > If the key bag is for a Rekey SA (GIKE_UPDATE protocol), then exactly > one SA_KEY attribute MUST be present in the GSA_AUTH, GSA_REGISTRATION, and > GSA_INBAND_REKEY exchanges. > --> Fine, thank you. > 30) <!-- [rfced] In Section 4.5.3.2, since there is only one list item in > this unordered list, would it be appropriate to remove the bullet > and make it into a paragraph? > > Original: > * If digital signatures are used for the GSA_REKEY message > authentication then the content of the AUTH_KEY attribute is a > public key used for digital signature authentication. The public > key MUST be represented as DER-encoded ASN.1 object > SubjectPublicKeyInfo, defined in Section 4.1.2.7 of "Internet > X.509 Public Key Infrastructure Certificate and Certificate > Revocation List (CRL) Profile" [RFC5280]. The algorithm field > inside the SubjectPublicKeyInfo object MUST match the content of > the Signature Algorithm Identifier attribute in the Group > Controller Authentication Method transform. When the id-RSASSA- > PSS object identifier appears in the algorithm field of the > SubjectPublicKeyInfo object, then the parameters field MUST > include the RSASSA-PSS-params structure. > > Perhaps: > If digital signatures are used for the GSA_REKEY message > authentication, then the content of the AUTH_KEY attribute is a > public key used for digital signature authentication. The public > key MUST be represented as DER-encoded ASN.1 object > SubjectPublicKeyInfo, defined in Section 4.1.2.7 of > [RFC5280]. The algorithm field inside the SubjectPublicKeyInfo > object MUST match the content of the Signature Algorithm > Identifier attribute in the Group Controller Authentication Method > transform. When the id-RSASSA-PSS object identifier appears in > the algorithm field of the SubjectPublicKeyInfo object, then the > parameters field MUST include the RSASSA-PSS-params structure. > --> I'd rather keep the list even that it is redundant here - it shows that the content of the AUTH_KEY Attribute depends on authentication method, even that the current document defines only one. Perhaps we can add a bullet here to make using list justified: NEW (a new bullet in the list): * In case of implicit authentication the AUTH_KEY Attribute is not used and MUST be absent (see Section 2.4.1). (note, that this is not a new requirement, this is only a paraphrase of what the last sentence in 2.4.1 says). > 31) <!-- [rfced] The following sentence is hard to parse. Would either of > the following proposals improve readability and retain the > sentence's original meaning? > > Original: > Note, that the restrictions are defined per a substructure > corresponding attributes are defined for and not per whole G-IKEv2 > message. > > Perhaps A: > Note that the restrictions are defined per a substructure > corresponding to the attributes that are defined and not > per a whole G-IKEv2 message. > > or > Perhaps B: > Note that the restrictions are defined per a substructure for which > corresponding attributes are defined and not per a whole > G-IKEv2 message. > --> Option B is correct, please use it to improve readability. > 32) <!--[rfced] How may we update this sentence to clarify "and more these > attributes MAY be present"? Perhaps "one or more SA_KEY > attributes MAY be present in a GSA_REKEY exchange"? > > Current: > For a Data-Security SA, exactly one SA_KEY attribute MUST be > present. For a Rekey SA, one SA_KEY attribute MUST be present in all > cases and more these attributes MAY be present in a GSA_REKEY exchange. > > Perhaps: > For a Data-Security SA, exactly one SA_KEY attribute MUST be > present. For a Rekey SA, one SA_KEY attribute MUST be present in all > cases and one or more SA_KEY attributes MAY be present in a GSA_REKEY > exchange. > --> I would propose a different text change (also relates to item 42d below): NEW: 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 and, in case of GSA_REKEY pseudo-exchange, additional SA_KEY attributes MAY be present. > 33) <!--[rfced] How may we clarify this sentence? Is the sender proven to > be a member of the group when the GM "decrypts and verifies the > ICV"? > > Original: > An implicit authentication can also be used, in which case, > the ability of the GM to decrypt and to verify ICV of the > received message proved that a sender of the message is a > member of the group. > > Perhaps: > An implicit authentication can also be used, in which case > the GM decrypts and verifies the ICV of the received > message to prove that a sender of the message is a > member of the group. > --> This is not incorrect, but the original text tries to stress that the authentication is implicit: the receiver will decrypt the message and verify its ICV just to get this message for application and not to (explicitly) authenticate the sender. The proposed text sounds like this is the goal. Perhaps the following text is clearer: NEW: An implicit authentication can also be used, in which case, the ability of the GM to decrypt and to verify ICV of incoming messages is used as a proof that the sender knows group keys and therefore is a member of the group. > 34) <!-- [rfced] We have included some specific questions about the IANA > text below. In addition to responding to those questions, please > review all of the IANA-related updates carefully, including the > IANA values in the running text, and let us know if any further > updates are needed. > > Please refer to the following URL to view the IANA registries: > <https://www.iana.org/assignments/ikev2-parameters/> > > a) For Tables 3-7 and 11-16, may we order the "Value" columns first to match > the corresponding IANA registries? Yes. > b) FYI: For Tables 11-16, we updated "Private Use" to "Reserved > for Private Use" to match the corresponding IANA registries. OK, thank you. > c) Please clarify the text below. Was "new registrations" perhaps > intended rather than "changes and additions to the unassigned range"? > Note that there are multiple instances. > > Original: > Changes and additions to the unassigned range of this registry > are by the Expert Review Policy [RFC8126]. > > Perhaps: > In this registry, new registrations are to be made by Expert > Review [RFC8126]. Perhaps use even simpler form? NEW (proposed): The registration policy for this registry is Expert Review [RFC8126]. > d) May we update the title of the "Group-wide Policy Attributes" registry > to "Group-Wide Policy Attributes" (i.e., make "wide" uppercase as it's an > adjective within a hyphenated compound)? Sure. > e) FYI: For clarity, we added the "Reference" column to Table 19 to show > that the "Security Association" Payload Type was registered by RFC 7296. > If this is not desired, please let us know. I don't think this is necessary, because the text above says that this definition is updated and not created. In IPsec documents we usually omit "Reference" column in IANA considerations, the IANA kindly adds it for us, let us keep this tradition :-) > f) Is it helpful for the reader if the history of the SENDER_REQUEST_ID > registration is included? If so, should an informative reference to > "draft-yeung-g-ikev2-07" (e.g., "[G-IKEV2]") be added (option A)? Or > if the history isn't necessary, is option B preferred? > > Original: > The Notify type with the value 16429 was allocated earlier in the > development of G-IKEv2 document in the "IKEv2 Notify Message > Status Types" registry with the name SENDER_REQUEST_ID. This document > renames it as follows: > > Perhaps A: > An earlier draft of this document [G-IKEV2] registered the Notify > type 16429 with the name SENDER_REQUEST_ID. Per this document, > IANA has updated the "IKEv2 Notify Message Status Types" registry > as follows: > > or > Perhaps B: > IANA has registered the following in the "IKEv2 Notify Message Status > Types" registry: > --> I prefer option A. This name existed in IANA registry for decade, so it is better to keep the history. Just one minor suggestion - can we be more specific and say "renamed" instead of "updated"? NEW (proposed): An earlier draft of this document [G-IKEV2] registered the Notify type 16429 in the "IKEv2 Notify Message Status Types" registry with the name SENDER_REQUEST_ID. Per this document, IANA has renamed it as follows: > 35) <!-- [rfced] May we replace "so after all" with "and thus" in the > sentence below for improved clarity? > > Current: > Similarly, when other GMs will be joining the group, they will be > provided with the corresponding keys, so after all, the GMs will have > the following Working Key Paths: > > Perhaps: > Similarly, when other GMs join the group, they will be > provided with the corresponding keys and thus the GMs > will have the following Working Key Paths: > --> No objections. > 36) <!-- [rfced] Abbreviations > > a) FYI - We have added expansions for abbreviations upon first use > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. OK. > b) We note that some abbreviations are expanded multiple times > throughout the document. If there are no objections, we will update terms > to use their abbreviations after their first expansions for consistency. > > One example (see the document for more examples): > > Group Member -> GM > --> No objections. > 37) <!-- [rfced] Terminology > > a) Please review the following terms for capitalization and let us know which > form you prefer (uppercase or lowercase) for consistency. > > Data-Security vs. data-security > [Note: Only two instances of "data-security" are lowercase; > should they be uppercase?] Please keep them as is - these occurrences are not related to SA, but to keys and to subsystem. I think it is OK that they are lowercase. > Group Member vs. group member > Group Receiver vs. group receiver > Group Sender vs. group sender For these please use lowercase form (unless in captions or when abbreviation is expanded). > Group-wide policy vs. group-wide policy I believe the current usage of this term is correct - uppercase form is used when abbreviation is given, otherwise lowercase form is used. > GSA registration exchange vs. GSA_REGISTRATION exchange It's OK, the former is just a clarification of the purpose of exchange, the latter is an IANA-given name of this exchange. > Header vs. header (when referring to specific headers, e.g., Payload Header > vs. IKE header) Please use lowercase form (unless it is "Authentication Header" where it must be uppercase). > Key Bag vs. key bag I believe the current use of this term is mostly correct - lowercase form is used unless this is a name of some structure (like Group Key Bag), in which case an uppercase form is used. There is one place that violates this rule, please correct. Section 4.5: CURRENT: Key Bags (variable): A set of Key Bag substructures. NEW: Key Bags (variable): A set of key bag substructures. > Key information vs. key information Please use lowercase form everywhere. > Key Wrap Algorithm vs. key wrap algorithm I believe the current use is correct - uppercase form is used only as a name of corresponding transform, otherwise lowercase form is used. > Notify Message vs. Notify message vs. notify message Please, make the following changes: Section 4.7 CURRENT: There are additional Notify Message types introduced by G-IKEv2 to communicate error conditions and status (see Section 9). NEW: There are additional Notify Message types introduced by G-IKEv2 to communicate error conditions and status (see Section 9). Section 2.3.3 CURRENT: A GM intending to emit data traffic MUST send a GROUP_SENDER Notify message type. NEW: A GM intending to emit data traffic MUST send a GROUP_SENDER notification. Section 2.3.4 (3 instances) CURRENT: If the GCKS fails to authorize the GM, it responds with an AUTHORIZATION_FAILED Notify message type. The GCKS may also respond with an INVALID_GROUP_ID notify message if the requested group is unknown to the GCKS or with an REGISTRATION_FAILED notify message if there is a problem with the requested group (e.g., if the capacity of the group is exceeded). NEW: If the GCKS fails to authorize the GM, it responds with an AUTHORIZATION_FAILED notification. The GCKS may also respond with an INVALID_GROUP_ID notification if the requested group is unknown to the GCKS or with an REGISTRATION_FAILED notification if there is a problem with the requested group (e.g., if the capacity of the group is exceeded). (all to be aligned with RFC 7296, which mostly use "notification") > Security Association vs. security association Please use only uppercase form (as per RFC 7296). > [Note: should the security association policy be uppercase > (e.g., "Security Association policy")? Yes. > Transform(s) vs. transform(s) > Transform ID vs. transform ID These are related. Please use "Transform Type(s)" and "Transform ID(s)" (all in uppercase), but "transform(s)" (lowercase) otherwise. There seems to be quite a lot of changes, sorry :-( > b) We note that the following terms are used inconsistently. Please review and > let us know which form you prefer to use throughout the document. > > Data-Security GSA TEK vs. GSA TEK vs. Data-Security SA policy (GSA TEK) > [Note: Are any of these terms the same?] > > group key management vs. group key management protocol > > Multicast Security (MSEC) Group Key Management Architecture vs. > Multicast Security (MSEC) key management architecture > > > c) FYI: We updated the text to reflect the forms on the right for consistency. > Please let us know of any objections. > > G-IKEv2 Rekey -> G-IKEv2 rekey > GKCS -> GCKS > group key bag -> Group Key Bag > group security association -> Group Security Association > GSA Policy -> GSA policy= > IKEv2 Intermediate exchange -> IKEv2 Intermediate Exchange (per RFC 9242) > member Key Bag and member key bag -> Member Key Bag > NO_PROPOSAL_CHOSEN Notification -> NO_PROPOSAL_CHOSEN notification > protocol ID -> Protocol ID > Rekey message -> rekey message > rekey SA -> Rekey SA > Security Association Payload -> Security Association payload (per RFC 7296) > Secure Password authentication -> secure password authentication (per RFC > 6467) > --> OK, thank you. > 38) <!-- [rfced] Some figures and tables were updated during the > formatting process and do not have titles. Would you like to add > titles to the figures and tables below for consistency throughout > the document? If so, please let us know the desired text. > > Current: > Figure 10 > Figure 15 I think that numbering of these figures is not needed. In RFC 7296 similar figures (Sections 2.14, 2.15) are not numbered. > Figure 16 > Figure 24 > Figure 27 This figures have titles. I believe they are listed here by mistake. Figure 23 has no title. Please add the following title: NEW: Figure 23: Example of a KD Payload Figure 26 has no title. Please add the following title: NEW: Figure 26: Key Paths for all GMs Figure 30 has no title. Please add the following title: NEW: Figure 30: Key Paths for all GMs after Exclusion of a GM > Figure 31 Figure 31 is missing in the document. I believe it is listed here by mistake. > Tables 3-8 For Table 3 add the following title: NEW: Table 3: Group Controller Authentication Method Transform IDs For Table 4 add the following title: NEW: Table 4: Key Wrap Algorithm Transform IDs For Table 5 add the following title: NEW: Table 5: GSA Attributes For Table 6 add the following title: NEW: Table 6: GW Policy Attributes For Table 7 add the following title: NEW: Table 7: Group Key Bag attributes For Table 8 add the following title: NEW: Table 8: Member Key Bag attributes > Tables 11-25 I don't think these tables need titles. Looking at recent RFCs in IPsecME WG, all tables in IANA considerations are untitled. I'd rather they don't have numbers too, but as far as I know this is unavoidable for tables with the current xml2rfc version :-) > --> > 39) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature typically > result in more precise language, which is helpful for readers. > > For example, please consider whether the term "man-in-the-middle" should be > updated. --> I believe we can use "person-in-the-middle" instead. I failed to find other issues with inclusive language guide in the text. I also have some issues. 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). 41) A typo in Appendix A.3: CURRENT: If the GCKS performs a simple SA rekey without changing group membership, it will only send a Group Key Gag in the KD payload with a new SA key encrypted with the default KWK. NEW: If the GCKS performs a simple SA rekey without changing group membership, it will only send a Group Key Bag in the KD payload with a new SA key encrypted with the default KWK. (should be "Key Bag" instead of "Key Gag"). 42) The draft incorrectly calls the GSA_REKEY pseudo-exchange as "GSA_REKEY exchange" in few places. This is the result of careless editing from my side, this is better to fix: a) Section 4.5.2 CURRENT: (*): Multiple SA_KEY attributes may only appear for the GIKE_UPDATE protocol in the GSA_REKEY exchange if the GCKS uses the group key management method that allows excluding GMs from the group (like LKH). NEW: (*): Multiple SA_KEY attributes may only appear for the GIKE_UPDATE protocol in the GSA_REKEY pseudo-exchange if the GCKS uses the group key management method that allows excluding GMs from the group (like LKH). b) Section 4.5.2 CURRENT: In the GSA_REKEY exchange, at least one SA_KEY attribute MUST be present, and more attributes MAY be present (depending on the key management method employed by the GCKS). NEW: In the GSA_REKEY pseudo-exchange, at least one SA_KEY attribute MUST be present, and more attributes MAY be present (depending on the key management method employed by the GCKS). c) Section 4.5.3.3 CURRENT: This attribute MUST NOT appear in the rekey operations (in the GSA_REKEY or GSA_INBAND_REKEY exchanges). NEW: This attribute MUST NOT appear in the rekey operations (in the GSA_REKEY pseudo-exchange or in the GSA_INBAND_REKEY exchange). d) Section 5 (see also item 32) CURRENT: (2): For a Data-Security SA, exactly one SA_KEY attribute MUST be present. For a Rekey SA, one SA_KEY attribute MUST be present in all cases and more these attributes MAY be present in a GSA_REKEY exchange. NEW: (2): For a Data-Security SA, exactly one SA_KEY attribute MUST be present. For a Rekey SA, one SA_KEY attribute MUST be present in all cases and more these attributes MAY be present in a GSA_REKEY pseudo-exchange. e) Section 5 CURRENT: The AUTH_KEY attribute MUST be present in the GSA_REKEY exchange if the GCKS employs an authentication method based on digital signatures and wants to change the public key for the following multicast rekey operations. NEW: The AUTH_KEY attribute MUST be present in the GSA_REKEY pseudo-exchange if the GCKS employs an authentication method based on digital signatures and wants to change the public key for the following multicast rekey operations. 43) Section 1, typo, missing hyphen in "pseudo-exchange". CURRENT: Refreshing the group keys can be performed either in a unicast mode via the GSA_INBAND_REKEY exchange (Section 2.4.2) performed over a specific IKE SA between a GM and a GCKS or in a multicast mode with the GSA_REKEY pseudo exchange (Section 2.4.1) when new keys are being distributed to all GMs. NEW: Refreshing the group keys can be performed either in a unicast mode via the GSA_INBAND_REKEY exchange (Section 2.4.2) performed over a specific IKE SA between a GM and a GCKS or in a multicast mode with the GSA_REKEY pseudo-exchange (Section 2.4.1) when new keys are being distributed to all GMs. 44) Please change "Generic Payload" to "generic payload" (make lowercase) to match RFC 7296 (2 instances in the document - in Sections 4.4 and 4.5). 45) Please change "Payload Header" to "payload header" (make lowercase) to match RFC 7296 (1 instance in Section 2.4.1.1.) 46) Section 4.4 CURRENT: The GSA payload is used by the GCKS to assert security attributes for both Rekey and Data-Security SAs. NEW: The Group Security Association (GSA) payload is used by the GCKS to assert security attributes for both Rekey and Data-Security SAs. 47) Section 4.4 CURRENT: The Security Association payload fields are defined as follows: NEW: The Group Security Association payload fields are defined as follows: 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). 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]
