Scott Fluhrer (sfluhrer) writes:
> The reason they gave this advise was the IKEv1, unlike IKEv2,
> stirred in the preshared key into the KDF function (along with the
> (EC)DH shared secret); hence if the preshared key was strong, then
> Shor’s algorithm (which can recover the (EC)DH shared secret) is not
> enough to recover the negotiated keys.
The fact that IKEv1 stirred the preshared keys when generating the
keying material for the IKE SA encryption etc keys was the reason that
Main mode of the IKEv1 cannot be used in general case.
I.e. as in IKEv1 when using main mode and preshared keys the responder
needs to know the identity of the initiator based solely on the
IP-address, as it cannot decrypt the Identity payload before it knows
the pre shared keys.
This "feature" of the protocol is really bad, and we should not copy
anything like that to the IKEv2.
> Now, we don’t want people to migrate back to an obsolete version of
> the protocol; hence we’ve devised a way to strengthen IKEv2 the same
> way.
Agree.
> It was considered important to minimize the changes made to IKEv2.
> From a cryptographical prespective, the only change we make is that
> we modify the nonces that we present to the KDF. By keeping the
> cryptographical changes minimal, we reduce the risk of accidentally
> introducing a weakness.
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.
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.
This also gets rid of the complicated PPK_REQUEST and PPK_ACK from the
IKE_SA_INIT.
In this case the initiator just needs to indicate which PPK it will be
using (especially with the OOB PPK keys there might be one-time pad of
them or they might be generated using some external method like
QKD).
As the identification of the PPK can be just random octet string which
interpretation is left to the implementation. Both end needs to have
same PPK anyways, so in addition the PPK they might have ID string for
it. The full exchange would be something like this:
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],
N(PPK_ID, x1), N(PPK_ID, x2), ...,
AUTH, SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,]
N(PPK_ID, x1), AUTH,
SAr2, TSi, TSr}
SKEYSEED is calculated normally, but the based on the agreed PPK_ID
both ends fetch the real PPK to be used for the KEYMAT calculations.
Initiator can send multiple PPK_IDs, as there might be cases where
initiator and responder might be out of sync when using one time pad
keys, and responder replies with one PPK_ID which is the selected
PPK_ID.
As the contents of the PPK_ID is completely implementation dependent,
it might also contain some other structure, for example the initiator
might send largest offset in its one-time pad in PPK_ID, and responder
will pick any offset that is larger than that in response. Also as it
is not needed until the IPsec SA is created, there is no need to put
them in the unencrypted IKE_SA_INIT, we can put them in the IKE_AUTH
payload.
The PPK is then fetched from database or whatever, and used in the
KEYMAT calculation as specified above.
The same PPK_ID payloads can be used also in the CREATE_CHILD_SA
exchanges in similar ways as we can do another Diffie-Hellman there.
I gave about same comments when we were checking this last time, i.e.
when we were talking about the
draft-nagayama-ipsecme-ipsec-with-qkd-01.txt draft.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
