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

From: [email-masked]
Date: Fri, 16 Sep 2005 17:15:14 -0400

To what messages do you refer to in the sentence "Such messages MUST NOT
kill an SA"? In the next sentence, you say that "a cryptographically
protected AUTHENTICATION_FAILED message should kill the SA". So, I infer
that you mean AUTHENTICATION_FAILED messages that are in the clear, right?

Thanks,

Thomas G.

> -----Original Message-----
> From: Charlie Kaufman [mailto:[email-masked]]
> Sent: Friday, September 16, 2005 4:23 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Ipsec] Clarification on error notifications, please
> 
> 
> Yes and no.
> 
> The sentence only applies to SAs that have completed enough
> initialization that cryptographic protection of messages is 
> possible. So
> a failure response to an INIT message will not be 
> authenticated but that
> message should not be ignored (though an implementation might wait a
> while for a success response in case the failure was sent by a third
> party in a DOS attempt).
> 
> An AUTHENTICATION_FAILED notification, however, occurs after the first
> two messages and can be cryptographically protected even though the SA
> has not been authenticated. Such messages MUST NOT kill an SA. Only a
> cryptographically protected AUTHENTICATION_FAILED message should kill
> the SA.
> 
> 	--Charlie Kaufman
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Friday, September 16, 2005 8:15 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ipsec] Clarification on error notifications, please
> 
> It is not really clear to me what the scope of the following statement
> take
> from the IKEv2 draft, chapter 2.21, is.
> 
> "A node receiving such an unprotected Notify payload MUST NOT respond
> and
> MUST NOT change the state of any existing SAs."
> 
> My understanding is that this sentence only refers to the case where a
> node
> receives a message outside of the context of an IKE SA as outlined in
> the
> paragraph above this sentence, but not to the case where the node
> receives a
> notification on an IKE SA that is not (yet) completely negotiated. In
> particular, this sentence does not refer to an encrypted
> AUTHENTICATION_FAILED notification sent after a successful INIT
> exchange,
> although the notification will not be authenticated. (If this sentence
> were
> referring to such notifications, they would be not very meaningful.)
> Is my understanding correct?
> 
> Thanks,
> 
> Thomas G.
> 
> 
> 
> _______________________________________________
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec
> 

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 19 Sep 2005 03:52:00 +0300

[email-masked] writes:
> kill an SA"?

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. Also
AUTHENTICATION_FAILED messages cannot be sent after the IKE_AUTH
finishes, so the only case where they would be send authenticated
would be when the first AUTH payload check works with EAP, and the EAP
exchange itself succeeds (i.e. returns EAP(SUCCESS)), but the actual
keying material generated by the EAP does not match, thus the AUTH
payload verification of the second AUTH payload fails. 

> In the next sentence, you say that "a cryptographically

He might be refering the case of getting AUTHENTICATION_FAILED after
the first AUTH payload has already be verified (i.e. when we have
already authenticated the responder of the exchange). 

-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Sep 2005 07:29:45 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:

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

  I would disagree.

  I think that they are useful to send, and for the recipient to
rate-limit log. It's a signal to "please fetch human".

    Tero> He might be refering the case of getting AUTHENTICATION_FAILED after
    Tero> the first AUTH payload has already be verified (i.e. when we have
    Tero> already authenticated the responder of the exchange). 

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 21 Sep 2005 19:03:48 +0300

> rate-limit log. It's a signal to "please fetch human".

I agree in that there is some use for sending them, but I still think
the responder MUST NOT act based on them...
-- 
[email-masked]