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

[Tero Kivinen <[e-mail]>]

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.
...
-- 
[e-mail]