eap Mailing List: RE: Liaison Request from IEEE 802.11u

[Bernard Aboba (bernard_aboba]

Review of IEEE 802.11u Requirements

Overall, it appears that much of the functionality defined in this document
is dependent on the adoption of a scalable "Virtual AP" model within
IEEE 802.11.  For reasons that will be described, a model in which a
single SSID can be used to access multiple realms cannot easily
satisfy many of the requirements.

R8E1 - Required

"Define functionality by which the STA is able to determine what online
enrolment (also called online subscription) methods are supported by the
network"

In large scale roaming situations, an AP will typically not have knowledge
of all the potential roaming realms which customers may be able to 
authenticate
to.  For example, an AP typically is not configured with a realm routing
table, but just a "default route" to the local AAA proxy or server.
The local AAA proxy in turn may also be configured with a "default route".

As a result, the AP may not know what realms are available, nor may it
have information on the services (such as enrollment) provided by those 
realms.
As a result, the AP may not be able to inform the STA whether online 
enrollment
is supported by a realm, or even if a realm is available to be reached by 
the STA.

Note that this problem cannot be solved by introduction of a "realm routing"
protocol, since it would be unlikely that such a protocol would be supported
by an AP, or even a local AAA proxy.  Due to the memory and CPU requirements
required to run such a protocol, it would be likely to only be supported
on "core proxies", much as BGP is only run on core routers.

As a result, an AP can only be presumed to have knowledge of a realm if
that realm is configured into the AP, potentially as a "Virtual AP".
Where a single physical or virtual AP is configured to enable access
to multiple realms, the only way a STA can determine whether the realm
supports an enrollment method is via an EAP exchange with that realm.

While a partial solution is provided within "Identity selection hints for 
EAP"
http://www.watersprings.org/pub/id/draft-adrangi-eap-network-discovery-14.txt
this solution requires the STA to associate with an AP prior to discovering
the supported realms.

As a result, where multiple realms are reachable via a single "Virtual AP",
the requirement specified in R8E1 may not be satisfiable by an exchange
occurring solely within IEEE 802.11.

R8E2 - Optional

"Define functionality for online enrollment"

During the recent EMU BOF, there was discussion of enrollment support
within EAP.  Rohan Mahy has submitted a draft on this subject:
http://www.watersprings.org/pub/id/draft-mahy-eap-enrollment-00.txt

This would support the document's assertion that "a solution may be
outside the scope of this task group".

However the current EMU WG Charter does not include a work item
on enrollment.

R8E4 - Optional

"Functionality shall be provided by which APs can advertise (before 
connection)
the charges that will be made for use of the network if a user enrolls with 
it."

The charges associated with access to a realm may vary not only with the 
realm
but also with the path by which the realm is accessed -- the "decorated 
NAI".
Since charges may also vary by time of day or day of the week, the 
information
required to fully inform the STA may be quite complex.

For the reasons described in R8E1, an AP may not know the realms accessible
from within a given "Virtual AP", or the charges associated with access to
that realm via any path, at any time.

Since neither EAP nor AAA provides a mechanism for communication of charges,
it is not clear how this requirement can be satisfied other than by manual
configuration of an AP.

We concur with the document characterization of this requirement as 
"optional".

R8N1 - Required

"Define functionality by which a STA can determine whether its subscription 
to an
SSPN would allow it to access a particular 802.11AN  before actually joining 
a BSS
within that 802.11 AN. Proposals must describe their consideration of 
scalability."

As described in the analysis of R8E1, where a single physical/virtual AP 
provides
access to multiple routing realms an AP may not know what realms are 
accessible
from a given "virtual AP".  As a result, the AP may not have the information
available to satisfy this requirement.

R8N2 - Required

"The mechanism described in requirement R8N1 must allow a STA that has 
multiple
credentials with an SSPN to select the correct credentials when 
authenticating
with a Local Network."

For a STA to select the correct credentials, it needs to be aware of the 
realms
available to it, as well as the EAP method to be used with the desired 
realm.
Once a STA has enrolled in a realm, it presumably is configured with the EAP
method to be used for that realm, so that the problem comes down to 
determining
which realms are available.

Therefore the issues inherent in realm discovery (see R8E1) are applicable
to this requirement as well.

R8N3 - Required

"Define functionality to support authentication with multiple SSPNs through 
a single AP."

That document indicates that "It?s not acceptable to require a separate
"virtual" AP for each SSPN", but does not provide more detail on how this 
statement
was arrived at.  Certainly, existing "Virtual AP" mechanisms do not scale 
much
beyond a dozen "Virtual APs" per physical AP.  However, recent submissions
within IEEE 802.11 appear to be aimed at removing those limitations, by 
enabling
multiple "Virtual APs" to be supported within a single Beacon/Probe 
Response,
as well as by enabling support of "hidden virtual APs" that are not 
advertised.

It would therefore appear that in the long term it will be possible to 
remove most if
not all of the "virtual AP" scaling limitations.

It is questionable whether this is really a requirement.

R8N5,  R8N6 - Optional

The issues described with respect to R8E4 apply here as well.
We concur with the document characterization of this requirement as 
"optional".

R8N7 - Not Required

"It should be possible to inform a STA about unbroadcasted SSIDs without 
causing
the STA to probe for each preferred SSID."

Unbroadcasted or "hidden" SSIDs are one mechanism by which the scalability 
of
802.11 advertisement mechanisms may be improved.  In a large scale roaming
deployment, presumably many of the SSIDs would be "hidden", since even 
support
for multiple "virtual AP" advertisements per Beacon might not be sufficient.

Since a "hidden" SSID is by definition not advertised, a Probe 
Request/Response
exchange is typically necessary to determine whether it is supported.  If a
STA has multiple SSIDs in its preference list which could conceivably be 
"hidden"
then it is not clear how it can determine whether they are present without
probing for them.

We concur with the document characterization of this requirement as "not 
required".

R8P2 - Required

"Define functionality to prevent hijack of MAC addresses."

RFC 4017 requires EAP methods supporting "mutual authentication" and
"key derivation" so that a STA supporting IEEE 802.11i can determine
whether an AP to which it has associated has been authorized by the
AAA server.

RFC 4017 also includes "Channel Binding" as an optional security claim.
Among other things, support for channel bindings enables a STA to
check with the AAA server whether an AP is impersonating another
AP to the STA.

More recently, IEEE 802.1ar "Secure Identity" has been chartered in order
to enable verification of ownership of MAC addresses.

It therefore appears that there is work in progress relevant to this
requirement.

R8A1 - Required

"A STA shall be able to authenticate with different SSPNs simultaneously,
in order to gain simultaneous access to multiple Destination Networks."

Simultaneous access to multiple wireless networks has already been
demonstrated using existing standards.  See:
http://research.microsoft.com/~bahl/MS_Projects/MultiNet/default.htm

It is therefore not clear that new functionality is necessary in order
to satisfy this requirement.

R8I1 -  Required

"Define IEEE 802.11TM functionality which would be required to support an
Emergency Call (e.g. E911) service as part of an overall, multi-layer 
solution.
Specifically: Capability Advertisement Authentication issues"

Multiple IEEE 802 groups have already become involved in the specification
of Emergency Service capability -- IEEE 802.11k, 802.11v, 802.1AB
(via TIA LLDP MED).

It is not clear that adding yet another group to the mix is the right
approach to providing coherence.