| RE: Re: comments on draft-groeting-eap-netselection-results -00.txt | <– Date –> <– Thread –> |
|
From: Tschofenig Hannes (hannes.tschofenig |
|
| Date: Tue, 20 Jul 2004 11:19:06 -0400 (EDT) | |
hi bernard, i also have to thank you for your quick response: please find a few responses to your comments below: ~snip~ > > > In fact, most administrators of WLANs do not change > the > default SSID (see for example [Pri04] for a study about WLAN > > usage in London where approximately 40% of the access > points are > running their default SSID.) Such an approach > makes the phone book > (see [RFC3017]) approach (as an > out-of-band mechanism to associate a > particular service to > an identifier) difficult to deploy. > > This implies that the SSID by itself can't uniquely identify > the network, something that can happen even without use of a > default SSID (user types in "John's Network"). In these > cases the combination of but SSID + BSSID can help > differentiate them. the combination of the ssid with the bssid (which is effectively a 48-bit mac address) makes the identification unique. given the large number of wlan hotspots i think the phone book entry can still be difficult to deploy. an additional step of mapping this <SSID + BSSID> identifier to network name which can be progressed by humans might be desireable. even automatic processing might be complicated if you have to carry a 10mb file of <SSID + BSSID> identifiers and their services with you. this also requires that you register your <SSID + BSSID> identifier pair somewhere. what do you think? > > > As a summary, to provide a short-term solution the > authors suggest to > provide a mechanism to exchange > information about the offered and the > desired service > between the end host and the access network. > > Why is this exchange between the host and the "network" and > not between the host and the NAS? i should have said NAS. on the other hand i hope that all NAS devices within a "network" distribute the same information to the end host. hence, it would also be possible to speak a "network". terminology can, however, be confusing. > > > Subsequently, this information has to be repeated both in > the EAP > method and the AAA infrastructure to give the > user and the home > network the ability to detect fraud. > > Well, channel bindings might be helpful here, but it's a > somewhat experimental facility. So if something simpler > (like Beacon + 4-way > handshake) were available, I'd go that way instead. this is certainly a simpler mechanism but cannot prevent against certain attacks (such as the lying nas problem). ciao hannes > > _______________________________________________ > eap mailing list > eap [at] frascone.com > http://mail.frascone.com/mailman/listinfo/eap >
-
RE: Re: comments on draft-groeting-eap-netselection-results -00.txt Tschofenig Hannes, July 20 2004
- RE: Re: comments on draft-groeting-eap-netselection-results -00.txt Bernard Aboba, July 20 2004
Results generated by Tiger Technologies using MHonArc.