Nico Williams writes: > I believe you are wrong about that. Evidence: SCRAM (RFC5802). > > If you look at SCRAM you'll see that it's exceedingly simple -- it's a > pre-shared password type mechanism, loosely resembling DIGEST-MD5.
I have not yet read the SCRAM, but based on the discussion on the secdir list, I think you were missing some points of this discussion in here too. All of these 3 (hush is withdrawn as pointed out to me) methods we are discussing here are ZKPP. IPsecME charter says: ---------------------------------------------------------------------- - 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. ---------------------------------------------------------------------- So the major points are: - Machine to machine communication (i.e. no user) - Weak password created by admins and entered to the configs - Symmetric nature, i.e. either end can initiate communications, there is no server and client roles - Needs to be secure against off-line dictionary attacks even against active attackers - No certificate support required - No AAA infrastructure required > All the GSS aspects of SCRAM are segregated into a small, clean > section. You'd mostly not have to concern yourself with it because I > volunteer to write that for you :) If I understood your comments in the secdir list correctly SCRAM does not fill all of those requirements? -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
