Subject: [IPsec] Issue #152: EAP failure and acknowledgement

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Jan 2010 13:05:14 -0800

2.16: if the responder sends an EAP Failure, is this IKE message acknowledged by the initiator?

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Jan 2010 23:52:43 +0200

In fact, the whole message sequence of EAP Failure is not described anywhere, and is at best hinted in 2.21.2, which in general assumes the basic 2-message IKE_AUTH exchange.

	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Hoffman
> Sent: Wednesday, January 20, 2010 23:05
> To: IPsecme WG
> Subject: [IPsec] Issue #152: EAP failure and acknowledgement
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jan 2010 08:30:56 +0200

We do have this:

                                                                The
   responder MAY at any time terminate the IKE exchange by sending an
   EAP payload containing the Failure message.

I guess "terminate" means that the initiator does not send any more messages. 

This is also one of the places where there is an ambiguity as to the meaning of "exchange". Usually an "exchange" is one request-response pair, but here it seems to be referring to the entire series of IKE_AUTH requests and responses.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 21 Jan 2010 11:30:59 +0200

> I guess "terminate" means that the initiator does not send any more

Yes. As the responder send EAP Failure, and it is the one who is
driving EAP exchanges, there is nothing initiator can do after that.

Also as responder already indicated that the authentication failed by
sending EAP failure, it most likely will mark that IKE SA as failed,
and will clean it up after suitable timeout, just like it does in
AUTHENTICATION_FAILED case (it cannot clean it up immediately, as it
needs to be able to retransmit its EAP failure message in case it
didn't reach the other end and initiator retransmits its last packet).

> This is also one of the places where there is an ambiguity as to the
> meaning of "exchange". Usually an "exchange" is one request-response
> pair, but here it seems to be referring to the entire series of
> IKE_AUTH requests and responses. 

As the EAP Failure goes into the IKE Response packet which completes
that current IKE_AUTH exchange anyways, I think the terminate here
really means the whole initial exchanges (i.e. combined IKE_SA_INIT
and IKE_AUTH exchanges).

> > acknowledged by the initiator? 

How could the initiator acknowledge it? EAP failure was sent inside
the response packet, so only way to initiator to send anything is to
start new exchange. That new exchange cannot be INFORMATIONAL as those
can only be sent AFTER all IKE_AUTH exchanges have completed (from
section 1). So the only way would be to start new IKE_AUTH exchange
which contains N(AUTHENTICATION_FAILED) or similar, but most likely
the other end will not respond to that as for his point of view the
IKE SA authentication has already failed.

So the best way is probably just interpret the EAP Failure in the same
way we do for N(AUTHENTICATION_FAILED) notifications in IKE_AUTH, i.e.
the whole IKE SA creation failed, and half-created IKE SA will be
silently cleaned up (i.e. initiator can do that immediately when it
gets N(AUTHENTICATION_FAILED) or EAP(Failure), and responder can do it
after suitable timeout).

We could clarify this by modifying the text in 2.21 from:

   Only authentication failures (AUTHENTICATION_FAILED) and malformed
   messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
   requiring an explicit INFORMATIONAL exchange carrying a DELETE
   payload.  Other error conditions MAY require such an exchange if
   policy dictates that this is needed.

to

   Only authentication failures (AUTHENTICATION_FAILED and EAP
   Failure) and malformed messages (INVALID_SYNTAX) lead to a deletion
   of the IKE SA without requiring an explicit INFORMATIONAL exchange
   carrying a DELETE payload. Other error conditions MAY require such
   an exchange if policy dictates that this is needed.

I.e. expand that authentication failures include both
AUTHENTICATION_FAILED notification and EAP Failure cases.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 21 Jan 2010 12:06:29 +0200

Also add at the end of the relevant paragraph of 2.16: "If the exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED notification is not sent."

Thanks,
	Yaron

> Of Tero Kivinen
> Sent: Thursday, January 21, 2010 11:31
> To: Yoav Nir
> Cc: IPsecme WG; Paul Hoffman
> Subject: Re: [IPsec] Issue #152: EAP failure and acknowledgement
> 
> Yoav Nir writes:
> > We do have this:
> >
> >                                                                 The