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

<Black_David@emc.com> Wed, 03 March 2010 01:18 UTC

Return-Path: <Black_David@emc.com>
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 BB90B28C1F8; Tue, 2 Mar 2010 17:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rFbs7zM82g6p; Tue, 2 Mar 2010 17:17:59 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B92113A8CFF; Tue, 2 Mar 2010 17:17:59 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id o231HrYV019757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 20:17:53 -0500
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Mar 2010 20:17:45 -0500
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o231HjqS032202; Tue, 2 Mar 2010 20:17:45 -0500
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.202]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 20:17:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 02 Mar 2010 20:17:44 -0500
Message-ID: <C2D311A6F086424F99E385949ECFEBCB01D1DF7E@CORPUSMX80B.corp.emc.com>
In-Reply-To: <20100302195835.07e66c4e@yellowstone.machshav.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2
Thread-Index: Acq6bKy+5oQXVB2WTXSuRtcZQnK7jAAAbysg
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> <20100302195835.07e66c4e@yellowstone.machshav.com>
From: Black_David@emc.com
To: smb@cs.columbia.edu, dharkins@lounge.org
X-OriginalArrivalTime: 03 Mar 2010 01:17:45.0097 (UTC) FILETIME=[543E0F90:01CABA6F]
X-EMM-EM: Active
Cc: ipsec@ietf.org, cfrg@irtf.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 01:18:01 -0000

> > >>   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.

That's roughly what I understood - good groups for EKE should be good
groups for IKE, but good groups for IKE (e.g., the existing groups) are
not necessarily good groups for EKE because they may not have the
specialized properties required to block additional attacks on EKE that
don't apply to IKE.

It appears like Dan agrees, so I may have misinterpreted what he
originally wrote.

Thanks,
--David