Re: [IPsec] Review of draft-kampanakis-ml-kem-ikev2-02

[Daniel Van Geest <[e-mail]>]

Hi John, Scott,

 

RFC 4739 (experimental) defines multiple authentication in IKEv2: https://datatracker.ietf.org/doc/html/rfc4739.  It allows for mixed authentication types (e.g. EAP/certificates) and also multiple certificates.

 

https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/ takes RFC 4739 into consideration.  If multiple SUPPORTED_AUTH_METHODS notifications are sent, each notification contains methods appropriate for each authentication round.  This was a late addition to the draft, so additional thought on that may be needed.

 

Depending on the security requirements, these two in combination may not be sufficient. E.g. if one of the authentication algorithms is broken it may be possible to strip off the other algorithm since neither the number nor types of authentication is committed to during IKE_SA_INIT, the capability is simply announced.

 

Daniel

 

 

 

 

From: IPsec <[e-mail]> On Behalf Of John Mattsson
Sent: Monday, March 4, 2024 10:10 AM
To: Scott Fluhrer (sfluhrer) <sfluhrer=[e-mail]>; [e-mail]
Subject: Re: [IPsec] Review of draft-kampanakis-ml-kem-ikev2-02

 

Hi Scott,

                Scott Fluhrer wrote:

*         Transition – I believe (and do correct me if I’m wrong) that in IKE each side just sends over its certificate and auth payload and assumes that the peer knows how to handle them.  We need to do something better if we need for updated sites to work with nonupgraded ones.  One thing that’s in TLS 1.2 is the client provides a list of “which signatures I understand” (the signature_algorithms extension in the client hello).  In TLS 1.3, they extended it to include a list of “which signatures can appear in a cert chain”.  Using something similar in IKEv2 would appear to be one way to address the issue (of course, the details would need to be worked out – what’s in TLS might not be exactly what we need).  Or, does anyone else have other ideas?

 

Yes, this seems very good to discuss. I assume this has also been a problem in the past for systems upgrading from PSK to RSA to ECDSA. Seems like there is already an adopted draft that allows announcing supported authentication methods.

https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/

 

TLS 1.3 even has two extensions:
 
“The "signature_algorithms_cert" extension applies to signatures in certificates, and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages.
 
“If no "signature_algorithms_cert" extension is present, then the "signature_algorithms" extension also applies to signatures appearing in certificates.”
 
I don’t know how well that would map to IKEv2. Would ML-DSA be part of authentication method 14 (RFC 7427)?
 

*         Scott Fluhrer wrote:

*         Multiple authentication – there may be a desire to depend on multiple signature algorithms – that is, authentication would be secure unless both RSA and Dilithium are broken.  If we decide that this is something we want to support (and we may or may not decide to), there are several ways to do it (having both algorithms in a single certificate, or use multiple independent certificates, or even more generally, provide for multiple IKEv2 authentication methods in parallel).  This is of some controversy in the lamps working group, it might be good to hash out what makes sense for IKE.

 

I am personally not sure multiple signatures is needed for end-entity certificates with short life times. My understading is that the controversy in lamps was about hybrid keys and signatures in a singe certificate chain. I was not active in that discussion, but talking to some of my PKI people they do not like hybrid algorithms in certificates very much and would rather use two separate chains.

My feeling is that IPSECME should register ML-DSA in one standards track RFC. If people want multiple authentication, that can be done in a separate RFC just like RFC 9242, RFC 9370, and draft-kampanakis-ml-kem-ikev2 are independent.

 

Cheers,

John Preuß Mattsson

 

From: Scott Fluhrer (sfluhrer) <sfluhrer=[e-mail] <mailto:sfluhrer=[e-mail]> >
Date: Sunday, 3 March 2024 at 18:40
To: John Mattsson <[e-mail] <mailto:[e-mail]> >, [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Subject: RE: Review of draft-kampanakis-ml-kem-ikev2-02

I agree that it sounds like a good time to start work on postquantum IKEv2 authentication.  In addition to the lamps draft you cite, my list of items that need to be done (or at least considered) include:

 

*         Specifying the code points in the auth payload to mean “dilithium signature” (and I believe we need three for the three dilithium parameter sets); that’s the easy part.

*         While the draft FIPS 204 does not mention it, NIST has publicly pondered modifying the signature API to include a diversification string (e.g. is this a signature to authenticate IKEv2 vs one to authenticate TLS, for example), a flag whether this is a ‘prehash’ signature or not (that is, one where we hash the message and then sign the hash), and if it is, what hash function did we use. While it is not certain whether the final FIPS 204 will include them (I expect that it will), it might be good to consider which options we select should it include them.

*         Transition – I believe (and do correct me if I’m wrong) that in IKE each side just sends over its certificate and auth payload and assumes that the peer knows how to handle them.  We need to do something better if we need for updated sites to work with nonupgraded ones.  One thing that’s in TLS 1.2 is the client provides a list of “which signatures I understand” (the signature_algorithms extension in the client hello).  In TLS 1.3, they extended it to include a list of “which signatures can appear in a cert chain”.  Using something similar in IKEv2 would appear to be one way to address the issue (of course, the details would need to be worked out – what’s in TLS might not be exactly what we need).  Or, does anyone else have other ideas?

*         Multiple authentication – there may be a desire to depend on multiple signature algorithms – that is, authentication would be secure unless both RSA and Dilithium are broken.  If we decide that this is something we want to support (and we may or may not decide to), there are several ways to do it (having both algorithms in a single certificate, or use multiple independent certificates, or even more generally, provide for multiple IKEv2 authentication methods in parallel).  This is of some controversy in the lamps working group, it might be good to hash out what makes sense for IKE.

 

From: IPsec <[e-mail] <mailto:[e-mail]> > On Behalf Of John Mattsson
Sent: Sunday, March 3, 2024 3:35 AM
To: [e-mail] <mailto:[e-mail]> 
Subject: [IPsec] Review of draft-kampanakis-ml-kem-ikev2-02

 

Review of draft-kampanakis-ml-kem-ikev2-02

Hi,

 

I think IPSECME should adopt this draft asap. This should definitely be a standards track RFC.

 

I really like that IKEv2 register KEMs as separate code points and not hybrid code points like in TLS 1.3. I think the hybrid code points in TLS 1.3 might end up being a mess. It is also a good long-term solution, as long-term, people might want to use only a quantum-resistant KEM such as ML-KEM.

 

We would also like to be able to use ML-DSA for authentication in IKEv2. Is there any draft-xxx-ml-dsa-ikev2, otherwise it should be written asap. I am happy to help.

https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/

 

Comments of the draft:

 

- “Post-quantum”
 
I think the draft should remove “post-quantum” and only use the term “quantum-resistant”, this aligns with draft-ietf-lamps-dilithium-certificates, draft-gazdag-x509-slhdsa, and CNSA 2.0. “Post-quantum” is quite a strange term as ML-KEM needs to be deployed way before CRQCs are built.

 

- “As post-quantum keys are usually larger than common network Maximum Transport Units (MTU)“

 

“usually” depends on your sample of algorithms and security categories. As the ciphertext is not a key, I think it would be good to talk about encapsulation keys and ciphertexts, which aligns with FIPS 203. The encapsulation keys and ciphertexts in ML-KEM-512 and ML-KEM-768 are smaller than the typical Internet MTU. Also, it is the packet size carrying the encapsulation key or ciphertext that matters, not just the key ciphertext sizes themselves.

 

- “ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts can exceed typical network MTUs (1500 bytes).

 

ML-KEM-768 encapsulation keys and ciphertexts are smaller than 1500 bytes. The word "can" is weird as the sizes are fixed. Should probably talk about packets.

 

- “Thus, ML-KEM-1024 Key Exchange Method identifier TBD37 SHOULD only be used in IKE_INTERMEDIATE exchanges.  It SHOULD NOT be used in IKE_FOLLOWUP_KE messages until there is a separate document which defines how such exchanges are split in several messages.”

 

I think this should be rewritten to say that ML-KEM-1024 should only be used in IKE_SA_INIT when it is known that the network MTU is large. There is no reason to discourage use of ML-KEM-1024 in networks that use 9000 bytes ethernet jumbo frames.

 

- “which generates a public key 'pk' and a secret key 'sk'.”
 
I think the document should align with FIPS 203, which calls them encapsulation key and decapsulation key.
 
- “Otherwise keep a normative reference of [FIPS203].”
 
I think FIPS203 should be the normative reference no matter what.
 
- " which will not have material performance impact on IKEv2/IPsec tunnels which usually stay up for long periods of time."
 
Not sure that long-lived tunnels are so relevant as best practice is to rekey with PFS based on both time and data (ANSSI says 1 hour or 100 GB).
https://cyber.gouv.fr/sites/default/files/2015/09/NT_IPsec_EN.pdf <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-95d074f1e17afe43&q=1&e=30ba9ee6-2c65-4802-93bf-168b293e474c&u=https%3A%2F%2Fcyber.gouv.fr%2Fsites%2Fdefault%2Ffiles%2F2015%2F09%2FNT_IPsec_EN.pdf> 
 
I think the document should stress how fast ML-KEM is. On a single core AMD Ryzen 5 5560U [17], a mobile CPU from 2021, the cryptographic operations in ML-KEM takes 12 μs for the initiator and 8 μs for the responder. The key generation can be pre-computed, reducing the time required for real-time cryptographic operations to 6 μs for the initiator and 8 μs for the responder.
https://bench.cr.yp.to/results-kem.html <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-84e6e00fe0aa2d3c&q=1&e=30ba9ee6-2c65-4802-93bf-168b293e474c&u=https%3A%2F%2Fbench.cr.yp.to%2Fresults-kem.html> 
  
- “Consider adding ML-KEM-512 which would fit in one packet.”
 
I strongly think this document should just register all variant in FIPS 203. NIST latest assessment is that “the most plausible values for the practical security of Kyber512 against known attacks are significantly higher than that of AES128”. Ericsson agrees with that assessment and so do Sophie Schmieg (Google).
https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/faq/Kyber-512-FAQ.pdf
https://keymaterial.net/2023/11/18/kyber512s-security-level/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-932138c3cd478641&q=1&e=30ba9ee6-2c65-4802-93bf-168b293e474c&u=https%3A%2F%2Fkeymaterial.net%2F2023%2F11%2F18%2Fkyber512s-security-level%2F> 
 
- “The ML-KEM-768 public key is 1184 bytes”
 
I think it would be good with a table that shows the encapsulation key and ciphertext sizes for ML-KEM-512, ML-KEM-768, and ML-KEM-1024.
 
- “Although ML-KEM is IND-CCA2 secure, reusing the same ML-KEM keypair does not offer forward secrecy.”
 
I strongly think IPsec should continue to use the term "perfect forward secrecy", this aligns with RFC 4949, RFC 7296 and most government documents talking about ephemeral key exchange in IKEv2. The TLS 1.3 use of "forward secrecy" for both ephemeral key exchange and symmetric ratcheting has had the unfortunate result that people think they get the same security properties from both, which is absolutely not the case.
 
- “The initiator should generate a new ML-KEM keypair with every ML-KEM key exchange.”
 
I think this should be a MUST. On a single core AMD Ryzen 5 5560U [17], a mobile CPU from 2021, key generation with ML-KEM-512 takes the initiator 6 microsecond. Reuse was needed with the very slow FFDH key exchange on old CPUs of the past. Forbidding reuse significantly simplifies the security analysis.

 

Cheers,

John Preuß Mattsson