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

From: Yaron Sheffer <[email-masked]>
Date: Sun, 3 May 2009 23:37:10 +0300

Tero:

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

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:

The first part (don't nuke the IKE SA) is resolved, but the second part
(should the error message be encrypted) is still an open issue.

Yaron:

And then we had a long discussion (see e.g.
http://www.ietf.org/mail-archive/web/ipsec/current/msg03783.html) but it was
never resolved.

---

From: <[email-masked]>
Date: Mon, 4 May 2009 14:09:16 +0200

Tero,

What do you think of the proposed text here?

http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Yaron Sheffer
> Sent: 03 May, 2009 23:37
> To: IPsecme WG
> Subject: [IPsec] Issue #9: Notification when creation of CHILD_SA fails
> 
> Tero:
>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 May 2009 15:09:24 +0300

> http://www.ietf.org/mail-archive/web/ipsec/current/msg03783.html) but it was

I think I have now changed my mind about this issue, meaning I think
the reply should be encrypted and MAC'ed but it should still be
clearly specified that it is unauthenticated, as we have not yet
verified the identity of the other end. Having the message encrypted
and MAC'ed proofs that the entity who sent us the IKE_SA_INIT is also
responsible for this IKE_AUTH error, which means there is no point of
retransmitting our request anymore, as only the party participating
the Diffie-Hellman could have generated the error.

I.e. when error of type:

				<--- HDR, SK { N(error_for_ike_sa) }

is received we can consider that IKE SA connection as failed, and
delete the IKE SA immediately, but we should not consider that error
as permanent error from that node, as man in the middle attacker could
have generated such error instead of the intended party.

After receiving such error initiator MAY restart IKE SA creation from
the beginning few times before completely failing the IKE SA creation.
This is related to the section 2.4 3rd last paragraph which explains
how initiator can protect himself against this kind of poison the
connection setup attempt. I.e. if IKE SA negotiation failed then
initiator should perhaps consider there might be man-in-the-middle and
enable that protocol described there, i.e. process multiple
IKE_SA_INIT replies, and continue them in paralleal and then pick the
one which succeeds and fail the others. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 4 May 2009 15:49:48 +0300

Hi Pasi,

Tero's mail gives a clearer explanation of the situation than your proposed
text. Gluing the two together, how about replacing your last paragraph with:

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 (or if
the peer fails to authenticate the other end for some reason), the
information needs to be treated with caution. More precisely, (assuming that
the MAC verifies correctly) the sender of the error indication is known to
be the responder of the IKE_SA_INIT exchange, but the sender's identity
cannot be assured.

Thanks,
	Yaron

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, May 04, 2009 15:09
> To: [email-masked]; [email-masked]
> Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA
> fails
> 
> Tero,
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: <[email-masked]>
Date: Mon, 4 May 2009 15:16:45 +0200

Yaron Sheffer wrote:

> Hi Pasi,
> 
> Tero's mail gives a clearer explanation of the situation than your
> proposed text. Gluing the two together, how about replacing your
> last paragraph with:
> 
> 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 (or if the peer fails to
> authenticate the other end for some reason), the information needs
> to be treated with caution. More precisely, (assuming that the MAC
> verifies correctly) the sender of the error indication is known to
> be the responder of the IKE_SA_INIT exchange, but the sender's
> identity cannot be assured.

Looks good to me!

Best regards,
Pasi

> > From: [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 May 2009 13:37:09 +0300

> http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html

The NO_ADDITIONAL_SAS error should be added to the error list, and I
am not completely happy with the last paragraph, i.e. it could be
expanded bit more to explain the situation more, not just say "treated
with caution".

I am bit worried that implementors do not understand the difference
with encrypted and MACed compared to the fact that the other peer has
authenticated himself (i.e. sent AUTH payload). I think adding bit
more text there to make that clear would be needed.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 May 2009 13:56:23 +0300

> be the responder of the IKE_SA_INIT exchange, but the sender's identity

That is also good, but I would like to add also something about what
implementations should do in that situation.

Texts with "treated with caution" etc are fine for specifications, but
are really annoying for implementors. What does that mean for my
implementation? What kind of things should I do after that?

I.e. it should tell following things:

  - If properly MACed error reply is received, the IKE SA creation
    fails, and no more retransmissions is sent.
  - This is not fatal permanent error as the identity of the other end
    could not be proven, meaning active attacker could have faked
    those messages.
  - Because of this it should still retry IKE SA creation from the
    beginning several times, before completely giving up (and perhaps
    enable multiple IKE_SA_INIT response processing described in
    section 2.4).
-- 
[email-masked]