Re: The remaining IKEv2 issues

[Nicolas Williams <Nicolas.Williams@sun.com>]

On Mon, Aug 18, 2003 at 11:23:06PM -0400, Theodore Ts'o wrote:
> On Mon, Aug 18, 2003 at 05:04:36PM -0400, Michael Richardson wrote:
> > 
> >   My understanding of the MITM attack on non key-generating EAP methods is
> > that nothing we do in IKEv2 prevents this. This is because the attack is
> > not between two IPsec devices, but between different kinds of devices.
> > 
> 
> OK, so, how do we resolve this?
[...]
> Arguments in favor include the originally stated requirement that we
> support legacy password authentication schemes; arguments against are
> that given some operating environments, there may be an EAP tunnelling
> attack, which we shouldn't encourage.  And then of course there's the
> pragmatic observation that no matter whether we say MUST NOT or not,
> it may in the end have little effect on what VPN vendors actually
> choose to ship.

IMO, any non-kg EAPs that also cannot somehow be bound to the IKE_SA KE
should not be allowed ("MUST NOT"), but in a pinch (i.e., no consensus)
"SHOULD NOT," accompanied by LOUD warnings of dire, dire consequences
could do.

> Have I missed any of the arguments either against or for?  If so,
> please speak up, but otherwise, let's just take a straw poll and then
> just decide this one way or another.

Well, I have a use for "anonymous IPsec," that is, unauthenticated IKE
key exchanges.  Anonymous KEs can be rather useful, at least if we
define a "session ID" like SSHv2's[*], then we can bind authentication
at higher network layers (e.g., Secure NFS) to anonymous IPsec
"sessions," thus proving that there is no MITM.

Of course, this is not a solution to the non-kg EAP problem, though it
is related to the solution I offered for [some] challenge/response EAPs.

[*]  Derived from, and thus bound to DH and other KE material of an
initial IKE_SA, and which remains unchanged through subsequent re-keys.

Cheers,

Nico
--