Re: Secure legacy authentication for IKEv2

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

Dan,

Are you claiming, for example, that SLA-OTP is not susceptible to MitM
attacks if the same passwords are used under EAP-OTP (same for CHAP,
secure-ID, etc)? Or is there something special about EAP-SIM (which I am
not familiar with) on which you base your argument below?

In any case, if you consider legacy methods such as CHAP, OTP etc
then the use of EAP-CHAP, EAP-OTP, etc  in mixed protected/unprotected 
runs is insecure with SLA regardless of the "wrapping" mechanism you use to 
transport the authentication information in SLA (i.e it makes no difference
for the sake of these MitM attacks if you have specialized formats or use
EAP in SLA). 

Note that the fact that the unprotected run wraps the chalenges and
responses under a EAP construct does not mean that the attacker cannot
unwrap this information and re-format it under SLA.  For example, if
you talk EAP-OTP in the clear then I can attack the "protected" SLA-OTP
simply by reading the one-time-pad from the unprotected EAP-OTP run.  
Once I have that otp, SLA has nothing to do to protect the server against
impersonation.

If you agree with the above and still keep your objections against using 
EAP then please explain again why.

Regarding "stupid practices" see below

On Sun, 29 Dec 2002, Dan Harkins wrote:

>   Hugo,
> 
>   The problem with using EAP (that SLA doesn't have) is that EAP all
> by itself is a perfectly legitimate way to do good, strong, mutual
> authentication and therefore it is easy to launch the authentication
> binding attack by inducing the client to speak that EAP method all
> by itself.
> 
>   Quite a few EAP methods-- EAP-SIM for instance-- provide mutual
> authentication (and key generation) and speaking EAP-SIM by itself is
> a perfectly legitimate thing to do. SIM cards are used in mobile 
> phones and in wireless NIC cards today. They'll be used in more things
> tomorrow. The more they're used the more willing a client will be
> to speak EAP-SIM all by itself, and therefore the easier it will be
> for an attacker to tunnel it to a server who is only willing to speak
> a tunneled version of EAP-SIM. Ditto for EAP-TLS. (And yes, there are
> implementations today that do EAP-TLS-encapsulated EAP-TLS).
> 
>   But how could someone be induced into encapsulating its legacay
> authentication protocol in some format that is specific for SLA and
> thereby enable the authentication binding attack on it? It is
> not a legitimate authentication encapsulation all by itself.
> 
>   The authentication binding attack is possible on SLA only if the
> client is doing something that she should not be doing in the first
> place-- like providing her credentials to anyone who asks. It's
> possible for anything to be attacked if the client is doing something
> insecure! A password of "password", a PIN for a token card written on
> a the token card itself.
> 
>   In another email you wrote that in these attacks the attacker:
> 
> "(a) impersonates the server to the client in the unprotected run (we are
> talking of legacy authentication methods that do NOT authenticate the
> server so this impersonation is possible)"
> 
> Yes, it's possible. It's possible to write the PIN on the token card
> and leave it lying around and thereby leave one open to "attack". But
> we can't protect against things that are predicated on the client
> doing a patently insecure thing in the first place. It's possible to
> steal the contents of a locked car if the windows are down. Is that
> an "attack" against the lock, or does that, by itself, mean the lock
> is somehow ineffective? No, it means the owner did something stupid
> to eliminate the security afforded by other mechanisms.

I am not sure what exactly you are ridiculizing here.
Are you saying that the mixed protected/unprotected runs we are discussing
are a "stupid practice" and then there is no reason for us to address them?
This is indeed one of the options I enumerated in a previous email for
solving (or not solving) this issue.  On the other hand, I guess that many
people using legacy authentication may want to keep the "stupid practice" of
mixed runs and get as much defense as they can in the protected runs.

In one way or another I do not see that the use of EAP in SLA makes things
worse.

Hugo

> 
>   Dan.