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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
