Subject: [eap] Liaison Request from IEEE 802.11u

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 20 Nov 2005 10:24:37 -0800

A liaison letter has been received from IEEE 802.11u:
http://www.drizzle.com/~aboba/IEEE/11-05-0983-00-0000-liaison-to-ietf-from-ieee802-11u.doc

The letter references the IEEE 802.11u Requirements document, the latest 
version of which is available here:
http://www.drizzle.com/~aboba/IEEE/11-05-0822-08-000u-tgu-requirements.doc

============================================================
Title: IEEE 802.11u Interworking with External Networks Requirements 
Document
Purpose: To review and return comments on requirements which specifically 
influence WLAN interworking.

Dear Brian Carpenter,

IEEE 802.11 Task Group u, Interworking with External Networks has produced a 
requirements document enclosed (11-05-822r3) with this covering letter.

The purpose of this letter is to ask you to review the attached document and 
to return comments on any of the requirements which may have a direct impact 
on the interworking of IEEE 802.11 technology with your technology. It would 
be useful to know which requirements are important to your organisation and 
additional requirements would be considered.

Please review this document and provide comments, so that IEEE 802.11u may 
refine their requirements.  The objective of this request is then to enable 
IEEE 802.11u to correctly engineer an interworking solution which is both 
acceptable to IEEE 802.11 and your organisation.  Comments are invited 
before the end of 2005, which will enable us to complete our work.

We look forward to additional discussions, and invite you to send feedback 
and possibly attend future IEEE 802.11 face-to-face meetings to discuss this 
document, if so desired.  The next two IEEE 802.11 meetings are during the 
weeks of November 13th – 18th , 2005 (Vancouver, British Colombia, Canada) 
and January 15th – 20th , 2006 (Waikoloa, Hawaii, USA).

For your reference, ANSI/IEEE Std. 802.11-1999, as amended by IEEE Std. 
802.11a, IEEE Std. 802.11b, IEEE Std. 802.11b-COR1, IEEE Std. 802.11d, IEEE 
Std. 802.11g-2003, IEEE Std. 802.11h-2003, IEEE Std. 802.11i-2004, IEEE Std. 
802.11j-2004 is the current version of the IEEE 802.11 Standard.

Please contact Stuart J. Kerry, IEEE 802.11 Working Group chair, together 
with Stephen McCann, IEEE 802.11u Task Group chair and Dorothy Stanley IETF 
Liaison with any questions.

Best Regards,

Stuart J. Kerry
Contact information:
Stuart J. Kerry
[email-masked]
+1 408 474 7356

Stephen McCann
[email-masked]
+44 1794 833341

Dorothy Stanley
[email-masked]
+1 630 979 1572

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 20 Nov 2005 12:17:03 -0800

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.