Hi Jari, You're right that implementing a "weak shared secret" EAP method (both the EAP peer and EAP server roles) on both IPsec nodes, combined with the "EAP mutual authentication" work item (also in the new charter) could be used in this situation, and would result in roughly the same functionality (perhaps with slightly more roundtrips/other overhead -- but that's probably not a critical factor here). The WG discussed this at length (both in Hiroshima and on the list afterwards), and the general feeling was that having a simple IKEv2-only solution would still be desirable, and could be more likely to get implemented/deployed in situations that currently don't use EAP. Perhaps the currently proposed text is slightly misleading about this; it could be read to say that EAP would not work. As we discussed on the IESG telechat earlier today, that paragraph would benefit from slightly more clearer explanation, e.g: OLD: 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. NEW: 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. Comments? Best regards, Pasi > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > ext Jari Arkko > Sent: 16 February, 2010 14:08 > To: IETF Discussion > Subject: Re: WG Review: Recharter of IP Security Maintenance and > Extensions (ipsecme) > > 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf