Re: Secure legacy authentication for IKEv2

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

I think that I now understand what you mean.

I agree with the basic fact that methods such as EAP-TLS
are secure when run in "native form" but are susceptible to man-in-the
middle if run (with same credentials) in mixed native/tunneled modes.

However, SLA with "proprietary" formats does not solve the problem, it just
makes it harder for people to use these methods. It requires defining an SLA
profile for these methods, but if such a profile is created then the mitm
problem is there again.

The real issue is whether

1) ipsec people can live with doing ONLY weak [*] methods such as those
defined in the SLA profiles now (Secure-id, OTP, chall/resp) for which the
specific encapsulation method (SLA-specific or EAP) makes no difference to
their security 
([*] these methods are not weak if the authentication credentials are
used ONLY via secure tunnels).

or

2) ipsec people also want to use the stronger methods (such as EAP-TLS, SRP,
etc) in which case they will have to define SLA profiles for that and then
have the same MitM vulnerabilities as if they were using EAP transport 
(it only makes the definition more cumbersome).

If option (1) is all is needed then there is nothing to care about
(in particular, the security is not affected by the choice of EAP or 
"proprietary" encapsulation in SLA).
If people want (2) then making it harder for them to define these methods does
not seem as a great solution. I would prefer to add to the SLA document a
warning about the weaknesses introduced by mixed runs in "native" and
"tunneled" modes, and refer to possible external solutions (for example using
a generic mechanisms for securely composing EAP methods and tunnel methods as
being discussed in the EAP WG, or changing the underlying authentication
methods to include a binding to the server and protocol names).

In either case "non-standard" encapsulation is not the solution.
If for whatever reason you (and the WG) want to keep the current SLA
formats that's fine with me. I was just objecting the claim that this form
of encapsulation helps against these mitm threats.

Hugo

On Mon, 30 Dec 2002, Dan Harkins wrote:

>   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.
> > 
>