Subject: [IPsec] #9: Notification when creation of CHILD_SA fails

From: Yaron Sheffer <[email-masked]>
Date: Sun, 7 Dec 2008 17:09:21 +0200

>     same IP address.  The initiator begins negotiation of a CHILD_SA

>     using the SAi2 payload.  The final fields (starting with SAi2) are

>     described in the description of the CREATE_CHILD_SA exchange.

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

>                                           SAr2, TSi, TSr}

>     The responder asserts its identity with the IDr payload, optionally

>     sends one or more certificates (again with the certificate containing

>     the public key used to verify AUTH listed first), authenticates its

>     identity and protects the integrity of the second message with the

>     AUTH payload, and completes negotiation of a CHILD_SA with the

>     additional fields described below in the CREATE_CHILD_SA exchange.

>     The recipients of messages 3 and 4 MUST verify that all signatures

>     and MACs are computed correctly and that the names in the ID payloads

>     correspond to the keys used to generate the AUTH payload.

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

Tero: In the case of the that kind of failure the return packet will then be

without the SAr2, Tsi, and TSr, i.e.:

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

                                          N(error_for_child_sa)}

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. There is no point of

sending the notify encrypted and integrity protected, as it is not

authenticated (as initiator and responder have not yet verified the

AUTH payloads):

                                 <--  HDR, N(error_for_ike_sa)

The initiator receiving such reply MUST NOT immediately stop the SA

creation, but it should still retransmit the message few times, in

case that error notify was forgery and the real responder will reply

with valid reply. It can use the recipient of such message as a hint

to tell that authentication failed, thus it can shorten the

retransmission timers from few minutes down to few tens of seconds.

Paul: Not done. This is interesting, but should be discussed on the list.

Room: Scenario: IKE SA creation proceeds immediately to first CHILD SA
creation.  What if CHILD SA can't be created, but IKE SA is ok?  Text should
make it clear that failure of CHILD SA creation should not tear down IKE SA
(e.g., avoids losing work to create the IKE SA based on guessing wrong about
a child traffic selector).

Yaron: seems to me the ticket discusses one thing (IKE SA creation fails
because of bad authentication), while the room's discussion is about a
different thing (IKE SA successful). Comments on the original ticket are
welcome.

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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 8 Dec 2008 19:21:37 +0200

Yaron Sheffer writes:
> Yaron: seems to me the ticket discusses one thing (IKE SA creation
> fails because of bad authentication), while the room's discussion is
> about a different thing (IKE SA successful). Comments on the
> original ticket are welcome.

The ticket actually has two cases, the most important one is that
first part, i.e. where it says that we need to explicitly describe
the case where the IPsec SA creation fails, but IKE SA creation
succeeds. The clarification already says that, but I think we could
add explicit example messages out of that.

The ticket also talks about the second case, where the IKE SA fails,
i.e. the case when IKE SA is not created, and we need to send error
message back about that. As I explained in my text there is no point
of encrypting that as it will not be authenticated anyways. We might
want to split this to two different tickets. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Scott C Moonen <[email-masked]>
Date: Mon, 8 Dec 2008 15:35:56 -0500

> want to split this to two different tickets. 

I think that this response should be encrypted.  The IKE_SA_INIT exchange 
constitutes an agreement to use certain algorithms to protect subsequent 
messages.  Even if the peers cannot successfully authenticate one another, 
I think that encrypting the response is the right thing to do.  Consider 
section 1.2 of the draft (and similar statements in RFCs 4306, 4718):

   . . . All messages following the initial exchange are cryptographically
   protected using the cryptographic algorithms and keys negotiated in
   the the IKE_SA_INIT exchange. . . .  All
   subsequent messages include an Encrypted Payload, . . .

   . . .

   . . . The messages that
   follow [IKE_SA_INIT] are encrypted and integrity protected in their 
entirety
   . . .

I think any existing IKEv2 implementation is going to make the assumption 
that the response in this case is encrypted, and just ignore a 
non-encrypted response.  Moreover, having the response encrypted and 
HMACed is advantageous.  Even if the peers are not authenticated, 
receiving an HMACed response at least proves that the message came from 
the peer we're talking to, so it allows the initiator to take immediate 
action without waiting for a plaintext response to be contradicted.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
Yaron Sheffer <[email-masked]>
Cc:
IPsecme WG <[email-masked]>
Date:
12/08/2008 12:23 PM
Subject:
[IPsec]  #9: Notification when creation of CHILD_SA fails