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

Tero Kivinen <kivinen@iki.fi> Tue, 02 April 2013 13:06 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A69F21F8E4C for <ipsec@ietfa.amsl.com>; Tue, 2 Apr 2013 06:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rTCwe0y9jil for <ipsec@ietfa.amsl.com>; Tue, 2 Apr 2013 06:06:34 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEA421F8D94 for <ipsec@ietf.org>; Tue, 2 Apr 2013 06:06:29 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r32D6Pvp010139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Tue, 2 Apr 2013 16:06:25 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r32D6PgL001054; Tue, 2 Apr 2013 16:06:25 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <20826.55248.860637.210630@fireball.kivinen.iki.fi>
Date: Tue, 2 Apr 2013 16:06:24 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 34 min
X-Total-Time: 33 min
Subject: [IPsec] Some comments to draft-ietf-ipsecme-dh-checks-01
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 13:06:35 -0000

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.
...
-- 
kivinen@iki.fi