Re: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]