eap Mailing List: Review of the IEEE 802.11u Requirements Document

[Bernard Aboba (bernard_aboba]

Review of IEEE 802.11u Requirements

In situations where multiple realms may be accessible via a single
"virtual AP", the AP may not be able to satisfy many of the requirements
described in this document.  This is not merely due to deficiencies in
today's technology, but rather is a consequence of an architecture in
which APs serve as "edge devices" without full knowledge of the realm
routing table, much as access routers typically do not contain a full
routing table obtained by core routers running BGP.

Since APs do not have knowledge of the realm routing table, they cannot
respond to STA queries about which realms are accessible, nor can they
provide information relating to those realms, such as the services or
enrollment facilities available within them.

Much as an Internet host determines whether another host is reachable
by sending an IP packet to it, a network peer determines whether it can
authenticate to a realm by attempting to communicate with it.  If a peer
attempts to authenticate to an unreachable realm, the problem may not
be diagnosed until the request has traversed a core proxy with full
knowledge of the realm routing table, much as a "ping" may not generate an
ICMP network unreachable message until the request has reached a core
router.

As a result, it appears that much of the functionality required by
IEEE 802.11u cannot be provided in situations where a single SSID is
used to access an indetermine number of NAI realms.  In such situations,
the AP cannot easily obtain the required information relating to the
availability and capabilities of reachable realms.

The problem would be more tractable were IEEE 802.11u to focus on
development of a more scalable "Virtual AP" model for IEEE 802.11.  In
such a model, a determinate number of NAI realms (perhaps only one) would
correspond to an SSID, enabling the AP to be preconfigured with the
capabilities associated with each configured SSID.  This would enable the
communication of available "Virtual APs" and capabilities to the STA
without relying on facilities which are difficult for EAP or
the AAA infrastructure to provide.

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 deployments, 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.  The AP may not be able to inform the STA whether online
enrollment is supported by a realm, or even if a realm is reachable 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, 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 an indetermine number of 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 an indetermine number of 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 "Its 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 may be possible to
remove many of the "virtual AP" scaling limitations.

It is suggested that IEEE 802.11u re-examine whether R8N3 is really
required.

R8N5,  R8N6 - Optional

The issues described with respect to R8E4 apply here as well.
We concur with the 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.

Therefore there appears to be 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 been
demonstrated using existing standards:
http://research.microsoft.com/~bahl/MS_Projects/MultiNet/default.htm

As a result, new functionality may not be required to satisfy this
requirement, if a scalable "Virtual AP" model is available.

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), raising questions about the overall coherence of the
effort, let alone compatibility with the work of IETF WGs such as ECRIT
and GEOPRIV.

IEEE 802.11u may therefore wish to consider whether addition of another
group will help or hinder the effort to develop a coherent Emergency
Services architecture.