[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Secure legacy authentication for IKEv2


On Friday, December 20, 2002, at 05:42 PM, Hugo Krawczyk wrote:

For the binding attack (as I understand it) to be viable, an active
attacker would have to bring up the SLA IKE tunnel through message two
and then somehow induce someone to speak one of the legacy
authentication methods to it.  But for that to happen, the attacker
would have to complete the first two messages with the intended victim
and in doing so, the client would learn that the attacker wasn't
trusted.  (We were not concerned with trusted gateways impersonating
each other.)

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)

(b) impersonates the client to the server in the protected run (SLA,
PIC, etc) using the responses that it gets from the client in the
impersonated unprotected run (a).

But again see the mentioned documents for a full understanding of these
attacks, their independence from EAP, and applicability to SLA (in
particular, the fact that SLA requires server authentication does not
help against the attacks).

Hugo

Hugo,

Thanks for the pointer to the NRC paper. Between it and <http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding- 01.txt> I now have a good understanding of the particular MitM attack we're discussing. Further I now see that the distinction between using EAP vs. SLA (with its CHRE) is irrelevant with respect to this.

We agree that this attack requires that:

1) the authentication protocol that's run in the tunnel also be run outside of the tunnel (i.e. unprotected)

2) an attacker is somehow able to lure clients into running the unprotected legacy authentication against him

For SLA, we assumed that the legacy authentication methods that we're talking about tunneling are in use only back on the corporate network, not across the Internet. We assumed that the corporate network is appropriately isolated (behind a firewall) from the Internet and blocks nearly everything. It's our belief that that's the usual configuration for deployed IPSec VPN gateways today, which are increasingly hosted on (or built into) the firewall itself. Given these assumptions, clients aren't running the legacy authentication protocols anywhere outside of SLA because there's nothing to talk to (it's all blocked at the firewall).

Perhaps the salient point is that these assumptions and their implications on the security of the protocol do need to be clearly stated. I'm guessing you might agree with this because in another later email you wrote:

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

If we're on the same page, then it seems to me what's interesting to talk about as a group is whether or not these assumptions are realistic for our to-be-deployed IPSec remote client protocol. If we are indeed worried that the legacy authentication methods are today in use across the Internet then we've got more work to do.

Derrell