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

[Paul Hoffman <[e-mail]>]

At 12:12 PM -0800 3/2/10, Dan Harkins wrote:
>  There are other criteria that should be evaluated in making a
>decision, such as how well does the solution fits into IKE(v2) and
>does it support "crypto agility".

...and what we mean by "agility". To some, that means "in-protocol negotiation of parameters", but to others it means "have enough variants of the algorithm with different parameters to meet some security threshold".

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

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

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

>  Also, the table in section 5 should include IEEE 802.11s under the
>"standards" column for SPSK. And the phrase "may or may not infringe on
>existing patents" applies to all candidates, and frankly, to almost
>everything in the IETF. It is a meaningless phrase and it would be better
>to just remove it from the "IPR" column.

+1

--Paul Hoffman, Director
--VPN Consortium