Subject: [IPsec] Ticket #9

From: David Wierbowski <[email-masked]>
Date: Thu, 26 Mar 2009 16:09:25 -0400

Ticket #9 says"If the authentication fails in such ways that the entries
cannot create IKE SA (authentication failure or similar), then the response
will be unencrypted, unauthenticated notify."  Back in January there was
additional discussion about this issue.  Several people supported sending
the response as an encrypted, authenticated notify.  The reason being that
the only entity who can send an encrypted, authenticated notify is the
person with knowledge of  SK_e* and SK_a*.

Have we reach a decision yet?  I thought we decided it was ok to send an
encrypted, authenticated notify in this case and the initiator could take
action on it because he knows it came from the person that he performed the
DH exchange with, but the ticket does not reflect that.

Dave Wierbowski

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Mar 2009 03:43:12 +0200

> the response as an encrypted, authenticated notify.  The reason being that
				^^^^^^^^^^^^^
> person with knowledge of  SK_e* and SK_a*.

That authenticated is very dangerous word there. The party sending
that notification is NOT authenticated. He has not proven his
identity by sending AUTH payload. As this error happens BEFORE he
sends that payload, the notification will never be authenticated in
the IKEv2 sense. It will be integrity protected, and they are known to
be come from the same UNAUTHENTICATED party who responded to the
IKE_SA_INIT exchange and did Diffie-Hellman.

Man in the middle attacker can trivially fake that message, and if the
receiving party actually takes them as authenticated error messages
from the party he intended to talk to, he might do actions based on
the attackers notifications.

I agree there is benefit for allowing those encrypted and integrity
protected notifications, as they do prove that they are sent by the
same party who responded to the IKE_SA_INIT, thus they do tell that
there is no point of continue that IKEv2 SA creation. On the other
hand those cannot be taken as really authenticate errors, thus the
initiator should still delete that partial IKEv2 SA attempt and try
again (perhaps after suitable timeout).

As it seems to be hard thing to distinguish for even here in the IPsec
WG, I am afraid that it will be even harder for some implementor
reading the draft to understand the difference between integrity
protected and authenticated messages.

This means that if those are allowed, they do require some text
explaing this matter.

> DH exchange with, but the ticket does not reflect that.

I am not sure we reached the decision yet, but I think more text is
needed if that is allowed, thus creating that text might help moving
things forward (i.e send replacement text). 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Fri, 27 Mar 2009 18:25:29 +0100

> things forward (i.e send replacement text). 

Here's a first sketch:

Section 1.3.1:
OLD: 
   Failure of an attempt to create a CHILD SA SHOULD NOT tear down the
   IKE SA: there is no reason to lose the work done to set up the IKE
   SA.  When an IKE SA is not created, the error message return SHOULD
   NOT be encrypted because the other party will not be able to
   authenticate that message. [[ Note: this text may be changed in the
   future. ]]
NEW:
   If creating the CHILD SA fails for any reason, the IKE SA stays
   up.

(This section is about CREATE_CHILD_SA exchange, so the text about
IKE_SA creation failures is in wrong place)

