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

Jari Arkko <jari.arkko@piuha.net> Tue, 16 February 2010 12:06 UTC

Message-ID: <4B7A8A8E.3030704@piuha.net>
Date: Tue, 16 Feb 2010 14:07:42 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>
Subject: Re: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
References: <20100209190003.025AE3A75BF@core3.amsl.com>
In-Reply-To: <20100209190003.025AE3A75BF@core3.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Precedence: list

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

Re: WG Review: Recharter of IP Security Maintenan… Jari Arkko
Re: WG Review: Recharter of IP Security Maintenan… Jari Arkko
Re: WG Review: Recharter of IP Security Maintenan… Alfred Hönes
RE: WG Review: Recharter of IP Security Maintenan… Pasi.Eronen
Re: WG Review: Recharter of IP Security Maintenan… Jari Arkko
Re: WG Review: Recharter of IP Security Maintenan… Dan Harkins
Re: WG Review: Recharter of IP Security Maintenan… Bernard Aboba