RE: Secure legacy authentication for IKEv2

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

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 to
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. that
the mitm atacks work against EAP and not SLA) then this whole conclusion needs
to be revised as suggested above.

Hugo

> 
> --Paul Hoffman, Director
> --VPN Consortium
>