Re: The remaining IKEv2 issues

[Yoav Nir <ynir@CheckPoint.com>]

As many times as I read that article, I can't see how this is a 
problem.  It makes a very strong assumption, that EAP methods are used 
outside of secure tunnels.  IMO this is not true:

- The easiest case is the user/password.  This could be handled using 
EAP-MD5 or EAP-GTC.  In an average company, the user/password 
combination is used to log in to your workstation, to log in to 
servers, or to connect from home or while on the road.  You do not use 
it from home to do things that are not related to IKE.  When at work, 
you log on to the Windows domain controller or to some RADIUS server, 
but you do not use EAP.  The only cases where you actually use EAP is 
when connecting to a wireless LAN equipped with 802.1x or when 
connecting to a relatively new RAS.  These RAS usually also use 
L2TP/IPsec, so that's not snoopable either.  In short, I don't see the 
case where the user will pass their password through unprotected GTC.  
Since both GTC and MD5 are not good protection for passwords, it is up 
to the administrator to prevent these methods from being used in 
unprotected tunnels.

- Another case is the one-time password.  Here, the danger is real, 
although the user will notice that the authentication failed.

- An other case is the SecurID.  This will be done either by GTC or by 
SecurID's own EAP methods.  Both are non-kg.  Again I have to ask, why 
would anyone do GTC in an open channel?  You authenticate either inside 
your corporate network, or else at home for IPsec.  The case of a 
university where a lot of students have access to the network simply 
says that you should use IPsec or at least some kind of tunneled EAP 
such as PEAP or TTLS.  The administrator should not allow users to use 
non-kg methods outside tunnels.

To sum it up, I believe that it should be left to administrators to use 
EAP methods appropriately, i.e. not use the same non-kg method both in 
tunnels and in the clear.  That responsibility should not fall on IKE 
implementors.  They SHOULD, however, warn their customers about the 
dangers.

On Tuesday, August 19, 2003, at 06:23 AM, Theodore Ts'o wrote:
<snip>
> 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.