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

From: [email-masked]
Date: Mon, 19 Sep 2005 17:00:37 -0400

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.

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?  

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

Jim

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]]
Sent: Monday, September 19, 2005 4:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ipsec] Clarification on error notifications, please

[email-masked] writes:
> Once we have obtained privacy and integrity protection, but not yet
> authenticated our peer, we can break down the analysis into precisely two
> cases:
> 
> a. we are talking with the intended peer
> 
> b. we are not talking with the intended peer (includes all
man-in-the-middle
> scenarios)

c. We are talking to the intended peer, but attacker has modified the
cipher/prf/hash etc algorithms proposed by the initiator. 

> In case a. it is safe to respond to an AUTHENTICATION_FAILED notification
by
> tearing down our local state because we trust the message was generated by
> the intended peer.
> 
> In case b it is safe to respond to an AUTHENTICATION_FAILED notification
by
> tearing down our local state because we never want to interact with an
> incorrect peer.

And do we want to tear down the SA as attacker modified the cipher to
be null in IKE SA level, and we are now sending all that error
information in clear?

Note, that we haven't yet verified that the SA payload cipher/hash/prf
etc exchange is done properly without someone attacking against those.

> We cannot know whether we are dealing with case a or b, but since tearing
> down local state is safe and desirable in both cases, I think it is a
> defensible approach.
-- 
[email-masked]

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 20 Sep 2005 15:46:45 +0300

> 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. 

> 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). 

> 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]