Valery Smyslov writes: > > 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.
And if that helps, they do know that the problem was in the PPK. Also depending on the authentication algorithm there is more cases that result authentication failure and which are known to local user (i.e., expired or revoked certificates, unknown trust anchor, EAP authentication failure etc). With certificates or with EAP you should not really get failures in the AUTH calculation unless there is bug in your code, or there is attacker on the line modifying the bits. Only case where you get authentication failure which just results invalid AUTH is when you are using shared key authentication and then you do not know whether it is the shared secret or PPK which is wrong (or whether there is bug in implementation or attacker modifying the bits). Turning PPK off and retrying and see if that helps will tell you whether it is the PPK or the shared secret which is wrong, and that is quite easy way to debug issues. > 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). Yep. > 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. That does not help. We need to Diffie-Hellman before we can see the IKE_AUTH contents, so when we are doing that verification we have already done the expensive operations. On the other hand as this issue is not really with certificates, we are not doing actual public key operation when calculating the AUTH payload, we are simply ding the prf with shared secret. With certificates the public key used is already sent in the certificate payload inside the exchange, so it is known, and if there is problems verifying it, we know it before we end up in the AUTH calculation, and we return AUTHENTICATION_FAILED without ever calculating the AUTH payload. > 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. I do not think that is needed, and I definately do not want to tell attackers whether it was the PPK or something else that caused AUTHENTICATION_FAILED notification. It would be fine to tell that in the logs, but not on the wire. Even in the logs I do not think it is that important, as there as easy ways to debug this. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
