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

Re: The remaining IKEv2 issues



On Wed, Aug 20, 2003 at 10:15:06AM -0500, Tylor Allison wrote:
> 
> As defined and used within IKEv2, these methods are secure, though, aren't
> they?  (OK, not as secure as kg methods...) To mount the MITM attack on
> IKEv2, you have to have the Initiator not verify the responder/gateway's
> identity... that sounds like a broken client implementation.  There's been
> quite a bit of discussion about using MITM attacks on the AAA server which
> is listening for the EAP-GTC (or otherwise plaintext EAP messages) that
> could occur between the IKEv2 server and the AAA server.  But this assumes
> that EAP is being used to communicate with the AAA server... other
> protocols may be used by the IKEv2 gateway instead.

They are secure *if* there are no other protocols that might be using
EAP in an unprotected fashion.  For example, if someone had a set of
dialup modems that were connected using the PPP servers using a RS-232
over TCP/IP protocol, and the attacker had access to the LAN segment
between the dialup modems and the PPP server, then they could get
access to the plaintext EAP message.

There seems to be some question how often an attacker in a realistic
threat environment would be able to access the unprotected EAP packets.  

To be fair to the other side however, the danger is that an
administrator won't realize that some other application is using EAP
in an unprotected fashion, and one gets introduced later on.  Of
course, if one assumes a MITM attack, one can intercept an unecrypted
telnet session where the user logs in using a SecureID card, for
example, and they could simply steal the SecureID authentication
exchange, and use it either for another telnet session, or insert it
into a EAP packet and use it to authenticate an IKE exchange into the
firewall.

The question is whether or not the existence of such an attack means
that we should not allow the use of SecureID card (or any other token
authenticators) with IKE, given that they are very often used in
unprotected network connections.  Obviously the fault is with the use
of the token authentication system in unencrypted protocols, but
perhaps that means we shouldn't allow them in IKE at all.  

The flip side of the argument is that we've already tried telling
customers that they should use certificates, and this has gone over
like a lead balloon.

						- Ted