Subject: RE: [eap] Re: comments on draft-groeting-eap-netselection-results -00.txt

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 20 Jul 2004 17:32:19 +0200

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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Jul 2004 09:16:47 -0700 (PDT)

> even automatic processing might be complicated if you have to

The SSID is a non-unique identifier.  This will affect all schemes
that attempt to use the SSID as an identifier of a network configuration.
It does not matter whether the schemes are dynamic or static.

In particular, there are SSIDs that ship by default on APs.  For those
"default" SSIDs, the SSID isn't just a non-unique identifier with *some*
potential for duplication;  duplication is the intent, making the SSID
meaningless for network identification.  One potential mechanism for
dis-ambiguating "default" SSIDs is to use the BSSID ot distinguish them.
However, the implicit assumption here is that "default" SSIDs are not used
in large networks, but rather in situations where only a small number
(usually one) AP is deployed.  Thus the SSID + BSSID combination may
uniquely identify a single AP network.

If this assumption does not hold, a host of problems arise.  But these
problems will also afflict dynamic as well as static techniques that rely
on the SSID as a means of network identification.

The solution to this problem is probably to utilize another mechanism with
guaranteed uniqueness to identify WLAN networks.  However, given that the
problem is fundamental to 802.11, it seems likely that 802.11 will wish to
become involved in the solution.  The recent "straw poll" indicating a
desire to standardize Network Selection within 802.11 is a likely
indication of this.