Re: The remaining IKEv2 issues

[Jari Arkko <jari.arkko@kolumbus.fi>]

Yoav Nir wrote:
> 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 

1) Its snoopable/mitmable from the client to the RAS. Sure, it may
not be an IP network, but nevertheless...

2) Its snoopable/mitmable in the wireless LAN. New wireless LAN
standards require kg methods, but I'm not sure if this holds true
of all previous standards and products.

> will pass their password through unprotected GTC.  Since both GTC and 

3) If the <whatever> box that runs EAP talks RADIUS, it is not
certain that the RADIUS communication is encrypted. For PAP/CHAP
there's a lame encryption scheme, but for EAP there isn't since
EAP methods are expected to be secure by themselves. A recent
update of the RADIUS RFCs upgraded IPsec support to a SHOULD,
but common industry practise appears to be (like it or not)
that the lame scheme is enough.

> MD5 are not good protection for passwords, it is up to the administrator 
> to prevent these methods from being used in unprotected tunnels.

--Jari