| RE: network discovery & selection: problem definition | <– Date –> <– Thread –> |
|
From: Adrangi, Farid (farid.adrangi |
|
| Date: Sun, 30 Nov 2003 07:16:05 -0600 (CST) | |
Hi Michael, Please see my reply inline (marked by Farid>). BR, Farid -----Original Message----- From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On Behalf Of Michael Richardson Sent: Saturday, November 29, 2003 3:35 PM To: eap [at] frascone.com Subject: Re: [eap] network discovery & selection: problem definition -----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. 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. Farid> Is this a legal thing to do? That is, having two overlapping hotspots whose ESSID values are the same. It seems that this will create other problems ...! But, let's go on with this assumption. 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. Farid> Okay - here is my interpretation of the above paragraph: the GammaCoffee's AP takes the EAP-Response from the supplicant and puts into an Access-Request and sends it arkohoptsportproxy.com (assuming that there is a business relationship between the two). After a few EAP and EAP-over-RADIUS exchanges, the supplicant authenticates itself to its home service network through GammaCoffee's AP and the arkohotsportproxy.com (the intermediary proxy). Yes, passing the packets to DeltaCoffee's AP, to which it has already authenticated *itself* with. Farid> Here you losing me! Are we still talking about authentication packets here? Who is passing the packets to DeltaCoffee's AP? 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). Farid> How do supplicant's IP packets get sent to Delta hotspot? If it double NATed, I assume that the packets are forwarded by some Access Router within Gamma to Delta. That means that there has to be some business agreement between Gamma and Delta, otherwise Delta can simply drop the packets. 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) ] 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 iQCVAwUBP8ktCYqHRg3pndX9AQEYsAP+JIaS2/99nwcOgyAdzu/hhJ8RRbmD5DPn MxKKWmxvnDKwCZL35AEH7eIxZT+y4hgKPas43+HA77eIudbQcTiu30mXhq2pfsCl g47PhyzbBtiPH19KHDOpK2eqnM4GG5zyqUf8++X50dgNfefqwp0Io/+w9kINJleC NGlSKptV0BI= =vT5n -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
- Re: network discovery & selection: problem definition, (continued)
- Re: network discovery & selection: problem definition Yoshihiro Ohba, December 1 2003
-
Re: network discovery & selection: problem definition Alper Yegin, December 10 2003
-
Re: network discovery & selection: problem definition Jari Arkko, December 10 2003
- Re: network discovery & selection: problem definition Alper Yegin, December 11 2003
-
Re: network discovery & selection: problem definition Jari Arkko, December 10 2003
- RE: network discovery & selection: problem definition Adrangi, Farid, November 30 2003
- Re: network discovery & selection: problem definition Michael Richardson, November 30 2003
- Re: network discovery & selection: problem definition Bernard Aboba, November 30 2003
- RE: Re: network discovery & selection: problem definition Mark Grayson (mgrayson), December 1 2003
- RE: network discovery & selection: problem definition Adrangi, Farid, December 1 2003
Results generated by Tiger Technologies using MHonArc.