Subject: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 Apr 2013 16:06:24 +0300

The section 2.5 says:

----------------------------------------------------------------------
2.5.  Protocol Behavior

   The recipient of a DH public key that fails one of the above tests
   can assume that the sender either is truly malicious or else it has a
   bug in its implementation.  The recipient MAY respond with an
   unauthenticated INVALID_SYNTAX notification, and MUST immediately
   drop the IKE SA.
----------------------------------------------------------------------

I think the "MUST immediately drop the IKE SA" is wrong.

I.e if initiator sends IKE_SA_INIT request out as follows:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni  -->

and the responder gets it and starts to generate proper respond
message (i.e. starts to do Diffie-Hellman generate), but while it is
doing it attacker M sends faked message back:

                                <--  HDR, SAr1, KEr*, Nr, [CERTREQ]

where the KEr* is generated so that it will fail the tests (i.e.
sending all 0xffff...fff as KEr, which would fail the 1 < r < p-1
check), then using current text the Initiator deletes the IKE SA. When
the Responder is ready with properly generated KEr, it will send its
reply:

                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]

but it is too late, as Initiator has already "immediately dropped the
IKE SA".

Also these tests might also fail during the CREATE_CHILD_SA
exchange.

I think the more appropriate text would be to say:

----------------------------------------------------------------------
2.5.  Protocol Behavior

   The recipient of a DH public key that fails one of the above tests
   can assume that the sender either is truly malicious or else it has a
   bug in its implementation.

   If this error happens during the IKE_SA_INIT exchange, then the
   recipient MUST drop the message containing invalid KE payload. If
   the invalid KE payload was in the IKE_SA_INIT request, then
   responder receiving it MAY send INVALID_SYNTAX error back, but it
   MUST NOT start creating any new IKE SA based on such request. If
   the invalid KE payload was in the IKE_SA_INIT reply, then Initiator
   receiving that reply, ignores the message, and continues waiting
   for later messages containing properly formatted KE payload.

   If the invalid KE payload happen during the CREATE_CHILD_SA
   exchange (or any other exchange after the IKE SA connection has
   been authenticated) and the invalid KE payload is in the request
   message, then responder MUST reply with INVALID_SYNTAX error notify
   and drop the IKE SA. If the invalid KE payload is in the reply
   message, then initiator getting this reply message MUST immediately
   delete the IKE SA by sending IKE SA delete notification (as an new
   exchange).

----------------------------------------------------------------------

This also requires some changes to the section 3.3, i.e. replace

----------------------------------------------------------------------
   The behavior recommended in Section 2.5 is in line with generic error
   treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of [RFC5996].
   The sender is not required to send back an error notification, and
   the recipient cannot depend on this notification because it is
   unauthenticated.  Thus, the notification is only useful to debug
   implementation errors.
...
----------------------------------------------------------------------

with

----------------------------------------------------------------------
   The behavior recommended in Section 2.5 is in line with generic
   error treatment during the IKE_SA_INIT exchange, Sec. 2.21.1 of
   [RFC5996]. The sender is not required to send back an error
   notification, and the recipient cannot depend on this notification
   because it is unauthenticated. Thus, the notification is only
   useful to debug implementation errors. Also the Initiator getting
   reply message back with invalid KE payload should simply drop it as
   it can be from attacker, and wait for the real peer to reply.

   If the error happens after the peers have been authenticated we do
   have a trusted channel to send the errors. In that case we want to
   tear down the IKE SA as this kind of failures indicate there is
   something seriously wrong with the other peer, and clearing the IKE
   SA and starting from the beginning might help. If it is the
   responder failing these tests, it can simply return the fatal error
   notify (INVALID_SYNTAX, see Section 2.21.3 of RFC5996) and both
   peers will delete the IKE SA. The Initiator does not have this
   option, as when he notices this problem the exchange is already
   done. It needs to start new exchange to delete IKE SA. This IKE SA
   clearing is mandatory as Initiator cannot create the Child SA based
   on the invalid KE data, and other end already created it as it sent
   its reply, thus Child SA state is out of sync. Most compatible way
   to delete IKE SA is to just send IKE SA delete notification, even
   though starting new INFORMATIONAL exchange and sending
   INVALID_SYNTAX notify could also work.
...
-- 
[email-masked]

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 2 Apr 2013 13:36:58 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tero Kivinen
> Sent: Tuesday, April 02, 2013 9:06 AM
> To: [email-masked]
> Subject: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01
> 
> The section 2.5 says:
> 
> and the responder gets it and starts to generate proper respond message
> (i.e. starts to do Diffie-Hellman generate), but while it is doing it attacker M
> sends faked message back:
> 
> sending all 0xffff...fff as KEr, which would fail the 1 < r < p-1 check), then
> using current text the Initiator deletes the IKE SA. When the Responder is
> ready with properly generated KEr, it will send its
> reply:
> 
> but it is too late, as Initiator has already "immediately dropped the IKE SA".

