Hi Tero,
I think you are doing this wrong. There is no need to change the
SKEYSEED calculation. That only prototects the IKE SA encryption,
authentication keys. It would be much better to change the KEYMAT
calculation only, and keep the SKEYSEED calculation as it is now.
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.
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.
Thus it completely eliminates the IKEv2 property of protecting
identities against passive attackers.
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. 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. 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.
This also gets rid of the complicated PPK_REQUEST and PPK_ACK from the
IKE_SA_INIT.
I don't think it's prohibitevly complex.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
