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

From: [email-masked]
Date: Mon, 19 Sep 2005 10:37:20 +0300

Tero Kivinen wrote:

> I think he is refereing the AUTHENTICATION_FAILED
> notifies. Thus getting AUTHENTICATION_FAILED notify message
> before you have finished checking AUTH payloads MUST NOT kill
> an SA, which means they are ignored, so there is really no
> point of even seding them ever.

No, I don't think this is right... if you receive a protected
AUTHENTICATION_FAILED notify message during the IKE_AUTH
exchange, you must kill the IKE_SA.

Since the MAC of the message was correct, the recipient knows the
notification was sent by the same party as the KE/nonce payloads
in IKE_SA_INIT exchange.  Most likely this was the "real" peer,
who is just telling us that something went wrong in the
authentication.  And if it was an attacker, then the IKE_SA
will fail anyway, since AUTH verification later will fail.

Or in other words, there is no case where ignoring
AUTHENTICATION_FAILED would provide any kind of benefit: 
if we really do have a man-in-the-middle who can insert a 
fake AUTHENTICATION_FAILED notification, then it automatically 
means that AUTH payload verification will also fail.

(Unless the attacker can really do MitM against the IKE_SA
without causing AUTH verification to fail, but then we have
much, much worse problems than DoS...)

Best regards,
Pasi

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

---

From: [email-masked]
Date: Tue, 20 Sep 2005 10:30:48 +0300

Tero Kivinen wrote:
> [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. 
<snip>
> 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.

If the attacker has modified the algorithm proposals, the SA will be
torn down anyway because verification of the AUTH payload will fail.

Also, even if the attacker has modified the proposals, the selected
algorithms are still something that the peers consider as providing
sufficient level of security for them (and certainly not NULL). 
If it's sufficient for all other purposes as well, it's IMHO 
sufficient for encrypting an AUTHENTICATION_FAILED notification, too.

Best regards,
Pasi

---

From: [email-masked]
Date: Mon, 26 Sep 2005 18:02:18 +0300

Tero Kivinen wrote:

> He should probably log it, but I would say he should otherwise ignore
> the packet (or use it as hint), and continue trying until it times
> out, or after the policy is modified. The IKEv2 draft is quite clear
> about that (section 2.21):
> 
>    A node receiving such an unprotected Notify payload MUST NOT
>    respond and MUST NOT change the state of any existing SAs. The
>    message might be a forgery or might be a response the genuine
>    correspondent was tricked into sending. A node SHOULD treat such a
>    message (and also a network message like ICMP destination
>    unreachable) as a hint that there might be problems with SAs to
>    that IP address and SHOULD initiate a liveness test for any such
>    IKE_SA. An implementation SHOULD limit the frequency of such tests
>    to avoid being tricked into participating in a denial of service
>    attack.
> 
> Before we have processed the other ends AUTH payload the notifies are
> unprotected, as we do not know who the other end is. So the only
> option draft really gives you is to use it as a hint (i.e. you can log
> it, and you can perhaps make you time out faster, and limit the number
> of retranmissions). 

I think you're quoting the spec out of context. The paragraph before the

one you quoted makes it quite clear that "such an unprotected Notify"
means a Notify message sent totally outside of an IKE_SA (i.e., 
it's not encrypted and integrity-protected at all).

If we receive a notification _inside_ the IKE_SA (inside SK{..}), we
do know it came from the real peer of this IKE_SA, even if we don't 
know anything more about the peer yet. Thus, it makes absolutely no 
sense whatsoever to continue retransmitting the same request...

(Rate-limiting the establishment of new IKE_SAs is a totally 
different matter.)

Best regards,
Pasi