Dan, > >> For instance, I do not believe EKE is suitable for any of the > >>groups currently in the IANA registry of groups that can be used with > >>IKE(v2).
There was an analogous experience with SRP for iSCSI - completely different groups were used up to 2048 bits and beyond there, the modulus primes from the larger IKEv2 groups were combined with different generators (i.e., not 2) - see Appendix A of RFC 3723. [... 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. > And > if the group is good enough to use for the Diffie-Hellman key exchange > then, by definition, it is good enough for password authentication. No argument here, but I don't think that statement implies its converse. [... snip ..] > I think there is value in being able to use the same group (a lesson > learned from IKEv1 is that not everything needs to be negotiated and the > increase in complexity just isn't worth it). Some may find value in > negotiating groups separately. Whatever. But I think this should be > included in the criteria for selection so we can discuss the pros and > cons. I would agree with that - the ability to use the existing groups should be a plus for evaluation. I'd also suggest that if new groups are defined for password authentication, those groups ought to be usable for IKE as well *provided that* the resulting negotiation complexity doesn't get out of hand. I don't think we can retire/replace the existing groups, and I don't think you're suggesting that. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [email protected] Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Dan > Harkins > Sent: Tuesday, March 02, 2010 5:55 PM > To: Paul Hoffman > Cc: IPsecme WG; [email protected]; Dan Harkins > Subject: Re: [IPsec] Beginning discussion on secure password-only > authentication for IKEv2 > > > Hi Paul, > > On Tue, March 2, 2010 1:37 pm, Paul Hoffman wrote: > [snip] > >> RFC 2409 supported negotiation of various parameters, like the group > >>used for the Diffie-Hellman key exchange. That was removed in RFC 4306. > >>All of the candidate exchanges listed in draft-sheffer-ipsecme-pake- > >>criteria do some sort of discrete logarithm cryptography and therefore > >>it would be useful to list whether the candidate algorithm can use > >>any of the groups either negotiated or asserted by IKE(v2). > > > > OK, but... > > > >> For instance, I do not believe EKE is suitable for any of the > >>groups currently in the IANA registry of groups that can be used with > >>IKE(v2). The MODP groups have a generator that is a quadratic residue > >>which enables a passive attacker to eliminate passwords from the > >>dictionary if they do not decrypt to a value that is, itself, a quadratic > >>residue and ECP groups are unsuitable because a passive attacker can > >>eliminate passwords from the group if they do not decrypt to a valid > >> point > >>on the curve. In either case, after seeing a trivial number of exchanges > >>a passive attacker is able to determine the password with high > >> probability. > > > > Those two paragraphs don't line up. Why would you want to use the groups > > negotiated or demanded in the IKEv2 exchange if they allow for easier > > attacks? Wouldn't it be better to allow the PAKE to negotiate or demand > > its own, presumably better, groups? > > 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. And > if the group is good enough to use for the Diffie-Hellman key exchange > then, by definition, it is good enough for password authentication. > > If someone wants to use a 521-bit ECP group for the Diffie-Hellman key > exchange then requiring him to use a 2048-bit MODP group for authentication > seems a bit odd and constraining. It would make more sense, to me at least, > if the same 521-bit ECP group was used for authentication. Substitute the > group based on your own policy or whim-- 192-bit ECP, 8192-bit MODP, > 1024-bit MODP-- and it's still odd and constraining to be forced to use > a different one for authentication. > > I think there is value in being able to use the same group (a lesson > learned from IKEv1 is that not everything needs to be negotiated and the > increase in complexity just isn't worth it). Some may find value in > negotiating groups separately. Whatever. But I think this should be > included in the criteria for selection so we can discuss the pros and > cons. > > >> So EKE requires a hard-coded special group to be used for its discrete > >>logarithm operations and since negotiation has been removed in RFC 4306 > >>it means that the ability to change the group to suit the policy or whim > >>of the user (what is popularly termed "crypto agility") goes away. EKE > >>also requires specification of the mode of encryption used which may or > >>may not be the same as the one negotiated or asserted in IKE(v2). It > >>could be hard-coded into the specification, like the group, but this too > >>further limits "crypto agility". > > > > Yaron disagreed with this assessment. I would like to hear from others > > with EKE experience. > > Yaron points out that EAP-EKE negotiates the special group but we're > not using EAP here so the point he makes is neither here nor there. > > >> The other candidates, I believe, can use the same group, whether MODP > >>or ECP, that the IKE(v2) exchange is using. I think it would be good to > >>add these criteria to the draft. > > > > See above. I think the requirement should be "crypto agility, which means > > X Y Z" unless that agility itself opens up a security hole, such as a > > downgrade attack. > > No downgrade attacks. I agree. An attacker will go after the weakest > point. Which in this case has to be repeated active guessing attack > (which should be easy enough to notice and deal with). > > regards, > > Dan. > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
