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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
