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

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

  Hello,

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

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

  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.

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

  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.

  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.

  regards,

  Dan.

On Mon, March 1, 2010 4:34 pm, Paul Hoffman wrote:
> Greetings again. This message is cross-posted to both the IPsecME WG and
> the CFRG because it pertains to both groups.
>
> The recently-revised IPsecME charter has a new work item in it:
>
> ==========
> - IKEv2 supports mutual authentication with a shared secret, but this
> mechanism is intended for "strong" shared secrets. User-chosen
> passwords are typically of low entropy and subject to off-line
> dictionary attacks when used with this mechanism. Thus, RFC 4306
> recommends using EAP with public-key based authentication of the
> responder instead. This approach would be typically used in enterprise
> remote access VPN scenarios where the VPN gateway does not usually
> even have the actual passwords for all users, but instead typically
> communicates with a back-end RADIUS server.
>
> However, user-configured shared secrets are still useful for many
> other IPsec scenarios, such as authentication between two servers or
> routers. These scenarios are usually symmetric: both peers know the
> shared secret, no back-end authentication servers are involved, and
> either peer can initiate an IKEv2 SA. While it would be possible to
> use EAP in such situations (by having both peers implement both the
> EAP peer and the EAP server roles of an EAP method intended for "weak"
> shared secrets) with the mutual EAP-based authentication work item
> (above), a simpler solution may be desirable in many situations.
>
> The WG will develop a standards-track extension to IKEv2 to allow
> mutual authentication based on "weak" (low-entropy) shared
> secrets. The goal is to avoid off-line dictionary attacks without
> requiring the use of certificates or EAP. There are many
> already-developed algorithms that can be used, and the WG would need
> to pick one that both is believed to be secure and is believed to have
> acceptable intellectual property features. The WG would also need to
> develop the protocol to use the chosen algorithm in IKEv2 in a secure
> fashion. It is noted up front that this work item poses a higher
> chance of failing to be completed than other WG work items; this is
> balanced by the very high expected value of the extension if it is
> standardized and deployed.
> ==========
>
> As the last paragraph says, there are multiple algorithms to choose from.
> Different algorithms have different properties. Before the WG decides on
> which algorithm to focus on, it needs to at least roughly decide which
> properties are important for the new protocol. I have included the CFRG on
> this message because they are a good source of expertise on cryptographic
> properties.
>
> Yaron Sheffer has created a short and admittedly biased draft listing some
> desired properties and possible candidate algorithms:
> <http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-pake-criteria-00.txt>.
> Other people (and even Yaron) might have different views on which
> properties are important, how the properties should be ranked, the
> importance of the crypto properties of the listed algorithms, and so on.
>
> This message is therefore meant to kick off the discussion. It is OK for
> messages to focus on one or more of the proposed algorithms, but getting a
> clearer view of which crypto and non-crypto properties are important is
> probably more important first.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>