Re: The remaining IKEv2 issues

[Tylor Allison <allison@securecomputing.com>]

So the MITM attack on non-kg methods is possible for EAP messages being
transmitted outside of IKEv2 (e.g. not between IPsec peers), and occurs
because either the EAP messages are being passed in the clear, or the
server in a protected EAP protocol (e.g. PEAP) is not being authenticated
properly.

Why not make doing this a MUST NOT?  Aren't there many ways to make non-kg
EAP methods protected from MITM?  How about:

    o   Securing the EAP with another protocol (PEAP, others).

    o   Securing the network that the auth server is on (e.g. dedicated
        network for the server)

    o   Having IKEv2 peers consume the EAP messages directly ... e.g for
        small scale deployments, the IKEv2 firewall could locally manage a
        small set of user/passwords.

        Another example is that the firewall consumes the EAP messages and
        translates to other (proprietary) security protocols to communicate
        to the authentication servers.

Unless I'm misunderstanding the vulnerability, I think any of these may be
viable, and, as Ted points out, many IKEv2 vendors may be forced to provide
one or more of these solutions to customers with existing legacy auth servers.

My vote... I'm not sure I like the choices.  I would like to see a warning
in the draft regarding the use of EAP outside of IKEv2 (transmissions to
auth server), stating that this transmission needs to be secured.  But
perhaps that should be obvious to implementors and isn't needed?  I don't
want either of the "SHOULD NOT" or "MUST NOT" options.  I think there's
valid reasons why these legacy auth methods need to be supported, and there
are ways to make them secure.

Regards,

Tylor Allison

On Mon, 18 Aug 2003, 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, 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