eap Mailing List: Re: comments on draft-groeting-eap-netselection-results-00.txt

[Bernard Aboba (aboba]

Jari Arkko noted:

"I disagree about EAP being an obvious choice for this purpose.
I think we have consensus that we can use it in a very
limited fashion..."

Yes, the discussion so far in 802.11 WIEN does not appear to suggest that
EAP is the obvious choice either, particularly if the wider problem
statement is taken into account (service discovery and selection).

 >  is used in this fashion (i.e., beyond its original intention) it is
 >  important to note that there are possible impacts on security,
 >  scalability and the EAP state machine.

Actually I think there may be impacts even when used as intended.

 > Please don't use the EAP Identity Request packets for
 > a transmission of all this data. Farid's draft very clearly
 > states that you can transfer intermediate network names
 > (roaming information), but nothing else. As you point out
 > above, the space runs out very fast.

Given the limitations of the EAP MTU size, and the inherent inefficiency
of the described syntax, it's quite questionable whether these kind of
extensions make any sense.  And if they are really needed (which I can
believe), then this argues for going another route from the start, such as
delivering the information at the lower layer.

Given that a straw poll at the IEEE 802.11 WIEN group indicated strong
support for standardization within 802.11, I suspect that we'll have
discussions on lower layer alternatives taking place fairly soon.  Given
this, the argument for publishing the EAP Network Discovery document
rests on its general utility (providing hints for selection
of the right NAI for the EAP-Response), rather than its suitability
as a substrate for further extensions.

>    check for packets who are arriving more than one time.  As proposed
>    in [I-D.adrangi-eap-network-discovery] the AAA-Server has to handle
>    these packets based on the local routing policy.  In fact the
>    AAA-Server SHOULD discard these packets and send an EAP Failure
>    packet which stops the authentication process.

Actually, I'd argue for a Notification so that the client can figure out
what is going on, and *then* an EAP Failure.

> Can you clarify which protocol layer you intend
> to carry this in?

Please keep in mind that there is chartered work within 802.21 as well as
802.1af on Network Discovery, as well as the discussion going on in WIEN.
So there are lots of place to put this :)

 > 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.

 >  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?

 >  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.