[Gen-art] Genart last call review of draft-ietf-ipsecme-ikev2-multiple-ke-07

[Russ Housley via Datatracker <[e-mail]>]

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ipsecme-ikev2-multiple-ke-07
Reviewer: Russ Housley
Review Date: 2022-10-14
IETF LC End Date: 2022-10-24
IESG Telechat date: unknown


Summary: Almost Ready


Major Concerns: None


Minor Concerns:

Section 1.2 says:

   The secrets established from each key exchange are combined in a way
   such that should the post-quantum secrets not be present, the derived
   shared secret is equivalent to that of the standard IKEv2; on the
   other hand, a post-quantum shared secret is obtained if both
   classical and post-quantum key exchange data are present.

What is "post-quantum key exchange data"?

I am not sure what this is is really trying to tell me.  I think it is
trying to make three points.  First, the shared secret is based on all of
the key exchange mechanisms that are employed.  Second, when one
traditional key exchange mechanism is employed, the result is compatible
with IKEv2 as it is used today.  Third, the result is post-quantum safe,
when classical and a post-quantum key exchange mechanisms are used
together.  Please reword to be more clear.  Further, I suggest that
the discussion of Child SAs be in a separate paragraph.

Section 1.2 says:

   The IKE SK_* values are updated after each exchange, and so
   the final IKE SA keys depend on all the key exchanges, hence they are
   secure if any of the key exchanges are secure.

I wondered what was meant by "secure", then I learned the answer in
Section 2.  I think a forward pointer will help future readers.

Section 3.1 says:

   Note that this document assumes, that each key exchange method
   requires one round trip and consumes exactly one IKE_INTERMEDIATE
   exchange.  This assumption is valid for all classic key exchange
   methods defined so far and for all post-quantum methods currently
   known.  For hypothetical future key exchange methods requiring
   multiple round trips to complete, a separate document should define
   how such methods are split into several IKE_INTERMEDIATE exchanges.
   
I suggest this go much earlier in Section 3.1.  It really is a very
basic design constraint.


Nits:

Section 3.1: s/IKE; however, that can/IKE; however, IKE_INIT messages can/

Section 3.2.2 says:

   (derived from the previous IKE_INTERMEDIATE
   exchange, or the IKE_SA_INIT if there have not already been any
   IKE_INTERMEDIATE exchanges)

I suggest:

   (derived IKE_SA_INIT for the first use of IKE_INTERMEDIATE,
   otherwise from the previous IKE_INTERMEDIATE exchange)


Note:
   
I did not review the Appendix.