Re: [Last-Call] Genart last call review of draft-ietf-ipsecme-ikev2-multiple-ke-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Russ,

Many thanks for the review of our document. Please see our comments inline below. The updated version of the draft is available here: https://github.com/post-quantum/ietf-pq-ikev2/blob/master/draft-ietf-ipsecme-ikev2-multiple-ke-00.xml

Best regards,
CJ and Valery

On Fri, 14 Oct 2022 at 20:24, Russ Housley via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Russ Housley
Review result: Almost Ready

[ snip ] 
 
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.


We have changed that paragraph to the following:

   IKE peers perform multiple successive key exchanges to establish an
   IKE Security Association (SA).  Each exchange produces a piece of
   secret and these secrets are combined in a way such that:

   (a)  the final shared secret is computed from all of the component
        key exchange secret;

   (b)  the shared secret as specified in [RFC7296] is obtained unless
        both peers support and agree to use the additional key exchanges
        introduced in this specification; and

   (c)  if any of the component key exchange method is a post-quantum
        algorithm, the final shared secret is post-quantum secure.

 
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.


Yep, good idea. We have added a forward pointer to Section 3.2.2.
 
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.


Agreed. We have moved this paragraph further up in Section 3.1.
 

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)


Thanks, we have changed them accordingly.
  

Note:

I did not review the Appendix.





PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited company incorporated in England and Wales with registered number 06808505.
 
This email is meant only for the intended recipient. If you have received this email in error, any review, use, dissemination, distribution, or copying of this email is strictly prohibited. Please notify us immediately of the error by return email and please delete this message from your system. Thank you in advance for your cooperation.

For more information about Post-Quantum, please visit www.post-quantum.com.

In the course of our business relationship, we may collect, store and transfer information about you. Please see our privacy 
notice at www.post-quantum.com/privacy-policy/ to learn about how we use this information.
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux