Hi Valery, I think the property I'm describing is slightly different, but the difference may not matter for most purposes.
By "binding to the protocol context" I mean, at the point at which SKEYSEED(1) is derived, the initiator and responder only derive the same SKEYSEED(1) if they have a consistent view of what messages were exchanged so far. In IKEv2, they might compute the same SKEYSEED(1) even if they don't agree on the transcript. Of course, as you pointed out, this doesn't seem to matter for authenticated key exchange as long as they eventually confirm they have a consistent view of the protocol transcript (e.g., by signing or MACing it). To be clear, I'm not criticizing the design at all, I'm just curious about how the WG landed on this design. Perhaps it's historical? Chris P. On Sun, May 18, 2025 at 11:40 PM Valery Smyslov <smyslov.i...@gmail.com> wrote: > Hi Chris, > > > > Hi all, > > > > I'm reviewing draft-ietf-ipsecme-ikev2-mlkem-00 [1] and had a few > questions about its hybrid security. Forgive me if this concern has already > been raised and addressed, as I'm new to this mailing list. I briefly > searched the archive and didn't find a related thread. > > > > Suppose we do ECDH for the initial key exchange and ML-KEM for the first > intermediate key exchange. I understand the key exchange to work roughly as > follows. > > > > The key exchange involves the following values: > > - Ni // Initiator's nonce > > - Nr // Responder's nonce > > - SPIi // Initiator's SPI > > - SPIr // Responder's SPI > > - KEi(0) // Initiator's ECDH key share > > - KEr(0) // Responder's ECH key share > > - KEi(1) // ML-KEM public key > > - KEr(1) // ML-KEM ciphertext > > > > The key schedule is as follows: > > 1. KEi(0) and KEr(0) are combined to form shared secret SK(0) > > 2. SKEYSEED(0) is derived from prf(Ni | Nr, SK(0)) > > 3. SK_d(0) is derived from prf+ (SKEYSEED(0), Ni | Nr | SPIi | SPIr ) > > 4. KEi(1) and KEr(1) are combined to form shared secret SK(1) > > 5. SKEYSEED(1) is derived from prf(SK_d(0), SK(1) | Ni | Nr) > > > > Finally, SKEYSEED(1) is used to derive session keys or to carry out > another intermediate key exchange. Do I understand this right? > > > > Yes. > > > > This is similar to what TLS 1.3 does [2]: session keys are derived by > mixing the shared secrets SK(0), SK(1) and binding them to some protocol > context Ni, Nr, SPIi, SPIr. However, there is an important difference: in > TLS 1.3, the protocol context includes the ECDH key shares and the ML-KEM > public key and ciphertext; in IKEv2, the protocol context does not include > these values. > > > > This difference is interesting when we think of the key schedule as a "KEM > combiner" [3]. In TLS 1.3, the combiner binds the key to the ECDH key > shares and ML-KEM public key and ciphertext; in IKEv2, the combiner does > not. This means the combiner is not robust [4], meaning a weakness in ECDH > or ML-KEM could imply a weakness in the hybrid KEM. > > > > Of course, whether this is a problem for IKEv2 depends on what properties > of the combiner are needed for the security of the protocol. The draft > cites a proof of IND-CPA security for the combiner, thus we'd need to be > able to prove IKEv2 secure based on the assumption that one of ECDH or > ML-KEM is IND-CPA. Do I understand that right? > > > > Assuming I've got this all correct, I'd be curious to know if this working > group considered whether or not to bind the key to the key exchange > messages. On the one hand, it seems like doing so would require changing > the IKEv2 key schedule, which is probably undesirable. On the other hand, > it might be useful for proving stronger-than-usual security properties of > IKEv2, even if it's not strictly necessary for authenticated key exchange. > > > > Unless I’m missing your point, I believe that the binding of > shared secrets to the protocol context > > in IKEv2 is done via the way the content of the AUTH payload is > calculated. > > > > For pure IKEv2 (RFC 7296 Section 2.15) for initiator: > > > > BLOBi = MSGi | Nr | prf(SKpi, IDi) > > > > where MSGi – initiator’s IKE_SA_INIT message (includes > initiator’s ECDH key share) > > SKpi is derived from SKEYSEED > > > > > > In the case of hybrid key exchange ECDN+ML-KEM (RFC 9242, > Section 3.3.2) for initiator: > > > > BLOBi = MSGi | Nr | prf(SKpi(1), IDi) | prf(SKpi(0), INTi) | prf( > SKpr(0), INTr) | 2 > > > > where MSGi - initiator’s IKE_SA_INIT message (includes > initiator’s ECDH key share) > > SKpi(1) – derived from SKEYSEED(1) > > INTi – initiator’s IKE_INTERMEDIATE message before its > encryption (includes initiator’s ML-KEM public key), > > INTr – responder’s IKE_INTERMEDIATE message before its > encryption (includes ML-KEM ciphertext), > > SKpi(0), SKpr(0) – derived from SKEYSEED(0) > > > > > > BLOBi is then signed or MACed, which in my understanding > provides the necessary binding of the keys to the IKEv2 context. > > > > Regards, > > Valery. > > > > On an unrelated note, I'm curious about the language around input > validation in > https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-mlkem-00.html#section-2.3. > Namely, why use SHOULD instead of MUST for validating inputs? > > > > Thanks, > > Chris P. > > > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ > > [2] https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ > > [3] https://datatracker.ietf.org/doc/draft-irtf-cfrg-hybrid-kems/ > > [4] https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design/ >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
