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

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
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Dan Harkins
> Sent: Tuesday, March 02, 2010 5:55 PM
> To: Paul Hoffman
> Cc: IPsecme WG; cfrg@irtf.org; 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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec