Re: Secure legacy authentication for IKEv2

[Dan Harkins <dharkins@tibernian.com>]

  Hugo,

  What I'm saying is that providing legacy authentication credentials
in an unprotected run is insecure. Clients should never do that. So for
a second let's forget about attacks that are predecated on obtaining
the credentials via an unprotected run.

  Protocols which tunnel EAP (PEAP, PIC, and SLA if it used EAP) are
still susceptible to attack because the attacker does not need to
obtain the credentials in an unprotected run. All the attacker needs
to do is get the client to speak the EAP method by itself that the
server demands to be tunneled. 

  For instance, server wants PEAP with EAP-TLS as the "sub-protocol".
Client is willing to do PEAP with EAP-TLS as the "sub-protocol" but
would also settle for EAP-TLS by itself. This is entirely reasonable
since EAP-TLS provides strong mutual authentication and generates keys.
The attacker establishes the "outer" PEAP tunnel with the server
masquerading as the client and then merely tunnels the EAP-TLS
conversation from the client to the server. The client thinks it's
doing EAP-TLS by itself the server thinks it's doing PEAP with EAP-TLS
as the "sub-protocol". When the EAP-TLS conversation is finished the 
attacker terminates the connection to the client (perhaps sending
an EAP failure) and now starts impersonating the client with an
authenticated connection to the server. This same thing can happen
with PIC.

  That attack is possible even though the legacy credentials are not
sent in an unprotected run. 

  That is an objection to using EAP.

  To use EAP we would have to do something like use the keys generated
as part of the EAP exchange and mix them with the SKEYSEED blob. We'd
also have to prohibit use of EAP methods which do not generate keys.
But if we do that we've basically wiped out the whole desire of having
this sort of authentication option in IKE in the first place!

  To answer your question about what I'm claiming: I'm claiming that
providing your securID credential in an unprotected run would be
patently insecure and we should not consider attacks that rely on
someone first doing something patently insecure. One could describe
an attack against regular-old digital signature IKE by starting off
with "if I was to be given your private key...." Now that's absurd.
We should not attempt to protect against that.

  Similarly we should not demand that our legacy authentication add-on
to IKE protect against attacks that start off with someone doing something
patently insecure like providing their legacy credentials in an
unprotected run. A client should never provide its legacy credentials in
an unprotected run. 

  If you accept that then the reason to not use EAP is it is _still_ 
susceptible to attack (described above) while SLA is not.

  You may not accept that, though. But the point I'm making is that
tunneling EAP with SLA opens one up to a more sinister attack than
using a "proprietary" method of tunneling legacy credentials. Do
you agree?

  Dan.

On Tue, 31 Dec 2002 01:58:08 +0200 you wrote
> 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.
>