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

"Steven M. Bellovin" <smb@cs.columbia.edu> Wed, 03 March 2010 00:58 UTC

Return-Path: <smb@cs.columbia.edu>
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 3A9FC28C287 for <ipsec@core3.amsl.com>; Tue, 2 Mar 2010 16:58:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Level:
X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, 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 fEjHzkaf6eVZ for <ipsec@core3.amsl.com>; Tue, 2 Mar 2010 16:58:41 -0800 (PST)
Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 2EF713A8863 for <ipsec@ietf.org>; Tue, 2 Mar 2010 16:58:41 -0800 (PST)
Received: by machshav.com (Postfix, from userid 512) id D837E52D3FB; Tue, 2 Mar 2010 19:58:43 -0500 (EST)
Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 627E752D3E9; Tue, 2 Mar 2010 19:58:43 -0500 (EST)
Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 47832293D07; Tue, 2 Mar 2010 19:58:36 -0500 (EST)
Date: Tue, 02 Mar 2010 19:58:35 -0500
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: Dan Harkins <dharkins@lounge.org>
Message-ID: <20100302195835.07e66c4e@yellowstone.machshav.com>
In-Reply-To: <c36ec1cf807c114079f5090c659af8c5.squirrel@www.trepanning.net>
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> <c36ec1cf807c114079f5090c659af8c5.squirrel@www.trepanning.net>
Organization: Columbia University
X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64--netbsd)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org, cfrg@irtf.org, Black_David@emc.com, paul.hoffman@vpnc.org
Subject: Re: [IPsec] [Cfrg] 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:58:42 -0000

On Tue, 2 Mar 2010 16:48:07 -0800 (PST)
"Dan Harkins" <dharkins@lounge.org> wrote:

> 
>   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.
> 
Right.  In the original EKE paper, we called this a "partition
attack".  There are others possible; it's important to take care to
avoid them.  For example, suppose that we wanted a ~2048-bit -- 256 byte
-- modulus.  Choosing a modulus of 2040 bits, though about the same
difficulty when it comes to solving discrete log, is unacceptable for
EKE, because in a correct guess the high-order byte would be all zeros;
an incorrect guess would, with probability 255/256, let you rule out a
candidate password.  A good EKE modulus would be close enough to 2^2048
to have a negligible probability of a decryption with a bad guess being
in the range [p, 2^2048-1].  In other words, good moduli for EKE have
specialized properties.