Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2

"Dan Harkins" <dharkins@lounge.org> Wed, 03 March 2010 00:55 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53DC23A89F9 for <ipsec@core3.amsl.com>; Tue, 2 Mar 2010 16:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.165
X-Spam-Level:
X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.100, 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 fLjC+pwE11cD for <ipsec@core3.amsl.com>; Tue, 2 Mar 2010 16:55:32 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 326EF3A8881 for <ipsec@ietf.org>; Tue, 2 Mar 2010 16:55:32 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 826461022404A; Tue, 2 Mar 2010 16:48:07 -0800 (PST)
Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 2 Mar 2010 16:48:07 -0800 (PST)
Message-ID: <c36ec1cf807c114079f5090c659af8c5.squirrel@www.trepanning.net>
In-Reply-To: <C2D311A6F086424F99E385949ECFEBCB01C7551E@CORPUSMX80B.corp.emc.com>
References: <p0624081ac7b20a6459c5@[10.20.30.158]><3a17cf9ee724023e307fc446a871f9bf.squirrel@www.trepanning.net><p06240812c7b33427a351@[10.20.30.158]> <bcc4d01cd3d8be09590e22bc5066bab2.squirrel@www.trepanning.net> <C2D311A6F086424F99E385949ECFEBCB01C7551E@CORPUSMX80B.corp.emc.com>
Date: Tue, 02 Mar 2010 16:48:07 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Black_David@emc.com
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: ipsec@ietf.org, cfrg@irtf.org, paul.hoffman@vpnc.org
Subject: Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 03 Mar 2010 00:55:32 -0000

  Hi David,


On Tue, March 2, 2010 3:49 pm, Black_David@emc.com wrote:
[snip]
>
> OTOH, I think you've oversimplified here ...
>
>>   The candidate exchanges all rely on the "hard problem" of doing a
>> discrete logarithm in one of the defined groups. It's the same "hard
>> problem" that makes the Diffie-Hellman portion of IKE secure. If the
>> group negotiated or demanded in IKE allows for an "easier attack" then
>> it shouldn't be used in the IKE exchange to do the Diffie-Hellman.
>
> If I follow your logic, I think you're arguing that because the existing
> groups allow easier attacks on password authentication (e.g., based on
> checks on what a guessed password decrypts to) then they allow easier
> attacks on IKE with existing authentication, *hence* those groups are
> unacceptable to use with IKE.  I think the *hence* is off the mark due to
> the much larger candidate search space when other techniques (e.g.,
> certificate-based) are used to authenticate.

  That wasn't what I was arguing. I think all the candidate exchanges
are based on the computational Diffie-Hellman assumption. And the
work factor to attack them on that front should be the same as the
work factor to attack a standard Diffie-Hellman key exchange. Or am
I missing something?

  I don't think any of the currently-defined groups are unacceptable
to use with IKE. But hypothetically, if there was some group defined
that allowed an easy attack (the order was unacceptably small, for
instance) then it would be unsuitable for IKE just like it would be
unsuitable for any of the candidate password authentication schemes.

  For these password authentication schemes to be secure, the only method
of attack is repeated active guessing attacks of the password (the
advantage an attacker gains is through interaction, not computation).
An "easier attack" is an off-line dictionary attack to learn the password
(the advantage gained is through computation) and using any of the groups
in IKE(v2)'s IANA registry with EKE would enable a dictionary attack.
But the attacker doesn't learn the ephemeral secret that results from
EKE, the CDH assumption still applies. The issue isn't with the group,
per se, it's with the (mis)use of the group.

  regards,

  Dan.