[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

   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]
  

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/