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

[Michael Richardson (mcr]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Jari" == Jari Arkko <jari.arkko [at] piuha.net> writes:
    Jari> Are you thinking that the GammaCoffee's AP simply has its own
    Jari> userid for 
    Jari> access to DeltaCoffee, or some sort of a mitm authentication attack?

  Either way.

  If DeltaCoffee regularly uses username/password to get online (such as,
for instance, for regular customers, or for the "staff" machines), then it is
trivial for GammaCoffee to steal such an ID.
  But, we agree that those methods are inheirently insecure.

    Jari> I think I see your attack (if my assumption above was correct). Its
    Jari> an 
    Jari> interesting attack, though I'm not sure how specific it is to
    Jari> network selection 

  If the customer can figure out which AP belongs to DeltaCoffee and which
ones does not, then they customer can input this to their selection
algorithm.

  Btw, this was essentially the situation that we had at the last IETF,
except that the "rogue APs" weren't so cooperative as to route our packets.

    Jari> network access mechanisms enable us to have authentication, and
    Jari> link layer 
    Jari> protection. They do not, however, guarantee anything about the
    Jari> delivery of 
    Jari> the actual payload packets. In particular, there is no guarantee
    Jari> that the 
  
  Right, so this opens up the whole system up to disputes that one was
charged for service that was not received. You included QoS and pricing
in your "selection" algorithm.
  (No service is a QoS)

    Jari> We could call this the "payload route binding problem". In this
    Jari> problem, authentication and l2 support do not guarantee that
    Jari> the packets are actually routed through the path that appears to have
    Jari> been offered. Basically, if I have a flat fee account *and* a deal 

  If I took a shared key from the EAP EMSK somewhere, and used that to
authenticate the DHCP server (3118), it might have a serious positive
benefit. 

  In v6 land, we could use the channel created by EAP to provide the
certificates for the SEND secured RA. Both ways, that means that we are 
sure we are speaking at layer 3 to the services that we authenticated at
layer two.
  
    Jari> a lot of money. The local ISP would not be any wiser, as I could
    Jari> tunnel 
    Jari> my AAA packets through him encrypted. The user would not be any wiser
    Jari> either, because there's nothing in 802.11i or EAP that binds the SSID
    Jari> to the authentication. And even if there were, the user wouldn't care
    Jari> about the SSID enough to look at it. You would probably be breaking
    Jari> the contract with your provider, often they have just-one-machine
    Jari> clauses. But it would be hard for them to detect this.

  The one-machine clause has effectively died around here, with pretty much
all the ISPs selling "network sharing" NAT boxes themselves.

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

  I'd like a way to avoid the attack by careful network selection.
  If you think it is out of scope - that's fine. But it is, in my opinion
one of the major things that has fallen through the cracks between IETF
and IEEE. cf. my comment last summer about "subipSEC"

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr [at] xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device 
driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBP8pePoqHRg3pndX9AQEjsgQA6FRqTHOIK7K1Y/uzbBhU6nM/wuEsJ+Rd
mJ6sUFdq66IX8YoOEUkqpsWj2br2vZeBg8+PAQzWf8wXDLhOHW2c5XM2LyOXKVhw
VWOe0kabxKGdH9Lg9bYoKgdGERPMKJQ3zDt4rP9MsBGzZuELgpzcetza/F1398XV
7lMrWcrTZoA=
=J4vk
-----END PGP SIGNATURE-----