Re: Last Call: <draft-kuegler-ipsecme-pace-ikev2-05.txt> (Password Authenticated Connection Establishment with IKEv2) to Experimental RFC

"Dan Harkins" <dharkins@lounge.org> Mon, 28 March 2011 12:08 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BD23A6811 for <ietf@core3.amsl.com>; Mon, 28 Mar 2011 05:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP-bFQIPF6-F for <ietf@core3.amsl.com>; Mon, 28 Mar 2011 05:08:47 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id DF1933A67DF for <ietf@ietf.org>; Mon, 28 Mar 2011 05:08:47 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 83A981022404E; Mon, 28 Mar 2011 05:10:25 -0700 (PDT)
Received: from 130.129.83.144 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 28 Mar 2011 05:10:25 -0700 (PDT)
Message-ID: <8824020844b823b1419edbc142b831df.squirrel@www.trepanning.net>
Date: Mon, 28 Mar 2011 05:10:25 -0700
Subject: Re: Last Call: <draft-kuegler-ipsecme-pace-ikev2-05.txt> (Password Authenticated Connection Establishment with IKEv2) to Experimental RFC
From: Dan Harkins <dharkins@lounge.org>
To: ietf@ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: draft-kuegler-ipsecme-pace-ikev2@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2011 12:08:49 -0000

  Hello,

  I believe there is a problem with this draft that can void a claimed
security property: namely, resistance to dictionary attack. The issue is
not with the underlying key exchange itself, but with the way the key
exchange was added to IKEv2.

  In this protocol, a random nonce is encrypted using the encryption
algorithm negotiated in IKEv2 with a key that is based on a password
and data known to an adversary launching an active attack. The initiator
of the protocol produces the encrypted random nonce and sends it to the
responder. If an adversary, acting as the responder, is able to determine
whether a decryption of the nonce is successful he is able to launch an
off-line dictionary attack.

  When the negotiated encryption algorithm is used in an authenticated
encryption mode, like -GCM or -CCM, an integrity check value (ICV) is
encoded into the ciphertext produced by the encryption operation (see
RFC 5282). This provides a way for an adversary to determine whether a
decryption was successful and therefore whether the guessed password is
correct. The attack is simply to try each candidate password from the
dictionary, use it to compute a candidate key, and if the authenticated
decryption operation using the candidate key does not return FAIL then
exit, the password has been found.

  There are many ways to address this issue. The simplest would be
to just forbid use of an AAD cipher mode when using this method of
authentication. That would be regrettable though due to the wide appeal
of GCM (less so with CCM). A better solution would be to just use ECB
mode of the underlying block cipher. The nonce is uniformly random and
there is no need to inject additional randomness into the encryption
operation (i.e. no IV needed).

  I feel it is necessary to fix this issue before publication.

  regards,

  Dan.

On Sat, 26 Mar 2011 09:38:11 -0700, the IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>-  'Password Authenticated Connection Establishment with IKEv2'
>   <draft-kuegler-ipsecme-pace-ikev2-05.txt> as an Experimental RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf at ietf.org mailing lists by 2011-04-23. Exceptionally, comments
may be
> sent to iesg at ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/
>
>
>
> No IPR declarations have been submitted directly on this I-D.