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

Re: Secure legacy authentication for IKEv2


  But I think your solution would only work for EAP methods that
protect the EAP conversation themselves (like EAP-TLS). If Alice was
to speak EAP-OTP then the attacker could just splice in the "I am
running EAP over an IPsec tunnel" attribute.

But when I pointed this out before, I was careful to distinguish between SLA techniques that are MitM-proof *before* we tunnel them over IPsec and those that are already vulnerable to MitM without the addition of IPsec. It seems to me that EAP-OTP would fall into the latter category.

My point is that adding a private attribute to EAP is merely a different way of creating a new SLA exchange. This solves the MitM problem for the case where the attacker couldn't mount a MitM attack purely using dial-up. Rather than arguing which attack is possible when, we should be deciding whether it is easier to extend EAP or define our own payload format. Paul already stated that he thinks EAP is too difficult to extend, but we should solicit some more opinions from EAP experts.

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.



From: Dan Harkins <dharkins@xxxxxxxxxxxxx>
To: "Andrew Krywaniuk" <askrywan@xxxxxxxxxxx>
CC: hugo@xxxxxxxxxxxxxxxxx, ipsec@xxxxxxxxxxxxxxxxx
Subject: Re: Secure legacy authentication for IKEv2 Date: Tue, 31 Dec 2002 08:16:24 -0800

Andrew,

It's probably easier to add things in the EAP WG than the IPsec WG :-)

  But I think your solution would only work for EAP methods that
protect the EAP conversation themselves (like EAP-TLS). If Alice was
to speak EAP-OTP then the attacker could just splice in the "I am
running EAP over an IPsec tunnel" attribute.

Dan.

On Tue, 31 Dec 2002 04:27:53 EST you wrote
>
> I suggested a long time ago that we could solve the problem by simply adding
> a private attribute that says "I am running EAP over an IPsec tunnel", but I
> was told that adding a new EAP attribute is so hard that it would be easier
> to design our own SLA protocol. I don't really know enough about EAP to
> confirm or deny this.
>
> Andrew
> --------------------------------------
> The odd thing about fairness is when
> we strive so hard to be equitable
> that we forget to be correct.
>
>
> I do not agree. The problem is really with legacy authentication
> *protocols*,
> not with legacy *credentials*. If you let me re-design even the most basic
> of pswd authentication protocols such as CHAP I will do it in a way that
> will change the protocol very slightly (and will use passwds the same way
> CHAP uses now) but will make the modified protocol resistant to the MitM
> attacks we were discussing here. How? Simply put under the response
> computation the name of the server with which you are comunicating and (if
> possible) the name of the tunnel protocol under which the protocol is run
> (with a special "protocol name" for "no tunneling"). Needless to say this
> does not resolve dictionary attacks if the protocol is run unprotected but
> that is something that NO solution can avoid (except of course for NOT
> running the protocol unprotected or for switching to dictionary-attack
> resistant methods (which exist of course but not as "legacy").
>
>
>
> _________________________________________________________________
> MSN 8: advanced junk mail protection and 3 months FREE*.
> http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474
>&SU=
> http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_advancedjmf_
>3mf
>


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail