eap Mailing List: Re: network discovery & selection: problem definition

[Jari Arkko (jari.arkko]

Michael Richardson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
>
> > > > > > "Jari" == Jari Arkko <jari.arkko [at] piuha.net> writes:
>
>     Jari> Michael Richardson wrote:
>
>     >> An additional area, maybe out of scope:
>     >> how do I know that these intermediaries are legitimate, vs MITM?
>
>     Jari> I suppose they still have to be legitimate AAA proxies.
>     Jari> That is, an access network should not send your request to
>     Jari> an unknown intermediary. If it has a business relationship
>     Jari> with three intermediaries int1.com, int2.com, and int3.com,
>     Jari> it will route your request through one of them, even if you
>     Jari> tried to request routing through mitm.org.
>
>   It is more immediate than that.

Ok, reading on...

>   Let's assume that there are two competing hotspots, physically adjacent
> to each other. The signal is available in both locations. Both are using
> NAT. 
>
>   Call the two operators DeltaCoffee and GammaCoffee. They are using ESSID
> "delta" and "gamma". Both make deals with arkohotspotproxy.com, the most
> popular clearing house for EAP-AKA based payments.
>
>   However, GammaCoffee has found a way to make money without spending much.
>   They set their ESSID to "delta", and respond to EAP.

This could happen, yes.

>   As a supplicant, one could get a EAP Request from either one. Let's say
> that I get one from GammaCoffee's AP. It takes my request, goes back on the
> wireless, authenticates against arkohotspotproxy.com using radius. Yes,
> passing the packets to DeltaCoffee's AP, to which it has already
> authenticated *itself* with.

Are you thinking that the GammaCoffee's AP simply has its own userid for
access to DeltaCoffee, or some sort of a mitm authentication attack?
I am assuming the former, because I do not see the mitm authentication
attack here. Only one of the access points gets the session keys from
the home AAA. The other AP would not, and hence one of the AP could not
complete the 4-way handshake or send/receive packets.

>   The supplicant and authenticator do their thing, and then the supplicant
> gets an IP address from GammaCoffee's AP. supplicant's packets are NAT'ed by
> Gamma, and sent to Delta (who NATs them again).
>
>   The result:
>       Gamma gets a revenue stream from arkohotspotproxy.com
>       Delta pays for the bandwidth
>
>   If the charges are based upon per-byte, then maybe Gamma has to pay Delta
> as much as it takes in. If they are based upon time, then Gamma wins. 
>   (Best is if Gamma manages to steal a username/password along the way,
> from some user that is willing to do username/password instead of something
> that is secure)

I think I see your attack (if my assumption above was correct). Its an
interesting attack, though I'm not sure how specific it is to network selection
or even to authentication mechanisms such as EAP. Here's why: the current
network access mechanisms enable us to have authentication, and link layer
protection. They do not, however, guarantee anything about the delivery of
the actual payload packets. In particular, there is no guarantee that the
payload packets are delivered through a right route, or NATed only up to
some specific number of times.

We could call this the "payload route binding problem". In this
problem, authentication and l2 support do not guarantee that
the packets are actually routed through the path that appears to have
been offered. Basically, if I have a flat fee account *and* a deal with
a clearing house, I can offer access to anyone with a per-byte account,
NAT their packets, and send the traffic forward on my account, and get
a lot of money. The local ISP would not be any wiser, as I could tunnel
my AAA packets through him encrypted. The user would not be any wiser
either, because there's nothing in 802.11i or EAP that binds the SSID
to the authentication. And even if there were, the user wouldn't care
about the SSID enough to look at it. You would probably be breaking
the contract with your provider, often they have just-one-machine
clauses. But it would be hard for them to detect this.

In conclusion this looks like an interesting attack. It appears
to exist without any network selection functionality, so its a
general issue. What would you like to do with this issue - solve
or document it? I am not sure if we talk about something like this
already in the keying document. Or maybe we should go into business
together and start selling software that does this on the background
on everyone's PC ;-)

--Jari