Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[Roman Danyliw <[e-mail]>]

Hi!

Thanks for the explanation and the revised text in -07.  I’m advancing the document to IETF LC.

I have a few replies to consider with any additional IETF LC feedback.

From: CJ Tjhai <[e-mail]>
Sent: Tuesday, October 4, 2022 9:05 PM
To: Roman Danyliw <[e-mail]>
Cc: Valery Smyslov <[e-mail]>; [e-mail]
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

[snip]

On Fri, 30 Sept 2022 at 23:20, Roman Danyliw <[e-mail]<mailto:[e-mail]>> wrote:

[snip]
** Section 2

Federal Information Processing Standards (FIPS) compliance.
        IPsec is widely used in Federal Information Systems and FIPS
        certification is an important requirement.  However, algorithms
        that are believed to be post-quantum are not FIPS compliant yet.
        Still, the goal is that the overall hybrid post-quantum IKEv2
        design can be FIPS compliant.

What kind of coordination was done to ensure that this design is FIPS compliant?  Do we have a read if it is?

See NIST PQC FAQs (Transition and Migration section): https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs

Are multiple classic (EC)DH key exchanges FIPS compliant?

Based on the above FAQ, if at least one (EC)DH is FIPS complaint, we think that the overall exchange should be.

[Roman] Makes sense.  Thanks. To prevent this from coming up during subsequent reviews.  Please add a reference to that FAQ here.

[snip]
** Section 3.2.4.

The responder MUST handle this
   situation gracefully and delete the associated state if it does not
   receive the next expected IKE_FOLLOWUP_KE request after some
   reasonable period of time.

Is there a guidance on the timeout value?

IKEv2 traditionally does not mandate exact timeouts. For example, the same situation happens if the initiator completes IKE_SA_INIT and never starts IKE_AUTH. The responder should eventually delete the incomplete IKE SA, but RFC 7296 does not specify how long the waiting time is.

FWIW, our implementations waits 5 seconds by default (which is adjustable value).

Do you think we should recommend (but not mandate) to wait for 5-10 seconds?

[Roman] A recommended value would help if you are comfortable giving it, or explaining why it’s hard to give one.  This is a common question that comes from transport review during IETC LC or IESG review.


[snip]

** Section 5.  Is there any significance to the order of the KEs?  Does 4096-bit MODP Group then PQ_KEM1 yield anything different than the reverse?  Should the classic KEM come before the PQC one(s)?

In order to avoid potential fragmentation issue, KE payload should be small enough, so it may not be desirable to use PQ_KEM1 (assuming its public key/ciphertext is larger than 1.5KB) in the KE payload. So in general, we expect the KE payload to be used for (EC)DH and this will help in terms of backward compatibility. Ignoring this consideration, we think the ordering of the key exchange should not matter as we are only interested in the overall shared secret.

Having said that, we could also see that one could argue that it matters. Note that the "strength" of the running shared secret (assuming there is no issue on the random number generator used) increases with every new additional key exchange. So one may wish to first perform the most secure method (in some metrics) and then add less trusted one(s).

[Roman] Adding a bit of clarifying text like discussed here would be helpful – that the ordering does not matter.


** Section 5.

   Post-quantum authenticity
   may be provided by using a post-quantum digital signature and several
   of them have been being explored by IETF.  For example, if the
   implementation is able to reliably track state, the hash based
   method, XMSS has the status of an RFC, see [RFC8391].  Currently,
   post-quantum authentication methods are not specified in this
   document, but are planned to be incorporated in due course.

-- What activity in the IETF exploring PQ digital signatures?

There is this work on composite signatures: https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/
and an expired draft on the same subject but specific to IKEv2: https://datatracker.ietf.org/doc/draft-guthrie-ipsecme-ikev2-hybrid-auth/


-- Is using XMSS a recommendation?

Due to the need to keep states, we think XMSS may not be that suitable for IKEv2.

-- What is the planned due course referenced here?

We believe the document should focus on confidentiality. Supports for PQ digital signatures can be added as a separate document.

[Roman] Agreed. Consider if you need to talk about work that ISN’T done in this document here.  To keep things on point, I would recommend deleting this text.

Regards,
Roman