Section 1.2:
OLD:
   {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
   fails for some reason, the IKE SA is still created as usual.  The
   list of responses in the IKE_AUTH exchange that do not prevent an IKE
   SA from being set up include at least the following:
   NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
   INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
NEW:
   {{ Clarif-4.2 }} During the IKE_AUTH exchange, two kinds of 
   failures can happen. 

   If the failure is related to creating the Child SA, the IKE SA is
   still created as usual. The list of responses in the IKE_AUTH
   exchange that do not prevent an IKE SA from being set up include at
   least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,
   SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
   FAILED_CP_REQUIRED.  In this case, the error notification is
   included in the last IKE_AUTH response, and the SA/TSi/TSr payloads
   are omitted from this message.
 
   If the failure is related to creating the IKE SA (for example,
   AUTHENTICATION_FAILED), the IKE_SA is not created. Note that
   although the IKE_AUTH messages are encrypted and integrity
   protected, if the peer receiving this notification has not
   authenticated the other end yet, the information needs to be
   treated with caution. 

Best regards,
Pasi

---

From: "Kalyani Garigipati (kagarigi)" <[email-masked]>
Date: Tue, 31 Mar 2009 17:32:43 +0530

Hi ,

Please clarify the following .

1. Is it mandatory or optional (implementation dependent) to create an
IKEV2 sa when IKE_AUTH exchange fails for reason like
NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,
SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ?

Regards,
Kalyani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, March 27, 2009 10:55 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [IPsec] Ticket #9

Here's a first sketch:

Section 1.3.1:
OLD: 

Section 1.2:
OLD:

Best regards,
Pasi
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Kalyani Garigipati (kagarigi)" <[email-masked]>
Date: Tue, 31 Mar 2009 17:38:56 +0530

Hi,

Please clarify the following.

On the responder , if creating the Child SA during the IKE_AUTH request
processing fails for some reason like NO_PROPOSAL_CHOSEN,
TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and
FAILED_CP_REQUIRED, then should we be sending AUTH, IDr and CERT
payloads as usual in AUTH response ?

Something like below flow.

HDR, SK {IDi, [CERT,] [CERTREQ,]
       [IDr,] AUTH, SAi2,
       TSi, TSr}  -->

                                      <--  HDR, SK {IDr, [CERT,] AUTH,
                                         N[TS_UNACCEPTABLE]}

Regards,
Kalyani

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 31 Mar 2009 11:08:09 -0700

>SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ?

I am unclear on what you are asking. The IKE SA is already set up when the child SA creation fails. Thus, it does not need to be created.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 31 Mar 2009 11:10:10 -0700

>                                      <--  HDR, SK {IDr, [CERT,] AUTH,

Yes, you need to be sending IDr and AUTH. CERT is already optional, and I don't think anyone would be surprised if you didn't send it during the failure case.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kalyani Garigipati (kagarigi)" <[email-masked]>
Date: Wed, 1 Apr 2009 11:26:28 +0530

Hi Paul,

My question was , during the AUTH exchange if failure happens
due to reasons like NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE,
SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED,
Should we still bring IKEV2 SA as usual? RFC says we can still bring the
IKeV2 SA as usual, but my doubt is if this is mandatory or optional?

My question was not during Child SA Creation.

Regards,
kalyani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Hoffman
Sent: Tuesday, March 31, 2009 11:38 PM
To: Kalyani Garigipati (kagarigi)
Cc: [email-masked]
Subject: Re: [IPsec] Ticket #9

>SINGLE_PAIR_REQUIRED,INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED ?

I am unclear on what you are asking. The IKE SA is already set up when
the child SA creation fails. Thus, it does not need to be created.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Apr 2009 09:34:03 +0300

Hi Kalyani.

One way or the other, it has to be mandatory. The "dread" scenario is that one peer thinks the IKE SA is set up, while the other thinks that it is not.

>From the discussion of Ticket #9, the consensus seems to be that with all those child-SA specific reasons, the IKE SA is set up - it is not silently discarded.

Of course, IKE SAs are usually not set up as for their own sake, but as a means to the end - the child SA. So if setting up the child SA fails, either peer may decide that keeping the IKE SA is a waste of memory. In that case either side can delete the IKE SA, but only by doing it explicitly with a DELETE payload in an INFORMATIONAL exchange.

Hope this helps

Yoav 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Kalyani Garigipati (kagarigi)
> Sent: Wednesday, April 01, 2009 8:56 AM
> To: Paul Hoffman
> Cc: [email-masked]
> FAILED_CP_REQUIRED, Should we still bring IKEV2 SA as usual? 
> RFC says we can still bring the
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Hoffman
> I am unclear on what you are asking. The IKE SA is already 
> set up when the child SA creation fails. Thus, it does not 
> need to be created.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> Scanned by Check Point Total Security Gateway.
> 
Email secured by Check Point