Subject: RE: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2 issues)

From: "Walker, Jesse" <[email-masked]>
Date: Wed, 20 Aug 2003 06:56:49 -0700

> * The primary discussion is whether the non-kg methods should
>    be allowed. See NON-KG METHODS below.
> 
>    We did not come to a specific conclusion in this discussion,
>    but Bernard and myself felt that non-kg methods should not
>    be allowed, kg variants of "legacy" methods exist and that
>    sufficient support already exists in common RADIUS servers
>    etc so that there's no real reason to support non-kg methods.
> 
>    We also felt that the primary requirement for support of legacy
>    is to avoid redistributing new credentials for users. This can be
>    avoided, new kg methods can use old non-kg credentials.
> 
>    Charlie felt that it is more important to ensure support
>    for legacy authentication infrastructure, and in his opinion
>    this is more widespread than what we believed.
> 
>    It seems that the primary disagreement is about the
>    extent legacy authentication infrastructure really
>    exists vs. the threat posed by the MITM attacks.

A keying EAP method has much different properties than a non-keying EAP method, which make each vulnerable to different threats.

As far as I can tell, none of the legacy non-keying EAP methods in question natively resist MITM attack anyway, so protecting them with IKE does not introduce a new problem. People shouldn't ever use them across any unprotected network, but they do.

On the other hand, by protecting the legacy EAP method with an IKE SA, the IKE peer is asserting that the client is communicating with the legacy authentication server. While such an assertion might often (usually?) be meaningless or fraudulant, it is not necessarily so.

This reasoning suggests supporting these legacy non-keying EAP methods in IKE is a clear win.

It seems to me that the debate is yet really again about eradicating legacy authentication methods that don't work but that the market demands anyway, to our collective dispair. The IPsec working group is probably the wrong forum to wage this battle.

Just my two cents.

-- Jesse Walker