David Wierbowski writes:
> Ticket #9 says"If the authentication fails in such ways that the entries
> cannot create IKE SA (authentication failure or similar), then the response
> will be unencrypted, unauthenticated notify." Back in January there was
> additional discussion about this issue. Several people supported sending
> the response as an encrypted, authenticated notify. The reason being that
^^^^^^^^^^^^^
> the only entity who can send an encrypted, authenticated notify is the
> person with knowledge of SK_e* and SK_a*.
That authenticated is very dangerous word there. The party sending
that notification is NOT authenticated. He has not proven his
identity by sending AUTH payload. As this error happens BEFORE he
sends that payload, the notification will never be authenticated in
the IKEv2 sense. It will be integrity protected, and they are known to
be come from the same UNAUTHENTICATED party who responded to the
IKE_SA_INIT exchange and did Diffie-Hellman.
Man in the middle attacker can trivially fake that message, and if the
receiving party actually takes them as authenticated error messages
from the party he intended to talk to, he might do actions based on
the attackers notifications.
I agree there is benefit for allowing those encrypted and integrity
protected notifications, as they do prove that they are sent by the
same party who responded to the IKE_SA_INIT, thus they do tell that
there is no point of continue that IKEv2 SA creation. On the other
hand those cannot be taken as really authenticate errors, thus the
initiator should still delete that partial IKEv2 SA attempt and try
again (perhaps after suitable timeout).
As it seems to be hard thing to distinguish for even here in the IPsec
WG, I am afraid that it will be even harder for some implementor
reading the draft to understand the difference between integrity
protected and authenticated messages.
This means that if those are allowed, they do require some text
explaing this matter.
> Have we reach a decision yet? I thought we decided it was ok to send an
> encrypted, authenticated notify in this case and the initiator could take
> action on it because he knows it came from the person that he performed the
> DH exchange with, but the ticket does not reflect that.
I am not sure we reached the decision yet, but I think more text is
needed if that is allowed, thus creating that text might help moving
things forward (i.e send replacement text).
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
