This new charter looks great otherwise, but I did have a reaction on this:
- 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. These features make using EAP (with its strict client-server separation) undesirable. 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.
Frankly, I'm not too convinced about the arguments above. First of all, EAP does not require separate back-end servers. And with IKEv2 itself already having to decide which side initiates, I do not see a problem running a password-based EAP method in the same direction.
Also, it is true that a new native scheme is slightly easier to implement on top of IKEv2 than EAP + an EAP method. However, if you look at the issue from a system level, does that mean that you are forced to implement this new scheme *and* EAP, because you already need EAP for many other situations? For someone working with a full-blown, all features supported implementation of IKEv2 this means *more* code, not less.
Perhaps there are some better arguments why you must choose a non-EAP solution. Or maybe the charter should require specific functionality to not dictate the solution by excluding EAP. Or maybe existing standards are already sufficient and we just need guidance on how to apply them in the best way for this problem.
In any case, I would like to understand better why this work is in the charter.
Jari _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf