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

[Paul Hoffman <[e-mail]>]

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