Skip to main content

Last Call Review of draft-ietf-ipsecme-ikev2-multiple-ke-07

Request Review of draft-ietf-ipsecme-ikev2-multiple-ke
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-10-24
Requested 2022-10-10
Authors C. Tjhai , M. Tomlinson , G. Bartlett , Scott Fluhrer , Daniel Van Geest , Oscar Garcia-Morchon , Valery Smyslov
I-D last updated 2022-10-14
Completed reviews Dnsdir Last Call review of -07 by Geoff Huston (diff)
Genart Last Call review of -07 by Russ Housley (diff)
Artart Last Call review of -08 by Russ Housley (diff)
Secdir Telechat review of -10 by Sean Turner (diff)
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-ipsecme-ikev2-multiple-ke by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 07 (document currently at 12)
Result Almost ready
Completed 2022-10-14
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

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.


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)

I did not review the Appendix.