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

Re: The remaining IKEv2 issues



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, my bad.  I didn't recognize issue #65 as being related to the
desire to thwart the tunnel/protocol composition problem, as
documented Asokan, Niemi, and Nyberg:

	http://eprint.iacr.org/2002/163.pdf

I'm embarassed didn't make the connection from going over the mail
messages and the issue tracker.  I suppose I can take some small
comfort (but only a little) in that Charlie and Angelos didn't notice
it either when we discussed things last week.  Thanks for bringing
that to our attention.

OK, so, how do we resolve this?

It's certainly true that in the general case, the EAP tunnelling
attack can be a real problem.  And if only to make ourselves feel
better about not leaving behind what might considered an attractive
nuisance, perhaps we should mark it as a MUST NOT.  With my working
group chair hat off and my security hat on, I think I would have to
agree with that sentiment.

On the other hand, in order to be realistic, we should at least take a
moment to recognize that there is going to be a very strong market
demand for this support, given the assumption by many corporations
that everything behind the firewire is goodness and light and is fully
secure.  In those environments, if the only use of EAP outside of the
firewall is in protected tunnels (such as IKEv2) used to gain access
to the protected intravent via a VPN solution, then this is in fact no
worse than making the original assumption that everything behind the
firewall is safe.  (After all, if the attacker has access to
unprotected EAP transactions happening behind the firewall, then s/he
has no need to try to use this to break a VPN solution trying to gain
access behind the firewall.)

Of course, this is a very silly, stupid assumption, and with my
security directorate hat on, I deplore it as being bad and horrible
and everyone who does this sort of thing ought to be ashamed of
themselves.  Tsk, tsk, tsk.  Taking that hat off for a moment, though,
I can think of a very large number of companies (including cough,
cough, my current employer, and probably many other complanies who
employ members of this working group), who make precisely this
assumption regarding firewalls and the relative security inside
vs. outside the firewall, and who make use of VPN solutions today.

Hence, I suspect that even if we were to very strongly forbid the use
of non-kg EAP mechanisms, the market pressure for vendors to implement
them for in VPN solutions, for applications such as SecureID and even
simple username/password passed to a Radius server (where more
advanced forms of CHAP-like authentication schemese are not an option
thanks to the customer's antiquated legacy infrastructure), will be
very strong indeed.  Of course, with all of this being said, we still
don't necessary have to condone this outcome (even if some of our
employers will either be building, buying, or deploying such
solutions).

So given this, I propose that we open a 48-hour discussion on this
issue.  Should we (a) say nothing about non-kg types, thus implicitly
allowing them, (b) specify that vendors SHOULD NOT use non-kg EAP
types, or (c) specify that vendors MUST NOT use non-kg EAP types?

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.

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.

					- Ted