Raghunandan P (raghup) writes: > During the IKEv2 negotiation, suppose an authentication failure occurs > on the responder side, a Notify payload with AUTHENTICATION_FAILURE is > sent in the AUTH_EXCH response back to the initiator (Message 4). Is > this correct?
Yes. We do have open ticket for ikev2bis whether that notification should be sent unencrypted or not. As we have not finished authentication we cannot send it authenticated, but as we have finished Diffie-Hellman we can send it encrypted and integrity protected if we like. Sending it encrypted and integrity protected does provide proof that the error was sent by the party who participated in the Diffie-Hellman exchange in the IKE_SA_INIT, but it does not provide proof that the party is actually the intended party you tried to talk to (i.e. it could be man in the middle attacker). See the 2nd part of the ticket #9 for the ikev2bis document and the related ongoing discussion on the IPsec list. > Will there be any ACK sent from the initiator for this > notification? No. As that error will be sent as response to the request sent by the initiator, there cannot be any response to response packet (section 3.1: "An IKE endpoint MUST NOT generate a response to a message that is marked as being a response."). > Suppose the authentication failure happens on the initiator (and not the > responder), how is this handled? Does initiator send an explicit Notify > to the responder, which needs to respond back with an ACK? If the authentication failure happens on the initiator side, initiator has two options. 1) It can simply silently delete the half-created IKE SA, and fail the connection attempt (for his point of view the IKE SA was never created, thus it is allowed to do that). Responder who thinks the IKE SA exchange was successful will keep the IKE SA up, and as there is no traffic at all over it, it will most likely trigger some dead peer detection query after some timeout, and as initiator does not have the IKE SA up, it will not reply to those, and after the timeout the responder will also delete the IKE SA because it failed dead peer detection. 2) It can finish creation of the IKE SA, but mark it as failed, then after that it can start new INFORMATIONAL exchange in the IKE SA and send request containing delete payload to the responder. When responder receives that it will delete the IKE SA and send empty response back (responder still needs to keep IKE SA alive for some timeout, in case the response was lost and initiator retransmits its request). When that response is received by initiator it will delete the IKE SA. The second option has problems as it creates "unauthenticated" IKE SA which could be used to attack the initiator unless the initiator is protected by such by making sure that no exchanges can be done over that IKE SA. This requires implementations to understand that this IKE SA has special status of unauthenticated. The first option on the other hand does not delete the IKE SA from the responder, thus responder will still think the IKE SA is up and alive, and will keep it there wasting resources until the dead peer detection fails. I think the most common case is to use the first option, as it does not really require any extra code, and initiator end will still log that connection failed, thus for example in remote access cases the interactive user who initiated the connection will see that and can change configuration etc to fix the situation. And as responder already did manage to authenticate the initiator, this cannot be used as unathenticated denial of service attack. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
