RE: Re: comments on draft-groeting-eap-netselection-results -00.txt
From: Tschofenig Hannes (hannes.tschofenigsiemens.com)
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
> 

Results generated by Tiger Technologies using MHonArc.