Yes I mean other protocols potentially covered by EKE patent. Regards, Uri
----- Original Message ----- From: Steven M. Bellovin <s...@cs.columbia.edu> To: Blumenthal, Uri - 0662 - MITLL Cc: 'dhark...@lounge.org' <dhark...@lounge.org>; 'ipsec@ietf.org' <ipsec@ietf.org>; 'c...@irtf.org' <c...@irtf.org>; 'black_da...@emc.com' <black_da...@emc.com>; 'paul.hoff...@vpnc.org' <paul.hoff...@vpnc.org> Sent: Wed Mar 03 11:05:07 2010 Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2 On Wed, 3 Mar 2010 09:30:53 -0500 "Blumenthal, Uri - 0662 - MITLL" <u...@ll.mit.edu> wrote: > A reasonable question is - do all the proposed "EKE variations" have > the same requirement (and the same weakness)? Or only the original > EKE does? > I'm not sure what you mean by "EKE variants" -- all of the variants in the original paper except for the main one (which was also the first) -- are now known to be insecure. Do you mean other PAKE protocols? I suspect that any PAKE protocol that relies on the lack of verifiable plaintext would have the same requirement; the form, however, may differ. The specific example I gave in my original note, quoted below, is specific to EKE, but it's far from the only conceivable attack. We're going to have to look at any proposal very carefully, with this in mind. > ----- Original Message ----- > From: cfrg-boun...@irtf.org <cfrg-boun...@irtf.org> > To: Dan Harkins <dhark...@lounge.org> > Cc: ipsec@ietf.org <ipsec@ietf.org>; c...@irtf.org <c...@irtf.org>; > black_da...@emc.com <black_da...@emc.com>; paul.hoff...@vpnc.org > <paul.hoff...@vpnc.org> Sent: Tue Mar 02 19:58:35 2010 Subject: Re: > [Cfrg] [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 > > On Tue, 2 Mar 2010 16:48:07 -0800 (PST) > "Dan Harkins" <dhark...@lounge.org> wrote: > > > > > Hi David, > > > > > > On Tue, March 2, 2010 3:49 pm, black_da...@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. > _______________________________________________ > Cfrg mailing list > c...@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > _______________________________________________ > Cfrg mailing list > c...@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
