Hi Guilin,
Dear Valery,
Thanks for your questions on our draft IKEv2 with FrodoKEM.
You mentioned to better use TCP, but IPsec seems mainly used in the
scenarios with UDP.
RFC 9329 defines how to use TCP as a transport for IKE and ESP.
This RFC was developed to cope with situations when UDP is blocked,
but using TCP may also help to deal with lossy networks in case you
have
to exchange large IKE messages (e.g. with FrodoKEM).
The disadvantage of using TCP for IKE is that in this case ESP is
also
encapsulated in TCP, that results in performance degradation
(see RFC 9329 for discussion).
A possible solution may be decoupling IKE and ESP transport,
as defined in draft-smyslov-ipsecme-ikev2-reliable-transport.
In this case IKE is run over TCP and ESP continues
to be run directly over IP (or over UDP). However,
this is an individual draft not yet much discussed in the WG.
You also mentioned something is "wrong", but I did not get the point.
Could you please explain this further?
I recall, that this remark was addressed to Paul W., who
previously mentioned that with IKE fragmentation
fragments are individually acknowledged (which is a wrong).
Regards,
Valery.
Thanks a lot,
Guilin
From:Bruckert, Leonie <leonie.bruck...@secunet.com
<mailto:leonie.bruck...@secunet.com> >
To:Wang Guilin <wang.gui...@huawei.com <mailto:wang.gui...@huawei.com>
>;ipsec <ipsec@ietf.org <mailto:ipsec@ietf.org> >
Date:2024-11-06 10:41:21
Subject:AW: [IPsec] Comments regarding draft-wang-hybrid-kem-ikev2-frodo-02
Hi Guilin,
Thank you for your offer. I am looking forward to working together on this
draft.
Cheers,
Leonie
Von: Wang Guilin <wang.gui...@huawei.com>
Gesendet: Dienstag, 5. November 2024 15:06
An: Bruckert, Leonie <leonie.bruck...@secunet.com>; ipsec <ipsec@ietf.org>
Cc: Wang Guilin <wang.gui...@huawei.com>
Betreff: RE: [IPsec] Comments regarding draft-wang-hybrid-kem-ikev2-frodo-02
Hi, Leonie,
Thanks a lot for your detailed comments.
A little later, I will integrate them into a new version. I am happy to
invite you working together on the draft.
Cheers,
Guilin
_____
Wang Guilin
Mobile: +65-86920345
Mail: wang.gui...@huawei.com <mailto:wang.gui...@huawei.com>
From:Bruckert, Leonie <leonie.bruck...@secunet.com
<mailto:leonie.bruck...@secunet.com> >
To:ipsec <ipsec@ietf.org <mailto:ipsec@ietf.org> >
Date:2024-11-05 12:15:37
Subject:[IPsec] Comments regarding draft-wang-hybrid-kem-ikev2-frodo-02
I had a closer look at the Frodo draft. Please find my comments below.
Cheers,
Leonie
General comments:
- The terminology should be aligned throughout the whole document, e.g.
Frodo should be replaced by FrodoKEM.
- I would add one or two sentences to the introduction like "This document
uses the terminology defined in "Terminology for Post-Quantum Traditional
Hybrid Schemes."
- I am wondering if it is sufficient to refer to the upcoming ISO standard
or the public FrodoKEM specification document, respectively. Do we want or
need a FrodoKEM specification from cfrg?
- In general, I would recommend (but not require) to use FrodoKEM in
addition to the traditional key exchange, and also mention that it can be
used together with multiple PQ KEMs.
- I found lots of typos, which I tried to correct in my text proposals, but
there are probably some more.
Here are some specific comments mainly regarding abstract and introduction:
Abstract:
When RFC 9370 was written the main motivation was to do a PQC KEM in
addition to ECDH, but RFC 9370 does not require the first key exchange to be
ECDH. In principle, you could do a PQC KEM in the first exchange. So, I
would rewrite the Abstract (I also corrected a number of typos in the NEW
text), e.g.
--OLD--
RFC 9370 specifies a framework that supports mulitple key encapsulation
mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by
allowing up to 7 layers of additiona KEMs employed with the oringal ECDH to
derive the final shared secret keys for IPsec protocols. The primitive goal
is to mitigate the security threat against quantum computers by hybriding
additional post-quantum (PQ) KEMs with the orinigal ECDH key exchange. This
draft specifies how one QP KEMs, FrodoKEM, is instantiated in the IKEv2 as
the additional KEMs with the main ECDH to achieve hybrid key agreement.
--NEW--
"Multiple key exchanges in the Internet Key Exchange Protocol Version 2
(IKEv2) [RFC9370] specifies a framework that supports multiple key
encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol
Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to derive
the final shared secret keys for IPsec protocols. The primary goal is to
mitigate the "harvest now and decrypt later" threat posed by
cryptanalytically-relevant quantum computers. For this purpose, usually one
or more post-quantum KEMs are performed in addition to the traditional
(EC)DH key exchange. This draft specifies how the post-quantum KEM FrodoKEM
is instantiated in IKEv2 as an additional key exchange mechanism.
The link in the EDNOTE points to the wrong draft (terminology draft).
Introduction:
Some sentences are quite long and complex, so I tried to simplify a bit
(again correcting typos). Here are my suggestions:
--OLD--
To mitigate the security threats on key exchanges again quantum computers,
especialy the harvest-now-and-decrypt-later (HNDL) attack, the approach of
hybrid key encapsulation mechanisms (KEMs) has been proposed to achieve
secure key exchange if at least one of KEMs is still secure. In particular,
hybrid KEMs is supposed to be used in the scenarios where one or multiple
traditional KEMs are used together with one or multiple post-quantum KEMs [
<https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/>
I-D.D24]. The Internet Key Exchange Protocol Version 2 (IKEv2), which
sepecifies the key exchange procedures of IPSec, has to be updated for
quantum resistant security. For this purpose, RFC 9370 [
<https://www.rfc-editor.org/info/rfc9370> RFC9370] describes a framework to
hybrid mulitple key encapsulation mechanisms (KEMs), which extends the IKEv2
by allowing multiple key exchanges to take place for deriving shared secret
keys during a Security Association (SA) setup. Essentially, this
speficiation employs the IKE_INTERMEDIATE exchange, which is a new IKE
message introduced in [ <https://www.rfc-editor.org/info/rfc9242> RFC9242]
so that multiple key exchanges can be run to establish an IKE SA via
exchanging additional PQ public keys and ciphertexts between a client and a
server. RFC 9370 also introduces IKE_FOLLOWUP_KE, a new IKEv2 exchange for
realizing the same purpose when the IKE SA is being rekeyed or is creating
additional Child SAs.
--NEW--
Cryptographically-relevant quantum computers pose a threat to
cryptographically protected data. In particular, the so-called
harvest-now-and-decrypt-later (HNDL) attack is considered an imminent
threat. To mitigate this threat the concept of hybrid key encapsulation
mechanisms (KEMs) has been proposed to achieve secure key exchange if at
least one of the KEMs is still secure. "Multiple key exchanges in the
Internet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a
framework to perform hybrid key encapsulation in IKEv2 by allowing multiple
key exchanges to take place for deriving shared secret keys during a
Security Association (SA) setup. Essentially, this specification employs the
IKE_INTERMEDIATE exchange, which is a new IKEv2 message introduced in
"Intermediate Exchange in the Internet Key Exchange Protocol Version 2
(IKEv2)" [ <https://www.rfc-editor.org/info/rfc9242> RFC9242], so that
multiple key exchanges can be run to establish an IKE SA via exchanging
additional PQ public keys and ciphertexts between a client and a server. RFC
9370 also introduces IKE_FOLLOWUP_KE, a new IKEv2 exchange for realizing the
same purpose when the IKE SA is being rekeyed or additional Child SAs are
created.
--OLD--
However, RFC 9370 just specifies the framework of hybrid KEMS but it has not
been instantiated for concrete multiple KEMS. [
<https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/> I-D.KR24]
desribes how the framework given by RFC 9370 can be run with the
post-quantum (PQ) ML-KEM [
<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf> FIPS203],
previously called Kyber, which is the standard published by NIST in August
of 2024. However, on the one hand, FRC 9350 allows up to 7 layers of
additiona KEMs employed with the oringal ECDH to derive final shared secret
keys for the IKEv2. On the other hand, for some applications (e.g. financial
services) demanding high security level, additional PQ KEMs may be desired
for completing the hybrid KEMs for the IKEv2. Currently, ISO is now
standardizing three PQ KEM aglorithms: Kyber, FrodoKEM, and classic
McElliece. Note that Frodo [
<https://frodokem.org/files/FrodoKEM-standard_proposal-20230314.pdf> Frodo]
is unstructured lattice based KEM, whose security is more conservative
compared to ML-KEM, which is based on structured lattice. Therefore, this
draft is motivated to describe concretely how the frame of hybrid KEMs for
the IKEv2 specified in RFC 9370 can be run via hybriding the ogirinal ECDH
and FrodoKEM, even with ML-KEM together, if necessary.
--NEW--
However, RFC 9370 just specifies the framework of hybrid KEMS and has to be
been instantiated for concrete KEMS by separate documents. [
<https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/> I-D.KR24]
describes how the framework given by RFC 9370 can be run with the ML-KEM [
<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf> FIPS203],
previously called Kyber. which has been standardized by NIST in August 2024.
However, on the one hand, RFC 9350 allows up to 7 layers of additional KEMs
to derive final shared secret keys for the IKEv2. On the other hand, for
some applications (e.g. financial services) demanding high security level,
additional PQ KEMs may be desired for use with RFC 9370. Currently, ISO is
standardizing three PQ KEM algorithms (EDNOTE: we may want to change the
wording since the ISO standard will be finished eventually): Kyber,
FrodoKEM, and Classic McEliece. Note that FrodoKEM [
<https://frodokem.org/files/FrodoKEM-standard_proposal-20230314.pdf> Frodo]
is unstructured lattice based KEM, whose security is more conservative
compared to ML-KEM, which is based on structured lattice. Therefore, this
draft is motivated to describe concretely how the frame of hybrid KEMs for
the IKEv2 specified in RFC 9370 can be instantiated with FrodoKEM. FrodoKEM
should be used together with a traditional key exchange mechanism such as
ECDH and in addition, may be used with further KEMs e.g. ML-KEM.
Further issues in introduction:
- Second bullet point: Add a reference for the break of SIKE
- typos in last paragraph: performace -> performance, triger -> trigger
More typos:
- section 3, last paragraph:
stardandization -> standardization
performace -> performance
showen -> shown
roughtly -> roughly
triger -> trigger
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
