Re: Secure legacy authentication for IKEv2

[Dan Harkins <dharkins@tibernian.com>]

  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.

  Dan.

On Sat, 21 Dec 2002 02:30:48 +0200 you wrote
> Paul,
> 
> What you wrote below regarding the man-in-the-middle attacks is incorrect.
> SLA with the use of "proprietary" payloads is susceptible to these
> attacks exactly as if it used EAP payloads. It is actually the other way
> around: these attacks may be a good reason to use EAP.
> See more specific coments below.
> 
> On Fri, 20 Dec 2002, Paul Hoffman / VPNC wrote:
> 
> > At 12:52 PM -0800 12/20/02, William Dixon wrote:
> > >Paul, why wasn't an EAP encapsulation chosen in a similar manner as PIC
> > >?  It seems you are re-inventing EAP types here.  For every new or
> > >different auth method type, you'd have to define a new one in the IKEv2
> > >spec.
> > 
> > If we used EAP, we would be susceptible to the man-in-the-middle 
> > attack described at 
> > <http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-01.txt>.
> 
> 
> These attacks have nothing to do with EAP but with a mixed use of SAME
> authentication credentials in unprotected and tunnel-protected runs (such as
> the IKE-based tunnel that SLA would provide).
> I am not going to explain the attacks here but I want to point out 
> that they are NOT due to EAP encapsulation. In particular, the CHRE 
> encapsulation in SLA would be susceptible to the SAME attacks. In 
> these attacks the attacker uses the unprotected run of the authentication 
> to obtain from the user responses to server-generated challenges.  
> Once the attacker obtains these responses from the legitimate user 
> it can go on and encapsulate these responses in CHRE payloads and 
> complete his man-in-the-middle atack against SLA.
> 
> For those interested in this type of attacks see the above mentioned draft 
> and also the paper "Man-in-the-Middle in Tunnelled Authentication Protocols"
> by N. Asokan and Valtteri Niemi and Kaisa Nyberg
> http://eprint.iacr.org/2002/163/
> 
> > The "EAP and EAP-like problem" is being discussed in many places, and 
> > is one of the things that is holding up PIC as well.
> 
> If that is a reason to hold up PIC then for the same reason you'll have to
> hold up SLA. I suggest not to hold up any of these protocols on the basis of
> these attacks (rather have clear language regarding the reasons for these
> attacks and the essentially-limited scope of possible solutions).
> It is up to the "legacy authentication" community to come up with solutions t
>o
> these problems (which arise from the essentially-insecure use of credentials
> in mixed protected/unprotected environments). Moreover, if you support EAP
> exchanges and the EAP community comes up with measures to alleviate these
> attacks in the context of EAP then you get the benefits of this solution
> automatically. If you do CHRE then you don't.
> 
> That's a good reason to support EAP in SLA.
> 
> And it is not the only benefit:
> There is a lot of deployment of EAP and the definition of authentication
> mechanisms over EAP can be (and is) done independently of IKE.  In my
> view, it is better to leave these definitions in the hands of people
> (such as the EAP WG) that specifically care about transport of client
> authentication. If you rely on EAP then all you have to care about is to
> build a sound tunneling mechanism for EAP in the context of IKEv2
> (rather than bulding profiles that depend on the specifics of secure-id,
> radius, etc.) And, as said, the EAP guys are better suited to take care of
> problems in the "legacy authentication" world such as the above "man in the
> middle attacks" against tunneled authentication that have been a concern
> lately in this community.
>  
> And adopting EAP into SLA is easy, just copy PIC.
> 
> 
> > 
> > Dan and Derrell decided that the danger of mis-use of EAP was more 
> > worrisome than the need for automatic extensibility. Note that SLA 
> > already covers all of the methods that are covered by XAUTH, and 
> > there haven't been any calls in a quite a while for new XAUTH methods.
> 
> SInce this decision is justified on the basis of a wrong assumption (i.e. tha
>t
> the mitm atacks work against EAP and not SLA) then this whole conclusion need
>s
> to be revised as suggested above.
> 
> Hugo
> 
> > 
> > --Paul Hoffman, Director
> > --VPN Consortium
> > 
>