Subject: [IPsec] Question on Authentication failure

From: "Raghunandan P (raghup)" <[email-masked]>
Date: Mon, 2 Mar 2009 18:25:27 +0530

Hi,

I needed a clarification related to handling of Authentication failure
on the initiator and responder sides.

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? Will there be any ACK sent from the initiator for this
notification?

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?

The draft mentions the following:

"AUTHENTICATION_FAILED                    24
       Sent in the response to an IKE_AUTH message when for some reason
       the authentication failed. There is no associated data."

More clarity will help.

Thanks

Raghu

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 2 Mar 2009 16:05:23 +0200

Raghunandan P (raghup) writes:
> 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.").

> 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.
-- 
[email-masked]