One document matched: draft-adrangi-eap-network-discovery-and-selection-00.txt
Network Working Group Farid Adrangi (Ed.)
INTERNET DRAFT Intel Corporation
Category: Informational Aug 16, 2003
Expires : March 30, 2004
Network Discovery and Selection within the EAP Framework
draft-adrangi-eap-network-discovery-and-selection-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes a solution for Service Network discovery
and selection that could be implemented within the existing EAP
specification framework. The purpose of Service Network discovery
and selection here is to help a WLAN client using EAP for
authentication to decide whether or not to connect to a WLAN
Access Network, and help it select the most appropriate Mediating
Network as a next hop for routing AAA packets in roaming
situations where the WLAN Access Network has agreements with more
than one Mediating Network affiliated with the clientÆs Home
Service Network.
The proposed solution has 3 components: a delivery mechanism for
conveying Access Network and Service Network Information to a WLAN
client, a data model/syntax for structuring the information in a
generic manner, and a method by which the WLAN client can indicate
its selection to the WLAN Access Network.
Adrangi, et al. Expires March 30, 2004 [Page 1]
Internet Draft Network Discovery and Selection 16 August 2003
Adrangi, et al. Expires March 30, 2004 [Page 2]
Internet Draft Network Discovery and Selection 16 August 2003
Table of Contents
1. Introduction....................................................3
1.1 Authentication Message Flow....................................4
1.2 Problem Statement..............................................5
1.3 Rationale for the Proposed Solution............................5
1.4 Applicability of the Proposed Solution.........................7
1.5 Requirements language..........................................7
1.6 Terminology....................................................7
2. Proposed Solution...............................................8
2.1 Delivery Mechanism.............................................9
2.2 Data Model / Syntax...........................................17
2.3 NAI Decoration................................................18
3. Attribute Definitions..........................................18
3.1 NAIPrefixes...................................................18
4. IANA Considerations............................................19
5. Security Considerations........................................19
6. Contributors...................................................19
7. Acknowledgements...............................................20
8. References.....................................................20
AuthorsÆ Addresses................................................20
1. Introduction
Wireless LAN (WLAN) Access Networks are being deployed in public
places such as airports, hotels, shopping malls, and coffee shops.
A Public WLAN (PWLAN) Access Network typically consists of three
key components that work together to provide authorized users with
a wireless access to the Internet or to services
offered/authorized by their Service Network providers (e.g., WISP,
3GPP, or 3GPP2 type Service Networks). The three components are:
the Access Points (AP), the PWLAN AAA server, and the Access
Router which links the PWLAN Access Network to the services
network (i.e., Internet and/or operatorÆs core IP network).
A PWLAN Access Network MAY have a direct or an indirect (i.e., via
a mediator) relationship with 1 or more Service Networks (e.g.,
WISP, 3GPP, or 3GPP2). Figure 1 illustrates a PWLAN Access
Network that has roaming agreements with three Mediating Networks
(i.e., ôRoaming Partnerö or ôBrokerö or ôVisited Service Networkö
- hereafter these terms are used interchangeably to mean a
Mediating Network in this document). As the figure shows,
Mediating Networks 1 and 2 have relationships with Home Service
Network A; Mediating Network 3 has relationship with Home Service
Network B. The figure also shows a direct relationship between
the PWLAN Access Network and Home Service Network B.
Adrangi, et al. Expires March 30, 2004 [Page 3]
Internet Draft Network Discovery and Selection 16 August 2003
PWLAN Access Network Mediating Network 1
+-------------------+ +-----------+ Home Service
| | | | Network A
| +------+ | |AAA server;| +---------------+
| +-----+ |Access| | | Other |=====|Home AAA server|
| |APs | |Router| | ||====|Components | | |
| |1..n | +------+ | || +------------ | ,And |
| +-----+ | || | Other |
| +------+ | || Mediating Network 2 | Components |
| +-----+ |PWLAN | | || +------------+ | |
| |Users| |AAA | | || |AAA Server; |====| |
| |1..n | |Server|============| Other | +---------------+
| +-----+ +------+ | || | Components |
| | || +------------+
+-------------------+ ||
|| Mediating Network 3
|| +------------+ Home Service
|| | | Network B
|| |AAA Server; | +---------------+
||====| Other |===|Home AAA Server|
|| | Components | | |
|| +------------+ | ,And |
|| | Other |
|| | Components |
||=====================| |
| |
+---------------+
Figure 1 : WLAN Roaming Network Architecture with AAA mediation
To be specific, hereafter, RADIUS [1] protocol is assumed for AAA
mediation between the PWLAN Access Network and the Home Service
Provider. Diameter [2] could also be used instead of RADIUS
without introducing significant architectural differences.
1.1 Authentication Message Flow
This section provides an overview of authentication exchanges
between a WLAN client and a Home Service Provider.
In roaming situations, authentication exchanges are carried out
between a WLAN client in a PWLAN AN and a RADIUS server in a Home
Adrangi, et al. Expires March 30, 2004 [Page 4]
Internet Draft Network Discovery and Selection 16 August 2003
Service Network through 1 or more Mediating Network RADIUS
servers located in the PWLAN Access Network and the Mediating
Networks as shown in Figure 2. During the authentication phase,
EAP messages are encapsulated using a mechanism such as EAPOL
(EAP over LAN) between the WLAN client and the AP and re-
encapsulated in RADIUS messages (referred to as the ôEAP over
RADIUSö [4]) from the AP to the home RADIUS server in the Home
Service Network.
WLAN Access Point Mediating Network Home
Client RADIUS Server RADIUS Server
(1 or more)
|<------------------------- EAP------------------------------->|
|<--- EAPOL ---->|<-------------- RADIUS --------------------->|
|<--------------- UDP ----------------------->|
|<--------------- IP ------------------------>|
Figure 2 û EAP-based Authentication Message Flow
1.2 Problem Statement
In roaming situations where a WLAN Access Network has agreements
with more than one Mediating Network affiliated with a WLAN
clientÆs Home Service Network, the WLAN client SHOULD be able to
influence the selection of the desired Mediating Network through
which authentication packets SHOULD be routed through. The WLAN
client may prefer one Mediating Network over another for
charging, Quality of Service (QoS), or other reasons. The WLAN
client may also decide to not connect to the WLAN Access Network
due to the absence of a desired Mediating Network.
Influencing the Mediating Network selection problem can be
divided into three sub-problems as follows:
1) A delivery mechanism by which Network Information is
conveyed to a WLAN client.
2) A general data model and syntax by which Network
Information is structured for unambiguous interpretation by
the WLAN client.
3) A general mechanism by which a WLAN clientÆs selection
can be conveyed to the WLAN Access Network.
1.3 Rationale for the Proposed Solution
Several solution alternatives were considered for Network
Discovery and Selection. The fundamental difference among them
is the type of bearer that they use to convey Network Information
to a WLAN client. This section articulates the rationale for
using EAP as a mechanism / bearer for Network Discovery and
Adrangi, et al. Expires March 30, 2004 [Page 5]
Internet Draft Network Discovery and Selection 16 August 2003
Selection by describing why the competing solution alternatives
are undesirable.
[Competing Solution Alternative 1]
It is possible for a WLAN client to derive Network Information
from the Broadcast SSID or other such information. However,
this requires having structured SSID values with a standardized
namespace which will break backwards compatibility, since
deployed PWLAN networks may not be in a position to change the
SSID used. Also private WLAN SSIDs could overlap with the
standardized namespace making it inefficient.
Note that the SSIDs can be broadcasted as the identities of the
Mediating Networks which eliminates the need for having
structure SSID values with a standardized namespace. However,
this will require APs to support broadcast of multiple SSIDs
which is not an IEEE standard. Furthermore, the capability for
broadcasting multiple SSIDs may have some scalability
implications.
[Competing Solution Alternative 2]
It is possible to convey Network Information in Access Point
(AP) broadcasts (e.g., beacon frames) to a WLAN client.
However, this is undesirable because of the high frequency
(i.e., every 100-400ms) of these broadcast frames and the
incurred traffic overhead which would adversely impact the
PWLAN performance. Furthermore, this is not backward-
compatible with existing PWLAN deployments as it requires
firmware/hardware changes to the APs.
[Competing Solution Alternative 3]
It is possible for a WLAN client to do active scanning wherein
the WLAN client would send a probe request with a specific
SSID and the Access Point would respond with the Network
Information. However, this will require changes to the APs to
support administrating and delivering Network Information,
hence it is not backward-compatible with currently deployed
PWLAN networks. It will also require changes to network
software layers on the client to propagate the information up
to the appropriate layer.
[Competing Solution Alternative 4]
It is possible for a WLAN client to have a local database
mapping SSIDs to Mediating Network names, where it is not
necessary to change SSIDs. However, this will have the same
problems as the alternative 1. Furthermore, it will require
Adrangi, et al. Expires March 30, 2004 [Page 6]
Internet Draft Network Discovery and Selection 16 August 2003
storage space for the database, and a mechanism for updating
it.
Having described the disadvantages of the competing solution
alternatives, this document proposes a solution that uses EAP as
a mechanism for conveying Network Information to a WLAN client.
And, the rationale for this as follows:
o The proposed solution is backward-compatible with existing
PWLAN deployments.
o The proposed solution does not introduce a new protocol
standard, or require any significant protocol changes to
existing protocol standards.
o The proposed solution can be implemented without impacting
existing APs deployed in PWLAN networks.
o The proposed solution does not negatively impact the
performance of PWLAN networks.
1.4 Applicability of the Proposed Solution
The solution can be deployed in any wireless access network
architecture where the clients use the existing EAP specification
framework [9] for authentication, and they present their identity
to the network in NAI [5] format.
1.5 Requirements language
In this document, several words are used to signify the
requirements of the specification. These words are often
capitalized. The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119].
1.6 Terminology
Access Network (AN)
The PWLAN hotspot network that provides wireless connectivity
to the Internet for WLAN clients (or stations) present in the
local access area. This MAY be in a separate security and
routing domain with respect to the Home Service Network or a
Mediating Network.
Home Service Network (HSN)
The network providing the service and therefore maintaining
the direct relationship to the user/subscriber of the WLAN
service. All AAA functions are ultimately performed by the
HSN.
Adrangi, et al. Expires March 30, 2004 [Page 7]
Internet Draft Network Discovery and Selection 16 August 2003
Visited Service Network (VSN)
The Service network providing service in the local
geographical region to roaming customers of another HSN. Such
networks may act as Mediating Networks to the roaming
clients.
Mediating Network (MN)
The network responsible for mediation between a PWLAN Access
Network and a Home Service Network. They could be AAA brokers
or Visited Service Networks.
Network Information (NI)
Network-related information pertaining to a PWLAN network
(e.g., location information such as country, state, city,
location ID, and etc.) and its roaming partners (e.g., a list
of ôvisited networksö that the PWLAN has agreements with).
Network Access Identifier (NAI)
An identifier that represents a client or user identity. The
basic structure of a NAI is user@realm, where the realm part
of the NAI indicates the domain responsible for interpretation
and resolution of the user name. See [5] for more details on
NAI format.
Decorated NAI
A valid NAI with additional information influencing the
routing choice of the next Mediating Network to the PWLAN AAA
server as describe in this document. It may include
information for several Mediating Networks to be indicated on
the route to the Home Service Network.
Access Point (AP)
ôA station that provides access to the distribution services
via the wireless medium for associated Stations.ö
RADIUS server
ôThis is a server which provides for
authentication/authorization via the protocol described in
[1], and for accounting as described in [6].ö It is deployed
in the PWLAN AN, MN, and HSN.
Service Set Identifier (SSID)
ôan identifier attached to packets sent over the wireless LAN
that functions as a ôpasswordö for joining a particular radio
network.ö
2. Proposed Solution
The EAP-Identity request message is used to deliver Network
Information (structured by a general data model/syntax) to a WLAN
client. Upon receipt of the information, the WLAN client then MAY
influence the selection of an MN which has a direct relationship
Adrangi, et al. Expires March 30, 2004 [Page 8]
Internet Draft Network Discovery and Selection 16 August 2003
with the PWLAN AN for routing RADIUS packets through to the HSN.
This is achieved by sending a Decorated NAI to the PWLAN AP in the
Type-Data field of the EAP-Identity Response. As specified in [4],
the PWLAN AP then encapsulates the EAP-Response within an EAP-
Message attribute and sends it to the PWLAN RADIUS server within a
RADIUS Access-Request packet. It also copies the contents of the
Type-Data field of the EAP-Response (i.e., the Decorated NAI) into
the User-Name attribute.
When a PWLAN RADIUS server receives a RADIUS Access-Request packet
containing a Decorated NAI which does not specify an MN recognized
by the PWLAN AN as the next hop for routing the RADIUS packet, the
PWLAN RADIUS server SHOULD route the RADIUS packet based on its
local routing policy.
The solution is comprised of three components: the delivery
mechanism for conveying the information to a WLAN client, the data
model / syntax for structuring the information, and the NAI
decoration for indicating the selected MN. The following sections
describe each solution component in details.
2.1 Delivery Mechanism
The EAP specification [3] describes the use of the Type-Data
field in an EAP-Identity Request for a displayable message
terminated by a null. It also suggests that additional data
(with format currently undefined) can be placed after the null
character.
Network Information MUST be placed after the null character in
the Type-Data field. The portion of the field prior to the null
MAY contain zero or more bytes (depending on whether or not there
is a displayable message). There are three possible options of
delivering Network Information to a WLAN client by using an EAP-
Identity Request. These options are:
1) Use the Initial EAP-Identity Request issued by the PWLAN AP.
2) Use the initial EAP-Identity Request issued by the PWLAN
RADIUS server.
3) Use a subsequent EAP-Identity Request issued by the PWLAN
RADIUS server.
Here we look at these three options with pros and cons of each.
[Option 1] Use the Initial EAP-Identity Request issued by the
PWLAN AP
Network information is pushed to a WLAN Client in the initial
EAP-Identity Request issued by the AP.
Adrangi, et al. Expires March 30, 2004 [Page 9]
Internet Draft Network Discovery and Selection 16 August 2003
The message flow below illustrates conversations between an
authenticating peer, AP, PWLAN AN RADIUS server, MN RADIUS
server, and HSN RADIUS server. Where the AP sends an EAP-
Request/Identity containing Network Information as the initial
packet, the exchange appears as follows:
WLAN PWLAN PWLAN MN HSN
Client AP RADIUS RADIUS RADIUS
| server server Server
| (1) | | | |
| EAP Id. Req. | | | |
|(Network Info) | | | |
|<--------------| | | |
| | | | |
| (2a) | | | |
| EAP Id. Resp. | | | |
|(Decorated NAI)| | | |
| *OR* | | | |
| (2b) | | | |
| EAP Id. Resp. | | | |
|(normal NAI) | | | |
|-------------->| (3) | | |
| |Access Request | | |
| |(EAP Id. Resp.)| | |
| |-------------->| (4) | |
| | |Access Request | |
| | |(EAP Id. Resp.)| |
| | |-------------->| |
| | | | |
| | | |Access Request |
| | | |(EAP Id. Resp.)|
| | | (5) |-------------->|
| ... | ... | ... | ... |
| <<EAP Authentication Methods>> |
| ... | ... | ... | ... |
| | | | |
| | | | Access Accept |
| | | | (EAP Success) |
| | | |<--------------|
| | | | |
| | | Access Accept | |
| | | (EAP Success) | |
| | |<--------------| |
| | | | |
| |Access Accept | | |
| |(EAP Success) | | |
| |<--------------| | |
| | | | |
| EAP Success | | | |
|<------------- | | | |
| | | | |
Adrangi, et al. Expires March 30, 2004 [Page 10]
Internet Draft Network Discovery and Selection 16 August 2003
The following describes each message flow in details.
(1) The PWLAN AP sends the initial EAP-Identity Request
containing Network Information the WLAN Client.
(2a) The WLAN client sends an EAP-Identity Response containing a
Decorated NAI indicating the selected MN to the PWLAN AP. OR,
(2b) The WLAN client sends an EAP-Identity Response containing a
normal NAI defined in [5] to the PWLAN AP.
(3) The PWLAN AP sends a RADIUS Access Request packet containing
the EAP-Identity Response (as defined in [4]) to the PWLAN RADIUS
server.
(4) The PWLAN RADIUS server processes the received Access-Request
packet as specified in [4] and forwards it to the appropriate MN
RADIUS server.
(5) The EAP Authentication continues as described in [4].
The following summarizes pros and cons of this option.
Pros:
o It does not introduce additional EAP messages
Cons:
o It requires modifications to APs, since most currently-
deployed APs do not include support for administering and
delivering Network Information in the EAP-Identity Request.
o It MAY require modification to the PWLAN RADIUS server for
processing a Decorated NAI (many RADIUS servers already have
this capability).
o It MAY introduce a contention problem if space in the Type-
Data field has already been used up for other purposes.
[Option 2] Use the initial EAP-Identity Request issued by the
PWLAN RADIUS server
This is similar to Option 1, but the initial EAP-Identity Request
is issued by the PWLAN RADIUS Server instead. Once a WLAN client
associates with a PWLAN AP using native IEEE 802.11 procedures,
the AP sends an EAP-Start message within a RADIUS Access-Request
as defined in [4] to trigger an EAP conversation initiated by the
PWLAN RADIUS server.
The message flow below illustrates conversations between an
authenticating peer, AP, PWLAN AN RADIUS server, MN RADIUS
server, and HSN RADIUS server. Where the AP sends an EAP-
Adrangi, et al. Expires March 30, 2004 [Page 11]
Internet Draft Network Discovery and Selection 16 August 2003
Request/Identity containing Network Information as the initial
packet, the exchange appears as follows:
WLAN PWLAN PWLAN RADIUS MN RADIUS HSN RADIUS
Client AP server server Server
| (1) | | | |
| Association | | | |
|------------->| (2) | | |
| |Access Request | | |
| |(EAP-Start) | | |
| |--------------->| | |
| | | | |
| | (3) | | |
| |Access Challenge| | |
| |(EAP Id. Req. + | | |
| | (Network Info) | | |
| (4) |<---------------| | |
| EAP Id. Req. | | | |
|(Network Info)| | | |
|<-------------| | | |
| | | | |
| (5a) | | | |
|EAP Id. Resp. | | | |
| | | | |
| (5b) | | | |
|EAP Id. Resp. | | | |
|------------->| (6) | | |
| |Access Request | | |
| |(EAP Id. Resp.+ | | |
| | Decorated NAI) | | |
| |--------------->| (7) | |
| | |Access Req. ( | |
| | |EAP Id. Resp.+| |
| | |Decorated NAI)| |
| | |------------->| |
| | | |Access Request |
| | | |(EAP Id. Resp.)|
| | | |-------------->|
| ... | ... |.. | ... |
| <<EAP Authentication Methods>> |
| ... | ... |... | ... |
| | | | |
| | | | Access Accept |
| | | | (EAP Success) |
| | | |<--------------|
| | |Access Accept | |
| | |(EAP Success) | |
| | |<-------------| |
| |Access Accept | | |
| |(EAP Success) | | |
| |<---------------| | |
| EAP Success | | | |
Adrangi, et al. Expires March 30, 2004 [Page 12]
Internet Draft Network Discovery and Selection 16 August 2003
|<-------------| | | |
The following describes each message flow in details.
(1) The WLAN client associates with the PWLAN AP.
(2) An EAP-Start message encapsulated within a RADIUS Access-
Request sent to the PWLAN AN RADIUS server.
(3) The PWLAN RADIUS server processes the received Access-Request
message and initiates an EAP conversation by sending an EAP-
Identity Request encapsulated within a RADIUS Access-Challenge.
(4) The PWLAN AP extracts the EAP-Identity Request from the
received Access-Challenge and sends it to the WLAN client.
(5a) The WLAN client sends an EAP-Identity Response containing a
Decorated NAI indicating the selected MN to the PWLAN AP. OR,
(5b) The WLAN client sends an EAP-Identity Response containing a
normal NAI [5] to the PWLAN AP.
(6) The PWLAN AP sends a RADIUS Access-Request packet containing
the EAP Response (as defined in [4]) to the PWLAN RADIUS server.
(7) The PWLAN AN RADIUS server processes the received Access-
Request packet and forwards it to the appropriate MN RADIUS
server.
(8) The EAP Authentication continues as described in [4].
The following summarizes pros and cons of this option.
Pros:
o It does not introduce additional EAP messages
o It does not require any modifications to APs to include
support for administrating and delivering Network
Information.
Cons:
o It may not be backwards compatible if currently deployed
APs in PWLAN ANs do not support EAP-Start.
o It MAY require modification to the PWLAN RADIUS server for
processing a Decorated NAI (many RADIUS servers already have
this capability).
o It MAY introduce a contention problem if space in the Type-
Data field has already been used up for other purposes.
Adrangi, et al. Expires March 30, 2004 [Page 13]
Internet Draft Network Discovery and Selection 16 August 2003
[Option 3] û Use a subsequent EAP-Identity Request issued by the
PWLAN RADIUS server
Network Information is delivered to a WLAN Client in a subsequent
EAP-Identity request after the initial EAP-Identity
Request/Response exchange.
Upon receipt of a RADIUS Access-Request packet containing the
initial EAP-Identity Response, the PWLAN RADIUS server MAY send
an EAP-Identity Request containing Network Information to the
WLAN client if the Response does not already contain a Decorated
NAI which specifies an MN recognized by the PWLAN AN as the next
hop for routing the RADIUS packet.
When a RADIUS Access-Request containing a subsequent EAP-Identity
Response is received, if the User-Name attribute contains a
normal NAI [5] then the PWLAN server MUST route the RADIUS packet
based on its local routing policy as usual.
The protocol message flow below illustrates conversations between
an authenticating peer, AP, PWLAN RADIUS server, MN RADIUS
server, and HSN RADIUS server. Where the AP sends an EAP-
Request/Identity containing Network Information as the initial
packet, the exchange appears as follows:
Adrangi, et al. Expires March 30, 2004 [Page 14]
Internet Draft Network Discovery and Selection 16 August 2003
WLAN PWLAN PWLAN RADIUS MN RADIUS HSN RADIUS
Client AP server server Server
| (1) | | | |
| EAP Id. Req. | | | |
|<-------------| | | |
| | | | |
| (2) | | | |
| EAP Id. Resp.| | | |
|------------->| (3) | | |
| |Access Request | | |
| |(EAP Id. Resp.) | | |
| |--------------->| | |
| | | | |
| | (4) | | |
| |Access Challenge| | |
| |(EAP Id. Req. + | | |
| | (Network Info) | | |
| (5) |<---------------| | |
| EAP Id. Req. | | | |
|(Network Info)| | | |
|<-------------| | | |
| | | | |
| (6) | | | |
|EAP Id. Resp. | | | |
| | | | |
|------------->| (7) | | |
| |Access Request | | |
| |(EAP Id. Resp.+ | | |
| | Decorated NAI) | | |
| |--------------->| (8) | |
| | |Access Req.( | |
| | |EAP Id. Resp.+| |
| | |Decorated NAI)| |
| | |------------->| |
| | | |Access Request |
| | | |(EAP Id. Resp.)|
| | | |-------------->|
| ... | ... |.. | ... |
| <<EAP Authentication Methods>> |
| ... | ... |... | ... |
| | | | |
| | | | Access Accept |
| | | | (EAP Success) |
| | | |<--------------|
| | |Access Accept | |
| | |(EAP Success) | |
| | |<-------------| |
| |Access Accept | | |
| |(EAP Success) | | |
| |<---------------| | |
| EAP Success | | | |
|<-------------| | | |
Adrangi, et al. Expires March 30, 2004 [Page 15]
Internet Draft Network Discovery and Selection 16 August 2003
The following describes each message flow in details.
(1) The PWLAN AP issues an EAP-Identity Request to a WLAN Client
(2) The WLAN Client replies with an EAP-Identity Response
containing a normal NAI, or perhaps a Decorated NAI based on the
Network Information cached from the most recent authentication
session to the PWLAN AN.
(3) The AP creates a RADIUS Access-Request packet encapsulating
the EAP-Identity Response and sends it to the PWLAN RADIUS
server.
(4) The PWLAN RADIUS server sends a RADIUS Access-Challenge
packet encapsulating an EAP-Identity Request containing Network
Information. Or, the step 8 is executed if the Response does
already contain a Decorated NAI which specifies an MN recognized
by the PWLAN.
(5) The PWLAN AP forwards the EAP-Identity Request containing the
network information to the WLAN Client.
(6) The WLAN Client replies with an EAP-Identity Response
containing a Decorated NAI indicating the preferred MN.
(7) The AP forwards the EAP-Identity Response to the PWLAN RADIUS
server over RADIUS protocol.
(8) The PWLAN RADIUS server processes the received Access-Request
message containing a normal or a Decorated NAI and forwards it to
the appropriate MN RADIUS server.
(9) The EAP Authentication continues as described in [4].
The following summarizes pros and cons of this option.
Pros:
o It does not require any modifications to existing APs
o It uses a dedicated EAP-Identity Request for delivering
Network Information and hence no contention problem for using
the space in the Type-Data field.
Cons:
o It introduces an extra EAP-Identity Request/Response pair
o It requires software upgrades to the PWLAN RADIUS server
In the above options, if the HSN RADIUS server uses an updated
User-Name attribute, for example, in RADIUS Access-Challenge and
Adrangi, et al. Expires March 30, 2004 [Page 16]
Internet Draft Network Discovery and Selection 16 August 2003
Access-Accept packets, then this SHOULD be used in subsequent
RADIUS message flows between AP and Home RADIUS Server.
In order for a WLAN client software implementation to work with
all options transparently, the implementation MUST not expect the
arrival of Network Information on a particular EAP-Identity
Request (i.e., the initial or a subsequent Request). PWLAN AN
operators therefore MAY choose to deploy any of the above
delivery mechanism options in their network without risking the
interoperability. However, this document recommends deploying
delivery mechanism options 2 and 3 as they are backward-
compatible with the currently deployed APs.
2.2 Data Model / Syntax
Network Information needs to be structured in a general format
and syntax so that the WLAN Client software can interpret it and
behave accordingly. The syntax SHOULD have minimum overhead
because the proposed delivery mechanism (i.e., EAP-Identity
Request) doesn't support fragmentation and therefore size of the
data is limited by the link layer MTU.
Network Information is placed after the displayable string and
NULL in the EAP-Identity Request. It is structured as a set of
comma-separated attribute names following an optional prefix and
values according to the following ABNF [7].
identity-request-data = displayable-string [ %d0 network-info ]
displayable-string = *CHAR
network-info = item ["," item ]
item = attribute "=" value
attribute = [prefix] 1*( ALPHA / "-" / "_" / DIGIT)
prefix = 1* alphanum ô:ö
value = 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except
","
The intent of prefixes is to define a namespace to avoid
collision where private attribute names (i.e., not registered
with IANA) are used. Either Attribute names or their prefixes
MUST be registered with IANA [8]. The content of an attribute
MUST NOT contain a comma (ô,ö). The exact format and semantics of
the content of an attribute MUST be specified in the definition
of the attribute. Examples of prefixed and non-prefixed attribute
names are: 3GPP:HotSpotInfo, NAIPrefixes
Adrangi, et al. Expires March 30, 2004 [Page 17]
Internet Draft Network Discovery and Selection 16 August 2003
2.3 NAI Decoration
The WLAN client using EAP specifies the preference for a desired
MN by decorating the NAI in the EAP-Identity Response. The NAI
decoration refers to a syntax by which information is added to an
NAI in order to indicate the selected MN to the PWLAN AN. The
syntax MUST adhere to the following guidelines:
o It MUST NOT modify the root NAI [5](i.e., username@homerealm)
o It MUST NOT form an illegal NAI [5].
o It SHOULD NOT require any changes to existing RADIUS
infrastructure in terms of processing the syntax.
This document specifies a prefix-based syntax for decorating an
NAI. That is, the MN name(s) MUST be added as a prefix to the
NAI followed by a ô/ö. The MN name MUST be a valid NAI realm
name. For example,
Mediating-Net.com/username@homerealm.com
Multiple MN prefixes may be specified, meaning that the request
should be routed first to the MN specified in the first prefix,
followed by the MN specified in the next prefix and so on. For
example:
Mediating-Net-1.com/Mediating-Net-2.com/username@homerealm.com
3. Attribute Definitions
This section lists definitions of 1 or more EAP Network
Information attribute(s).
3.1 NAIPrefixes
It defines a Network Information attribute for specifying a list
of NAI realms corresponding to MNs that are recognized by the
PWLAN AN.
Attribute name: ôNAIPrefixesö
Attribute value:
NAIPrefixes-value = prefix [ ô;ö prefix ]
prefix = *( domainlabel "." ) toplabel
domainlabel = alphanum *( alphanum / "-" )
toplabel = ALPHA *alphanum
Adrangi, et al. Expires March 30, 2004 [Page 18]
Internet Draft Network Discovery and Selection 16 August 2003
The ôNAIPrefixesö attribute lists MN names that are recognized by
the PWLAN AN.
An example ôNAIPrefixesö attribute is shown below:
NAIPrefixes=ipass.com;mnc123.mcc334.3gppnetwork.org
4. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of a new namespace for the
EAP Network Information attributes or prefixes, in accordance with
[7]. The initial attribute(s) are listed in Section 3. New
attributes or prefixes are assigned using the First Come Fist
Served policy defined in [8].
Requests for new attribute names MUST be accompanied by a
reference to a publicly available description of the attribute
value syntax and semantics.
5. Security Considerations
Network Information delivered inside an EAP-Identity Request is
considered as a hint in guiding the WLAN Client to select the
desired MN. It SHOULD be treated similarly to the SSID in beacon
broadcast: subject to modification and spoofing.
It should also be noted that at least with some EAP methods, there
is no way for the HSN RADIUS server to verify that the MN used was
actually the same one that the WlAN client had requested.
6. Contributors
This document is a joint work of the contributing authors (in
alphabetical order):
- Farid Adrangi (Intel)
- Farooq Bari (AT&T Wireless)
- Adrian Buckley (Rim)
- Blair Bullock (iPass)
- Pasi Eronen (Nokia)
- Mark Grayson (Cisco)
- Victor Lortz (Intel)
- Jose Puthenkulam (Intel)
- Raquel Rodriguez (Nokia)
- Joe Salowey (Cisco)
- Marco Spini (Telecom Italia)
- Mark Watson (Nortel)
- Johanna Wild (Motorola)
Adrangi, et al. Expires March 30, 2004 [Page 19]
Internet Draft Network Discovery and Selection 16 August 2003
7. Acknowledgements
The authors would like to thank Bernard Aboba (of Microsoft), and
Jari Arkko (of Ericsson), Jesse Walker (of Intel), Prakash Iyer
(of Intel), Dj Johnston (of Intel), Serge Manning (of Sprint), Ed
Van Horne (of Cisco), Antonio Ascolese (of Telecom Italia), Simone
Ruffino (Telecom Italia), Luca Dell'uomo (of Telecom Italia),
Luciana Costa (of Telecom Italia), Basavaraj Patil (of Nokia) for
their feedback and guidance.
8. References
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[2] Calhoun, P., "Diameter Base Protocol",
draft-ietf-aaa-diameter-17 (work in progress), January 2003.
[3] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998.
[4] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", Internet draft (work in
progress), RFC 3579, September 2003.
[5] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[6] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[9] Blunk, L., "Extensible Authentication Protocol (EAP)", draft-
ietf-eap-rfc2284bis-04 (work in progress), June 2003.
AuthorsÆ Addresses
Farid Adrangi
Email: farid.adrangi@intel.com Phone:+1 503-712-1791
Farooq Bari
Email : Farooq.bari@attws.com Phone:
Adrian Buckley
Email: abuckley@rim.net Phone:
Blair Bullock
Adrangi, et al. Expires March 30, 2004 [Page 20]
Internet Draft Network Discovery and Selection 16 August 2003
Email: bbullock@ipass.com Phone:
Pasi Eronen
Email: pasi.eronen@nokia.com
Mark Grayson
Email: mgrayson@cisco.com Phone:
Victor Lortz
Email: victor.lortz@intel.com Phone:+1 503-264-3253
Jose Puthenkulam
Email: jose.p.puthenkulam@intel.com Phone:+1 503-264-6121
Raquel Rodriguez
Email: Raquel.rodriguez@nokia.com Phone: +44 1628434456
Mark watson
Email : mwatson@nortelnetworks.com Phone:
Johanna Wild
Email : johanna.wild@motorola.com Phone: +49 1729419016
Marco Spini
Email: marco.spini@tilab.com Phone:
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement
Adrangi, et al. Expires March 30, 2004 [Page 21]
Internet Draft Network Discovery and Selection 16 August 2003
Funding for the RFC Editor function is currently provided by
the Internet Society.
Adrangi, et al. Expires March 30, 2004 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-20 20:26:49 |