How is that behavior fundamentally different from the behavior we would get if the attacker inserted a valid, but different KEr* payload?  In that case, the tests will pass, and we'll perform the DH, and come up with incorrect SKEYSEED.

If the real responder will then send the correct "HDR, SAr1, KEr, Nr, [CERTREQ]", well, the initiator has already received its response and generated some SKEYSEEDs.  I wasn't aware that it was a requirement that the initiator create multiple SKEYSEEDs if it happens to receive multiple initial exchange 2 messages.

For an attacker's point of view, the behavior he gets by sending valid KEr* payloads is even more advantageous; he has not only prevented the SA from being created, he also forced the initiator to do more work before doing so.

> 
> Also these tests might also fail during the CREATE_CHILD_SA exchange.

There isn't a real requirement to discard the parent IKE SA; of course, we can't allow the creation of the child SA.

> I think the more appropriate text would be to say:

While I don't think the below text is wrong (except I would point out that there is no security requirement to discard the parent IKE SA during a test failure while generating a child SA), I would also point out that these don't appear to have any advantage over the current text.

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 Apr 2013 13:30:28 +0300

Scott Fluhrer (sfluhrer) writes:
> How is that behavior fundamentally different from the behavior we
> would get if the attacker inserted a valid, but different KEr*
> payload?  In that case, the tests will pass, and we'll perform the
> DH, and come up with incorrect SKEYSEED. 

Not that much difference, but for those RFC5996 already has text
saying you can process multiple KEr's if you want to:

----------------------------------------------------------------------
2.4.  State Synchronization and Connection Timeouts
...
   There is a DoS attack on the initiator of an IKE SA that can be
   avoided if the initiator takes the proper care.  Since the first two
   messages of an SA setup are not cryptographically protected, an
   attacker could respond to the initiator's message before the genuine
   responder and poison the connection setup attempt.  To prevent this,
   the initiator MAY be willing to accept multiple responses to its
   first message, treat each as potentially legitimate, respond to it,
   and then discard all the invalid half-open connections when it
   receives a valid cryptographically protected response to any one of
   its requests.  Once a cryptographically valid response is received,
   all subsequent responses should be ignored whether or not they are
   cryptographically valid.
----------------------------------------------------------------------

I.e. implementation is allowed to fork the IKE SA creation at that
point and process all of the branches and see which one of them leads
to the valid authenticated IKE SA. I do not think any of the
implementations actually do that, but it is allowed.

The current text in the dh-checks would overwrite that and as it says
the whole IKE SA MUST be dropped, (not only the offending message),
that would open new DoS and prevent using the solution offered for it
in the RFC5996.

> If the real responder will then send the correct "HDR, SAr1, KEr,
> Nr, [CERTREQ]", well, the initiator has already received its
> response and generated some SKEYSEEDs.  I wasn't aware that it was a
> requirement that the initiator create multiple SKEYSEEDs if it
> happens to receive multiple initial exchange 2 messages.

As you can read from above, there is no REQUIREMENT to do that, but it
is allowed. The text in the dh-checks would forbid that...

> For an attacker's point of view, the behavior he gets by sending
> valid KEr* payloads is even more advantageous; he has not only
> prevented the SA from being created, he also forced the initiator to
> do more work before doing so.

Yep. 

> There isn't a real requirement to discard the parent IKE SA; of
> course, we can't allow the creation of the child SA. 

The problem is that if this is noticed in the Initiator then the
Responder has already created Child SA, but Initiator cannot create
it. Thus Child SA state is out of sync, and the general solution for
that in the IKEv2 is to restart the IKE SA, i.e. delete IKE SA and
start over.

As here the other end cannot be unauthenticated, this is most likely
caused by a bug in the implementation and restarting might or might
not help, but at least that does not cause black hole problems. 

> While I don't think the below text is wrong (except I would point
> out that there is no security requirement to discard the parent IKE
> SA during a test failure while generating a child SA), I would also
> point out that these don't appear to have any advantage over the
> current text. 

There is no security requirement to discard IKE SA, but there
operatinal reasons to do it. I.e. that would be clear indication that
something is wrong, thus most likely will cause one of the peers to
start investingating the problem, especially if it is persistent
problem. On the other hand if the problem is not persistent, and is
fixed by starting IKE SA over, then even better...
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Apr 2013 07:56:49 -0700

> fixed by starting IKE SA over, then even better...

It would be useful to add one or two sentences to the draft explaining that the discarding is for operational, not security, reasons.

--Paul Hoffman