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

Hi Roman,

Many thanks for the review, really appreciate it. We will update our draft
and submit a revision soon.

Please see our response inline below.

Best wishes,
CJ and Valery

On Fri, 30 Sept 2022 at 23:20, Roman Danyliw <rdd@cert.org> wrote:

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

Just an extra to Andreas' response, the interop tests have been presented
in IETF meetings and the latest one was in 2021. The slides can be found
here:
https://datatracker.ietf.org/meeting/111/materials/slides-111-ipsecme-hybrid-ikev2-interoperability-testing-00

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

In terms of independent assessment, there is a paper on the formal proof
analysis of the extension introduced in the draft:
https://www.mnm-team.org/pub/Publikationen/gggh21b/PDF-Version/gggh21b.pdf

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

You have got a point here, they are similar. What if we change the design
criteria #1 to this:

   1)   Need for PQC in IPsec.  Quantum computers, which might become
        feasible in the near future, pose a threat to our classical
        public key cryptography.  PQC, a family of public key
        cryptography that is believed to be resistant against these
        computers, needs to be integrated into IPsec protocol suite to
        restore confidentiality and authenticity.

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

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

We would like to summarise the changes, in particular the change to the
field on the KE payload is not in Section 4. How about this?

This document renames a field in the Key Exchange Payload from
"Diffie-Hellman Group Num" to "Key Exchange Method".  It also renames
Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange
Method (KE)"; the corresponding renaming to the IANA registry is
described 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?
>

Yep, I think we should add some text on the IANA Considerations section. We
will add it in the next revision of the draft.

>
> ** 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".
>
>
The design criteria is as follows. The semantics of Additional Key Exchange
[1..7] transform types is different from the semantics of the other
transform types: actually they all indicate the same type of algorithm -
Key Exchange - (as well as Transform Type 4) and their purpose is only to
show the order in which these key exchanges should take place.

For this reason, it is difficult to incrementally add new such transform
types. Say, we define only two Additional Key Exchange transform types now
with a hope to add more when (and if) it is needed. In this case, when we
add the third Additional Key Exchange transform type, there could be some
implementations out there which support only the earlier two Additional Key
Exchange transform types. Per RFC7296, implementations must ignore
proposals with transforms types they do not understand, so these
implementations will ignore the whole proposal if it contains the newly
introduced Additional Key Exchange transform type, despite the fact that it
may contain algorithms that are supported. This will badly influence
interoperability.

So, in order to promote interoperability, we need to introduce these
transforms at once, in a single block. In this case, either implementations
do not understand them all (and thus do not support this specification) or
understand them all. Since we have only one chance to introduce these
transforms, their number should be high enough, so that we will not have a
shortage of them in the future.

The choice of 7 is a bit arbitrary. The main purpose of hybrid key exchange
is to combine key exchange methods based on different mathematical
principles. In the PQ world, we currently have lattice-based, code-based
and isogeny-based methods. We want for the extreme cases to be able to
support the combination of all of them. Furthermore, in order to cater for
the possibility of new methods based on different mathematical principles
appearing in a near future, we double the possible different PQ key
exchange hardness assumptions. That gives us 6, which is rounded to 7, that
along with Transform Type 4 will allow us to use up to 8 different KE
methods in an IKE SA, which is a nice value for programmers :-)

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

Good point. We could add this text:

In the event of duplicated algorithms in the initiator's message, the
responder MUST reject the message with an error notification of type
NO_PROPOSAL_CHOSEN.  On the other hand, if the responder's message
contains one or more duplicated choices, the initiator should log the
error and MUST stop creating the SA or delete the SA if it is a rekey.

>
> ** Section 3.2.1.  Why is there a need to support non-consecutive
> Additional Key Exchange transforms?
>
>
For flexibility. For example, some implementations may always associate
Additional Key Exchange 1 with code-based algorithms, Additional Key
Exchange 2 with lattice-based, etc. In this case, if their current policy
requires only using lattice-based methods, they will always skip Additional
Key Exchange 1 and propose only Additional Key Exchange 2.

If we allow non-consecutive Additional Key Exchanges, this simplified
implementations will have no interoperability problems with others.

> ** Section 3.2.1.  Editorial.  For clarity, recommend narrating the figure
> above.
>
>
Sorry, we are a little puzzled here. We thought that we had narrated all
the figures, for both initiator's and responder's proposals and the
IKE_SA_INIT exchange. Could you please be more specific on what we need to
do here?

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

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?

>
> ** 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."
>

Ok, replaced with:

It is also possible to establish IKE SAs with post-quantum
algorithms only using additional key exchanges, but without using
IKE_INTERMEDIATE exchanges.

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

Replaced with:

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

> -- If there is such a local policy, why wouldn't a quantum resistant KE be
> done in the initial IKE_SA_INIT?
>

A few points to note:
- It is unlikely to do key exchange with PQC algorithm in IKE_SA_INIT due
to the potential IP fragmentation caused by large public key size.
- If we assume that the IKE_INTERMEDIATE phase is part of IKE_SA_INIT, then
Section 3.2.5 was written to show that there is an alternative to using
IKE_INTERMEDIATE. There are two reasons for this:
a) there might be an implementation that does not support IKE_INTERMEDIATE;
b) In the IKE_INTERMEDIATE phase, the peers are not authenticated yet, so
peers may not want to exchange large data due to the potential DoS attacks.
The alternative is to use Childless IKE SA.

>
> ** 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
>
>
We have got the requested IANA values allocated already. So apologies, we
should have let you review the draft with the actual values rather than
TBAs.

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

Perhaps it should point to both RFC7296 and 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.
>

Thanks :-)

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

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

> ** 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
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

-- 

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 
<http://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/ 
<http://www.post-quantum.com/privacy-policy/> to learn about how we use 
this information.