Hi,
> So I have proposed earlier that we should mix the ppk to SK_d, SK_pi,
> and SK_pr, i.e., something like this:
>
> SKEYSEED = prf(Ni | Nr, g^ir)
>
> {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'}
> = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)
>
> If no PPK available, then
>
> SK_d = SK_d'
> SK_pi = SK_pi'
> SK_pr = SK_pr'
>
> If PPK is available then
>
> SK_d = prf(PPK, SK_d')
> SK_pi = prf(PPK, SK_pi')
> SK_pr = prf(PPK, SK_pr')
>
> This has the follolowing benefits. The SK_d modification will mean
> that IKEv2 SA will gain protection against Quantum Resistance after
> the IKEv2 SA irs rekeyed, as rekeyed SA will be using SK_d to derive
> new keys. SK_d also used to derive the KEYMAT, meaning the Child SA
> will gain protection.
For this property it is enough to modify calculation of SK_d only.
> Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the
> IKEv2 authentication will fail, and we will get exactly same failure
> for wrong PPK than we do with wrong shared key or digital signature
> failures. This means that attacker do not gain any information which
> part of the authentication failed.
I'm not sure it is a good property. Sure, it gives an attacker no
information about which part of authentication (signature or PPK)
failed, but it gives local user no such information too. And
this is really bad, because in case of authentication failure users
will have hard time finding which part to blame and will
most probably just switch PPK off.
On the other hand, the nice property of modifying SK_pi and SK_pr
is that even the initial exchange is authenticated even in case an attacker
can break digital signatures on the fly (sure, she can break DH and see what
is inside IKE_AUTH, but she cannot change the content unless she breaks PPK
too).
I think that if SK_pi and SK_pr are modified, then some information
should be given to the user to help distinguish PPK errors from
signature errors. For example, the Initiator can include something like
N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 0)
into the IKE_AUTH request, and the responder can include something like
N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 1)
into the IKE_AUTH response. In this case each side can verify
that the other end do own and use the correct PPK before starting
computationally expensive public-key operations.
In case the PPK is incorrect AUTHENTICATION_FAILED
notification can be sent to the peer (as with any other authentication
errors), but local user will know which part of the authentication goes wrong.
Or probably some new notification (e.g. WRONG_PPK) can be sent
instead of (or in addition to) AUTHENTICATION_FAILED, if we want
the peer to have better diagnostics.
Regards,
Valery.
> [email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
