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

["Dan Harkins" <[e-mail]>]

  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.