Valery Smyslov writes: > > SKEYSEED is used to authenticate the other end and to attack that do > > require online attacks done during the IKE SA lifetime. Even if the > > attacker can break the encryption and MAC keys used for the IKE SA > > that will leak out the actual traffic transmitted over the IPsec SA. > > It does leak out the identities of the peers, but using active attacks > > those are visible anyways. > > Only one party's identity is visible, not both. > And active attacks are more complex and easier to detect.
The responder identity is usually quite static, as responders IP-address is usually static... If there are multiple responder IDs in the same IP-address, then initiator usually needs to tell which one of them he wants to connect using both IDi, and IDr in his IKE_AUTH request, and in that case the active attacker do get both identities. > > To make IPsec quantum computing safe, i.e. so that saved IPsec SA > > flows cannot be decrypted later when QC computers are available and > > which can break Diffie-Hellman used now, we just need to add the > > strong shared secret to the KEYMAT calculations. > > > > I.e. in addition to the g^ir (new) and nonces, we can add the PPK > > there: > > > > KEYMAT = prf+(SK_d, PPK | Ni | Nr) > > > > KEYMAT = prf+(SK_d, PPK | g^ir (new) | Ni | Nr) > > > > This way even if the attacker stores all the IKE and IPsec flows, and > > can then later break the DH used to protect the SKEYSEED, they will be > > able to decrypt the IKE SA, but the actual traffic is still protected > > as KEYMAT used to generate traffic keys contains PPK. > > I think this proposal is worse than presented in the draft. > It leaves information in the IKE SA vulnerable to QC-based attacks. And what information do you think is there that is really worth of protecting? My understanding is that when there really are attackers using QC-based attacks in real, we need to change the IKEv2 again, to make the authentication methods also protected against QC-based attacks. What we are solving now is the fact that someone can save all the IKEv2 / IPsec traffic now, and when they do get the quantum computers, they can break the Diffie-Hellman and then get the traffic keys used to protect the IPsec traffic. I.e. the saving of traffic happens now and breaking of the traffic happens much later. What information there are in the IKEv2 SA which is important to protect for that kind of attacks? > Thus it completely eliminates the IKEv2 property of protecting > identities against passive attackers. Yes. I think protecting the actual IPsec traffic is much more important than protecting the identities, especially as they are already vulnerable to the active attackers. Detecting active attackers is easier, but I still assume that quite a lot of implementations do retry silently if they do not get reply back to the IKE_AUTH, i.e., there is no big alerts at that time warning user that there might be active attacker on link, who just stole your ID. > Moreover, the way PPK is used in the draft is more clear and > easier to implement. Note, that the only difference between the crypto > formulas from RFC7296 and the draft is that every use of Nx (where x = [ir]) > is replaced with PRF(PPK | Nx). It is simple and modular from > implementer's point of view. The draft had all kind of talks about AES and SHA256, so I just assume that was there to confuse people and it is not needed? > Moreover, in this case the PPK is used as the key for PRF, while in > your proposal the PPK is used as additional data fetched into PRF. The reason I used that is that cryptographers who designed the IKEv2 did that same thing with the share secret output from the Diffie-Hellman, i.e., the g^ir. So I do assume that is safe, and if it not then we need some proper cryptographer to tell me why not. Also using the PPK as key to the PRF will limit the size of the PPK to match you PRF key length. Using it as a data is supposed to be better if I remember right why this method was selected for the IKEv2. Anyways I am not cryptographer, I just assume that the people who are and who said it is ok to do KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr) know what they were doing. > Using secret material (PPK) as a data is always a pain for the > products that maintain "security core", while using secret as a key > is simple and natural. But this what we do in IKEv2 for all cases, also the SKEYSEED is calculated in same way: SKEYSEED = prf(Ni | Nr, g^ir) I.e. the public values Ni and Nr are used as key, and the shared secret g^ir is used as data. If you think that is unsafe, I would like to get more information about that, as that would mean that we need to change the cryptographic protocol used in the IKEv2... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
