I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-ipsecme-g-ikev2-17
Reviewer: Russ Housley
Review Date: 2024-11-27
IETF LC End Date: 2024-12-10
IESG Telechat date: Unknown

Summary: Not Ready


Major Concerns:

IKEv2 implementers that have no need for group security associations
are not likely to read this document.  For this reason, I think it is
unwise to include the updates to RFC 7296 here that:

(1) Rename transform type 5 from "Extended Sequence Numbers (ESN)" to
    "Anti-Replay Protection (ARP)"; and

(2) Rename IKEv2 authentication method 0 from "Reserved" to "NONE".

I find the use of GIKE_REKEY and GSA_REKEY a little bit confusing.
I think it would help the reader if these were discussed a bit in the
Introduction.  Figure 1 introduces GSA_REKEY, so perhaps, shortly
after that a brife explanation og GIKE_REKEY can be included.

Section 1.2: To my ears, KEK and KWK are the same thing.  Please add
more words sto make the distinction more clear.

Section 2:  Please move the last paragraph of Section 2.1 into this
empty section.  Also, a few words about what this section is going to
to cover would be helpful.

Section 2.1: It says: "G-IKEv2 is compatible with most IKEv2 extensions
defined so far."  This begs for a list of the ones that are not
compatible.  The pointer to Section 6 should appear right after this
statement.

Section 2.4.1.1: I am surprised that the "ICV is computed using the
current KEK keys".  Two things surprise me.  First, I think there is
only one "current KEK" at a time.  Second,  I expected the current
authentication key to be used for the ICV computation.

Section 2.4.2.1: The text talks about "GSA, KD, N and D" payloads.
However, Figure 11 does not show the use of a D payload.  Further,
Sections 2.3.3 and 2.3.4 do not talk about the D payload.

Section 2.4.2.2: The text talks about "GSA, KD, N and D" payloads.
However, Figure 11 does not show the use of a D payload.  Further,
Sections 2.3.3 and 2.3.4 do not talk about the D payload.

Section 4.5.3.2: DSS public keys should be phased out, so I discourage
the inclusion of DSS in this document.


Minor Concerns:

Section 4.5.4: Can the wrapped key be 94 bits?  It appears that the
payload is a number of octets, but no padding mechanism is described.
The text is unclear because it says: "These bits..."

Section 2.3.4: The 3third paragraph ends with: "Sender-ID values (see
Section 2.5)."  I think that it should be pointing to Section 2.5.1.

Section 2.7: There is a missing ")".  After reading several times, I am
not sure where it belongs.


Nits:

Section 2.3.4: s/otherwise - in tunnel/otherwise, SAs are created in tunnel/

Section 2.4.1.1: s/Messages Authentication/Message Authentication/

Section 2.6: s/this transform/the Anti-Replay Protection transform/

Section 3.3: s/the wrapped keys are sent over/over which wrapped keys are sent/

Section 4.3: I suggest a rewording of the last sentence:

   The Payload Type for SAg payloads is thirty-three (33), which is
   identical to the SA Payload Type.

Section 4.4.2: s/section 3.13.1/Section 3.13.1/

Section 4.4.2.2.2: s/at the time of GMs' registration/when the GM is registered/

Section 4.5.1: s/the keys in the bag are for/associated with the keys in the bag/

Section 4.5.3.2: s/section 4.1.2.7/Section 4.1.2.7/

Section 8.2.1: s/unless in/unless used with/


Note:

I did not review the Appendix.

Optional payloads (for example: "[CERTREQ]") really confuse IDnits.
They appear to be references that are missing.  I'm not sure there is
anything to be done at this point, but you might be able to think of
a way to handle it.