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.
- [IPsec] Beginning discussion on secure password-o… Paul Hoffman
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Hannes Tschofenig
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Paul Hoffman
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Steven M. Bellovin
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Yaron Sheffer
- Re: [IPsec] Beginning discussion on secure passwo… Dan Harkins
- Re: [IPsec] Beginning discussion on secure passwo… Yaron Sheffer
- Re: [IPsec] Beginning discussion on secure passwo… Paul Hoffman
- Re: [IPsec] Beginning discussion on secure passwo… Dan Harkins
- Re: [IPsec] Beginning discussion on secure passwo… Dan Harkins
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- Re: [IPsec] Beginning discussion on secure passwo… Black_David
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Steven M. Bellovin
- Re: [IPsec] Beginning discussion on secure passwo… Dan Harkins
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Steven M. Bellovin
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Black_David
- Re: [IPsec] Beginning discussion on secure passwo… Yaron Sheffer
- Re: [IPsec] Beginning discussion on secure passwo… Yoav Nir
- Re: [IPsec] Beginning discussion on secure passwo… Tero Kivinen
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- Re: [IPsec] [Cfrg] Beginning discussion on secure… thomwu
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Steven M. Bellovin
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- [IPsec] [Fwd: Re: Beginning discussion on secure … Dan Harkins
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Dan Harkins
- [IPsec] [Fwd: Re: Beginning discussion on secure … Dan Harkins
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Black_David
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Blumenthal, Uri - 0662 - MITLL
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Yaron Sheffer
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Yoav Nir
- Re: [IPsec] [Cfrg] Beginning discussion on secure… Yaron Sheffer