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

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06.  Thanks for the work on this document.

Per the shepherd write-up:

** Question 4

Several implementors have been integral in developing this document, thus 
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification.

Could these implementations be explicitly named?

** Question 5

No. The document has already been reviewed by security area people, and 
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received 
to the basic protocol.

With no disrespect intended to the expertise of the authors, what is the process used by the WG to review the robustness of the cryptographic mechanisms?  Was there an independent assessment beyond those on the author team?  Did the Crypto Panel have an independent look?

Now to the document:

** Section 1.2.  Editorial.

OLD
... is not limited to addressing the threat of
   quantum computer only.

NEW
... is not limited to only addressing the threat of a 
   quantum computer.

** Section 2.  Design Criteria #3

A passive attacker can
        eavesdrop on IPsec communication today and decrypt it once a
        quantum computer is available in the future.  This is a very
        serious attack for which we do not have a solution.  

Isn't this the same thing as design criteria #1?

** 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?

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

** Section 3.1

We assume that new Transform Type 4 identifiers will be assigned
   later to the various post-quantum key exchanges.

-- Please add reference to such as "[IANA-Type4-ID] https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8"

-- s/assigned later to the/assigned later for/

** Section 3.1.

   To be more specific,
   this document renames Transform Type 4 from "Diffie-Hellman Group
   (D-H)" to "Key Exchange Method (KE)" and renames a field in the Key
   Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange
   Method".  The corresponding IANA registry is also renamed from
   "Diffie-Hellman Group Transform IDs" to "Key Exchange Method
   Transform IDs".

Why repeat what is already spelled out more clearly in Section 4?

** Section 3.1.

   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.  

Is ensuring that a chosen algorithm fits into a single exchange now an additional criterial for the DE for adding anything into the Type 4 ID registry?  If so, should this be stated?

** Section 3.1.  Typo. s/splitted/split/

** Section 3.2.  Editorial.  Colloquial language.  s/the initiator is happy with/the initiator starts/

** Section 3.2.  Editorial.

OLD
   In this case, the initiator performs the IKE_SA_INIT as usual,
   inserting a preferred key exchange (which is possibly a post-quantum
   algorithm) as the listed Transform Type 4, and including the
   initiator KE payload.  

NEW
In this case, the initiator performs the IKE_SA_INIT for a single key exchange using a Transform Type 4 (possibly with a post-quantum algorithm), and including the initiator KE payload.

** Section 3.2.1.  s/uses the protocol listed below./uses the protocol behavior listed below./

** Section 3.2.1.  What is the basis for the design choice allow up to 8 (1 in the IKE_SA_INIT + 7 via the AKE) key exchanges?  I don't have an intuition on why 7 is "just right".

** Section 3.2.1.

   However, for the Additional
   Key Exchange types, the responder's choice MUST NOT contain
   duplicated algorithms, except for the transform ID of NONE.  

If an initiator gets are response with such duplicates, what error or follow-up action should be taken?  In reverse, what happens if an initiator sends a responder a combination of Additional Key Exchange which are duplicates?

** Section 3.2.1.  Why is there a need to support non-consecutive Additional Key Exchange transforms?

** Section 3.2.1.  Editorial.  For clarity, recommend narrating the figure above.

OLD

In this example, the initiator proposes to perform initial key
   exchange using 4096-bit MODP group followed by two mandatory
   additional key exchanges using PQ_KEM_1 and PQ_KEM_2 methods in any
   order, then followed by additional key exchange using PQ_KEM_3 method
   that may be omitted.

NEW
In this example, the initiator proposes to perform initial key    exchange using 4096-bit MODP group followed by two mandatory additional key exchanges (i.e., Transform AKE2 and AKE3) using PQ_KEM_1 and PQ_KEM_2 methods in any order, then followed by additional key exchange (i.e., Transform AKE5) using PQ_KEM_3 method that may be omitted.

** Section 3.2.4.  Typo. s/splitted/split/

** Section 3.2.4.  Editorial. s/Since after IKE SA/After the IKE SA/

** Section 3.2.4.  Editorial. s/is <TBA by IANA>,/ is <TBA by IANA>, and/

** 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?

** Section 3.2.5.

It is also possible to establish a fully post-quantum secure IKE SAs
   from additional key exchanges without using ...

Please soften the language "fully post-quantum secure."

** Section 3.2.5

   Consequently, if the peers' local policy requires that all Child SAs
   should be fully-protected, then the peers can avoid creating the very
   first Child SA by adopting [RFC6023].  

-- what does "fully protected" mean here?
-- If there is such a local policy, why wouldn't a quantum resistant KE be done in the initial IKE_SA_INIT?

** Section 4

-- Create sub-sections for each IANA registry being touched to help IANA parse these requests.  Merge the guidance in Section 4.1 into these sections.
-- Please explicitly state that [RFCXXXX] should be added as the associated reference.

** To make the request to IANA easier to process, please number the "TBAs" (i.e., TBA1, TBA2, TBA3, etc) in the inline document text.  Specifically:  

-- Section 3.2.1. TBA for AKE1 - 7
-- Section 3.2.3.  TBA for IKE_FOLLOWUP_KE
-- Section 3.2.4.  TBA for Notify Message Type
-- Section 3.2.4.  STATE_NOT_FOUND

** Section 4.

   This document renames Transform Type 4 defined in "Transform Type
   Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange
   Method (KE)".

Should the Reference value also point to this document?

** Section 5. Consider repeating the threat model voiced at the beginning of the document to contextual the subsequent text.  

NEW (roughly)

The extension in this document is intended to mitigate two possible threats in IKEv2 - the compromise of (EC)DH key exchange using Shor's algorithm while remaining backward compatible; and the potential compromise of existing or future PQC key exchange algorithms.  To address the former threat, this extension allows the establishment of a shared secret by using multiple key exchanges -- one classical and the other quantum resistant.  To address the latter threat, multiple quantum resistant algorithm key exchanges cane be composed to form the shared key.

** 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)?

** 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?

-- Is using XMSS a recommendation?

-- What is the planned due course referenced here?

** Appendix A.  Editorial.  To be explicit, s/are purely for information purposes/are non-normative/

** Appendix B. In the spirit of inclusive language, consider s/MitM/on-path/

Regards,
Roman