Subject: RE: [Ipsec] Clarification on error notifications, please

From: [email-masked]
Date: Tue, 20 Sep 2005 09:33:02 -0400

As I pointed out previously, you cannot know (until verification via the
AUTH payload) whether or not you are talking securely with the intended
peer.  The strategy I am proposing for an initiator responding to an
authentication failure notification (by tearing down local state) is
independent of such knowledge, so I don't see why you complain about not
possessing this knowledge.

Regarding the third paragraph of section 2.4, the DOS attack and avoidance
strategy describe here is relevant to the INIT exchange.  This thread is
only concerned with the AUTH exchange.

For diagnostic purposes, it is much better to receive an immediate
notification, especially in testing scenarios.  Furthermore, if an initiator
has something useful to do in response to an authentication failure, such as
attempting to establish a tunnel with a different peer or with the same peer
in a different way, it can do so without a long delay.  I don't want a long
delay when I try to make a phone call on my UMA mobile phone.

Lastly, it is in fact the case that an unsuccessful EAP authentication
dialogue can end without an EAP failure message.  Consider a responder that
acts as a pass-through NAS to a RADIUS AAA backend.  It may receive an
authentication failure response via RADIUS that does not include an EAP
failure message.  A pass-through NAS is not supposed to generate its own EAP
failure message in this situation, so the only option remaining is to send
an AUTHENTICATION_FAILED error notification back to the initiator.

Jim

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]]
Sent: Tuesday, September 20, 2005 8:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ipsec] Clarification on error notifications, please

[email-masked] writes:
> My intent in defining case a. is to describe the situation where there is
no
> modification of messages by any third party (i.e., no man in the middle)
and
> we are in fact talking with the intended peer.  Case b. is the complement
-
> literally everything else.  Your case c. is therefore a sub-case of case
b.
> and everything I said before still applies.

But as you have not authenticated you do not know if you are talking
to the intended peer. 

> In your case c. there is an attacker modifying messages and the desirable
> outcome is to abandon the negotiation.  Are you suggesting there is
> something better to be done in this case?  

In case the real responder also gets the packets and answers to them
too, then you do not want to be tricked by the attacker sending
packets to you too (i.e. if you implement the 3rd last paragraph of
2.4, you must not abort the negotiation if you receive notify from one
of those messages). 

> Null encryption is not legal so I don't understand your point about
sending
> an error notification in the clear.

That was just to point you out that we haven't yet authenticated the
SA parameters, so you might be tricked to use weaker (or even broken)
cipher/hash by the attacker and that might have other security
properties.

As we have not authenticated those yet, we have to consider that as a
completele different case and it makes security analysis of the
protocol quite hard, and there might be new attacks opened because of
that.

As authentication failure is usually permanent condition that can only
be fixed by the human interaction, there is no real reason to use that
as special case requiring faster error messages than normally (i.e.
normal timeouts).

Note, that those should not happen in case there is interactive
authentication going on using EAP, as then you do send EAP(FAILURE)
instead of error notify. 
-- 
[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Sep 2005 21:25:29 +0300

> only concerned with the AUTH exchange.

They are not limited to the INIT exchange. You only know that it is
really the person you wanteed to talk to after you have processed the
valid AUTH payload from the other end.

Meaning:

Initiator		Attacker		Responder

IKE_SA_INIT ->

		<- IKE_SA_INIT_A
		<- IKE_SA_INIT_B
						<- IKE_SA_INIT_R

now the Initiator will continue with all those packets, and send out

IKE_AUTH_A ->
IKE_AUTH_B ->
IKE_AUTH_R ->

Attacker can decrypt those packets, and they can send valid
cryptographically protecteed error message, but they still cannot
generate AUTH payload that Initiator would accept. The Responder can
return IKE_AUTH packet with valid AUTH payload and then Initiator will
know that A, and B were bogus, and he can remove those, and only keep
the R.

		<- IKE_AUTH_A(AUTHENTICATION_FAILURE)
		<- IKE_AUTH_B(INVALID_SYNTAX)
						<- IKE_AUTH(valid)

> notification, especially in testing scenarios.  Furthermore, if an initiator

Changes made because of testing purposes should be considered as
testing aids, and they should not affect the security of the protocol. 

> delay when I try to make a phone call on my UMA mobile phone.

As there is no indication how to fix the situation, the initiator
cannot really do anything there. If your UMA mobile phone sim card is
rejected because of you haven't paid your bills, I do not think
immediate error messages really can solve the situation any faster...
Trying to get contact with the operators helpdesk will take hours
anyways :)

> an AUTHENTICATION_FAILED error notification back to the initiator.

The IKEv2 does not really allow that kind of behavior (section 2.16):

   Once the protocol exchange defined by the chosen EAP authentication
   method has successfully terminated, the responder MUST send an EAP
   payload containing the Success message. Similarly, if the
   authentication method has failed, the responder MUST send an EAP
   payload containing the Failure message. The responder MAY at any
   time terminate the IKE exchange by sending an EAP payload
   containing the Failure message.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Sep 2005 22:05:28 +0300

> testing aids, and they should not affect the security of the protocol. 

To clarify this point a bit more, sending error notifications in that
kind of situations is usefull for diagnostic purposes. Acting based on
such unauthetnicated (though encrypted and mac'ed) notifies do affect
the security of the protocol in a way that is not necessarely
understood properly by the casual observer.

There are quite a lot of tiny things there that needs to be taken
account, and I would not recommend acting based on those messages
unless you really understand what it means from the security point of
view. The current security considerations does not cover that as the
current document says you do not act based on unauthenticated notifies.
-- 
[email-masked]