view Side-By-Side changes

Extensible Authentication Protocol                            F. Adrangi

Network Working Group                                         F. Adrangi
Internet-Draft                                                  V. Lortz
Internet-Draft                                         Intel Corporation
Expires: December 16, 2004 February 6, 2005                                          Intel
                                                                 F. Bari
                                                           AT&T Wireless
                                                               P. Eronen
                                                                   Nokia Research Center
                                                               M. Watson
                                                                  Nortel
                                                           June 17,
                                                          August 8, 2004


 Mediating Network Discovery in the


 Identity selection hints for Extensible Authentication Protocol (EAP)
                 draft-adrangi-eap-network-discovery-01
                 draft-adrangi-eap-network-discovery-02

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, I certify each
   author represents that any applicable patent or other IPR claims of
   which I am he or she is aware have been or will be disclosed, and any of
   which I he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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. 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.

   This Internet-Draft will expire on December 16, 2004. February 6, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document defines a mechanism to enable a wireless client to
   discover roaming partners of that allows an access network over EAP.  The purpose to



Adrangi, et al.         Expires December 16, 2004 February 6, 2005                [Page 1]

Internet-Draft      Identity selection hints for EAP Network Discovery                 June         August 2004


   provide identity selection hints to an EAP client.  The purpose is to
   help a wireless the client select in selecting the most appropriate roaming
   partner as a next hop for routing of AAA packets. identity and NAI
   decoration to use.  This solution is especially useful in roaming
   scenarios where the access network does not have a direct
   relationship with the wireless client's home
   network - i.e., when AAA packets can not be directly routed from
   access network to the home network.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Applicability  . . . . . . . . . . . . . . . . . . . . . .  4
     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Data Model . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Delivery Mechanism . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Implementation Considerations  . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 13
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
       Intellectual Property and Copyright Statements . . . . . . . . 15



























Adrangi, et al.        Expires December 16, 2004                [Page 2]

Internet-Draft           EAP Network Discovery                 June 2004 network, but instead a mediating
   network, such as a roaming consortium or broker, is used.

1.  Introduction

   In wireless network access, the high level network topology is
   comprised of many roaming situations, an access network can have several
   roaming relationship, either with several home networks, or mediating networks, and home
   networks such as depicted in Figure 1.  RADIUS [2] protocol has been assumed for
   AAA mediation between roaming consortiums and brokers, or both.  A client
   can also have several sets of credentials, and its home network may
   have roaming relationships with several mediating networks.

   This document defines a mechanism that allows the access network to
   provide identity selection hints, and more specifically information
   about its roaming relationships, to an EAP client.  This information
   is sent to the home network
   although Diameter [3] could also be used instead of RADIUS without
   introducing significant architectural differences.

        Access Network         Mediating Network 1
    +-------------------+          +-----------+      Home
    |                   |          |           |      Network A
    |          +------+ |          |AAA server;|     +---------------+
    | +-----+  |Access| |          |   Other   |=====|Home AAA server|
    | |APs  |  |Router| |    ||====|Components |     |               |
    | |1..n |  +------+ |    ||    +------------     |     and       |
    | +-----+           |    ||                      |    Other      |
    |          +------+ |    || Mediating Network 2  |   Components  |
    | +-----+  |local | |    ||    +------------+    |               |
    | |Users|  |AAA   | |    ||    |AAA Server; |====|               |
    | |1..n |  |Server|============|    Other   |    +---------------+
    | +-----+  +------+ |    ||    | Components |
    |                   |    ||    +------------+
    +-------------------+    ||
                             || Mediating Network 3
                             ||    +------------+    Home
                             ||    |            |    Network B
                             ||    |AAA Server; |   +---------------+
                             ||====|   Other    |===|Home AAA Server|
                             ||    | Components |   |               |
                             ||    +------------+   |     and       |
                             ||                     |    Other      |
                             ||                     |  Components   |
                             ||=====================|               |
                                                    |               |
                                                    +---------------+

             Figure 1.  Network Access Arrangement.

   In roaming situations, EAP authentication exchanges [5] will be
   carried out between the wireless client in an EAP Identity Request message by appending
   it after the access network displayable message and an
   AAA server in a NUL character.

   Exactly how the home network directly when identity hint information is used by the two networks have a
   direct roaming relationship.  However when a wireless client roams to
   an access network that it does not recognize
   depends largely on the client's local policy and which does not have
   a direct roaming relationship with its home network, configuration, and
   is outside the AAA packets
   have scope of this document.

   One possible application for this mechanism is to help in selecting
   what kind of NAI decoration [1] must be routed through a mediating applied to allow proper
   routing of AAA network messages to the home
   network.  For inter operator settlement reasons, it is necessary to
   select the best AAA server.  If there are several
   possible mediating network.  For instance, in Figure 2, access



Adrangi, et al.        Expires December 16, 2004                [Page 3]

Internet-Draft           EAP Network Discovery                 June 2004


   through networks, the Mediating Network 1 may be cheaper for isp1 user, than if
   Mediating Network 2 is used.  However this decision client can not be choose which one to use.
   However, exactly how the selection is made
   by is beyond the access network as it would be unaware scope of
   this document.  See [6] for more detailed discussion about this
   problem space.

1.1  Applicability

   Although the roaming
   agreements of mediating networks 1 and 2 with proposed solution here is discussed in the isp1.  For this
   reason, context of
   public IEEE 802.11 access networks, it is desirable for the wireless client applicable to know which
   mediating other access
   networks are available through an access network, that use EAP [2] for authentication and
   influence use the decision of using NAI format
   [1] for identifying users.

   This document assumes that the desired mediating network.

                                     +---------+
                                     |         |---------> "isp1.com"
                                     | Roaming |
                 +---------+         | Group 1 |
                 |         |-------->|         |---------> "isp2.com"
   User "joe     | Access  |         +---------+
   @isp1.com"--->| Network |
                 |         |         +---------+
                 |         |-------->|         |---------> "isp1.com"
                 +---------+         | Roaming |
                                     | Group 2 |
                                     |         |---------> "isp3.com"
                                     +---------+

                Figure 2: Ambiguous AAA routing


   Influencing the mediating network selection problem can be divided
   into three sub-problems as follows:

   1.  A syntax by which mediating network information can be
       represented.

   2.  A delivery mechanism by which mediating network information protocol in use is
       conveyed to a wireless client.

   3.  A general mechanism by which a wireless client's selection can be
       conveyed to the access network.

   Section 2.7 of [6] discusses the conditions upon which NAIs can RADIUS [8].
   Diameter [7] could also be used to affect AAA routing, i.e., problem 3 above.  Problems 1 and 2
   are discussed in this document.

1.1  Applicability

   Although the proposed solution here is discussed in the context instead of
   public 802.11 access network deployment, it is applicable to other
   public wireless access networks where the wireless clients use the
   EAP specification framework [5] for authentication, RADIUS without introducing
   significant architectural differences.

1.2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and they present
   their identity to the network "OPTIONAL" in NAI [6] format. this



Adrangi, et al.         Expires December 16, 2004 February 6, 2005                [Page 4] 2]

Internet-Draft      Identity selection hints for EAP Network Discovery                 June         August 2004


1.2  Terminology


   document are to be interpreted as described in [3].

   Network Access Identifier (NAI)
      An identifier that represents a wireless 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.  Please  See [6] [1] for more details on NAI
      format.

   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 [2].


2.  Data Model

   Mediating network information needs to be structured in a general  Packet format and syntax so that the EAP 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.

   Mediating network

   Identity hint information is placed after the displayable string and NULL
   a NUL character in the EAP-Identity EAP Identity Request.  It is structured as  The following ABNF [4]
   defines a "NAIRealms" attribute for presenting the identity hint
   information.  The attribute's value consists of a set of
   comma-separated attribute realm names and values according to the following
   ABNF [1]:
   separated by a semicolon.

      identity-request-data = [ displayable-string ]
                              [ %d0 network-info %x00 "NAIRealms=" realm-list  ]
      displayable-string    = *CHAR

      network-info = attribute "=" value

      attribute =  1*( ALPHA / "-" / "_" / DIGIT)

      value *OCTET
      realm-list            = 1*( %x01-2B realm / %x2D-FF
                              ( realm-list ";" realm ) ; any non-null UTF-8 char except ","

   The CHAR, DIGIT, ALPHA terminals are "OCTET" rule is defined in [1].

   Only one attribute [4] and the "realm" rule is defined here, the NAIRealms attribute.  The use in
   [1].

   A sample hex dump of this facility for other purposes an EAP Identity Request packet is discouraged due to shown below.

      01                        ; Code: Request
      00                        ; Identifier: 0
      00 43                     ; Length: 67 octets
      01                        ; Type: Identity
      48 65 6c 6c 6f 21 00 4e   ; "Hello\0NAIRealms=example.com;mnc014.
      41 49 52 65 61 6c 6d 73   ; mcc310.3gppnetwork.org"
      3d 69 73 70 2e 65 78 61
      6d 70 6c 65 2e 63 6f 6d
      3b 6d 6e 63 30 31 34 2e
      6d 63 63 33 31 30 2e 33
      67 70 70 6e 65 74 77 6f
      72 6b 2e 6f 72 67

   EAP does not support fragmentation for Identity Request messages, so
   the limited
   amount size of space available identity hint information is limited by the link MTU.
   The exact limit depends on the lower layer in EAP packets. question, but it is at
   least 1020 octets.

   Some existing systems are known to use Identity Request messages to



Adrangi, et al.         Expires December 16, 2004 February 6, 2005                [Page 5] 3]

Internet-Draft      Identity selection hints for EAP Network Discovery                 June         August 2004


   The format and semantics of the NAIRealms attribute value are as
   follows:

       value = Realm [ ";" Realm ]


   Where


   send proprietary information to the Realm client.  This proprietary
   information is defined considered to be part of the displayable-string in [6].

   An example "NAIRealms" attribute is the
   ABNF shown below:

       NAIRealms=anyisp.com;mnc123.mcc334.3gppnetwork.org above.  In other words, the NUL character followed by the
   NAIRealms list MUST be placed at the end.

3.  Delivery Mechanism

   There are mechanisms

   This section describes three possible different options of for delivering mediating network the
   identity hint information to a wireless client by using an EAP-Identity Request.
   These options are:

   Option 1 -  Use the Initial EAP-Identity Request issued by the access
   network NAS

      Mediating network information client.  The main difference is pushed to a wireless client
   which entity in the initial EAP-Identity Request issued by the AP.

   Option 2 - Use the initial EAP-Identity Request issued by the access network RADIUS server

      This is similar to Option 1, but creates the initial EAP-Identity Request
      is issued by EAP Identity Request:
   this could be either the access network RADIUS Server instead.  Once point or a
      wireless client associates with an access RADIUS server.

   Access network AP using native
      IEEE 802.11 procedures, the AP sends an EAP-Start message [4]
      within a RADIUS Access-Request to trigger an EAP conversation
      initiated by the access network RADIUS server.

   Option 3 - Use a subsequent EAP-Identity Request issued by the access
   network RADIUS server

      Mediating network information is delivered to a wireless client in
      a subsequent EAP-Identity request, after the initial EAP-Identity
      Request/Response exchange, issued by by the access network RADIUS
      server.


4.  Implementation Considerations

   - In general, an option that requires changes only to a central AAA
   server is much preferred than a one that impacts a distributed set of



Adrangi, et al.        Expires December 16, 2004                [Page 6]

Internet-Draft           EAP Network Discovery                 June 2004


   APs.  The reasons for this preference include ease of operation and
   deployment, update costs, backwards compatibility and possible impact
   on current standards.  Option 3 is therefore preferred as it does not
   require any changes to the AP.  Option 2 is also equally desirable if
   the AP supports the EAP-Start message [4].

   - In order for a wireless client software implementation to work with
   all options transparently, operators can choose to deploy any of the options.
   Client implementation MUST not require the
   arrival of mediating network information on a particular EAP-Identity
   Request (i.e., the initial or a subsequent Request).  Access network
   operators therefore MAY choose to deploy any of the above delivery
   mechanism options in their network without losing interoperability.
   However, delivery mechanism options 2 and 3 are recommended as they
   are backward-compatible with the currently-deployed APs.

   - When support all three options.

3.1  Option 3 is used, upon receipt of a RADIUS Access-Request
   packet containing the initial EAP-Identity Response, the 1: Initial request from access
   network RADIUS proxy/server MAY send an EAP-Identity Request
   containing mediating network information to the point

   In typical IEEE 802.11 wireless client if it
   cannot route the RADIUS packet to the next AAA hop based on the realm
   portion (i.e., string after the @ sign) of the NAI in the RADIUS
   User-Name attribute.  When a RADIUS Access-Request containing a
   subsequent EAP-Identity Response is received, if the RADIUS proxy/
   server still cannot route the RADIUS packet to the next AAA hop based
   on the realm portion of the NAI, then it MUST discard the packet.

   - The use of the mechanism described in this document SHOULD be
   reserved for situations where the WLAN client can not identify a
   direct route to its home network based on the available SSIDs in the
   hotspot.

5.  IANA Considerations

   This document does not define a new name space, therefore, there are
   no considerations for IANA.

6.  Security Considerations

   Mediating network information delivered inside an EAP-Identity
   Request before the user authenticates to the network.  Therefore, it
   is considered as a hint in guiding the wireless client to select the
   desired mediating network through which the AAA packets should be
   routed.

   It should also be noted that at least with some EAP methods, there is
   no way for the home network RADIUS server to verify that the
   mediating network used was actually the same one that the wireless
   client had requested.



Adrangi, et al.        Expires December 16, 2004                [Page 7]

Internet-Draft           EAP Network Discovery                 June 2004


7.  Appendix

   The railroad diagrams below illustrate conversations between a
   wireless client, AP, Access Network (AN) RADIUS proxy/server,
   Mediating Network (MN) RADIUS proxy/server, and Home Network (HN)
   RADIUS server for the three options described above.

   Option 1 - Use the Initial EAP-Identity Request issued by the access
   network AP

      Wireless       AP         AN RADIUS       MN RADIUS    HN RADIUS
      Client                       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 >               |
      |   ...         |               |  ...          | ...           |
      |               |               |               |               |
      |               |               |               |               |
      | EAP Success   |               |               |               |
      |< ------------ |               |               |               |
      |               |               |               |               |

   The following describes each message flow in details.

   1.  The AP sends the initial EAP-Identity Request containing
       mediating network information to the wireless client.



Adrangi, et al.        Expires December 16, 2004                [Page 8]

Internet-Draft           EAP Network Discovery                 June 2004


   2.  The wireless client sends an EAP-Identity Response containing a
       Decorated NAI indicating the selected MN to the AP.  OR,

   3.  The wireless client sends an EAP-Identity Response containing a
       normal NAI (i.e., non-decorated)to the AP.

   4.  The AP sends a RADIUS Access Request packet containing the
       EAP-Identity Response to the access network RADIUS proxy/server
       as described in [4].  Please note that NAI in the EAP-Identity
       Response is copied to the RADIUS User-Name attribute in the
       Access-Request packet as per [4].

   5.  The access network RADIUS proxy/server forwards the received
       Access-Request packet to the next AAA hop based on the realm
       portion of the NAI in the RADIUS User-Name attribute.

   6.  The MN RADIUS proxy/server forwards the received Access-Request
       packet based on the NAI in the RADIUS User-Name attribute to the
       next AAA hop (i.e., HN RADIUS Server).

   7.  The EAP Authentication continues as described in [4].

   Option 2 - Use LANs, the initial EAP-Identity Request issued by the access
   network RADIUS server.


      Wireless       AP         AN RADIUS       MN RADIUS    HN RADIUS
      Client                       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. |                |              |               |
       |              |                |              |               |



Adrangi, et al.        Expires December 16, 2004                [Page 9]

Internet-Draft           EAP Network Discovery                 June 2004


       |   (5b)       |                |              |               |
       |EAP Id. Resp. |                |              |               |
       |------------ >|    (6)         |              |               |
       |              |Access EAP Identity
   Request is sent by the access point.  In the simplest case, the
   identity hint information is simply included in this request, as
   shown below.

   Wireless               AP              AN RADIUS         next RADIUS
    client                                  server              server
     |                    |                    |                    |              |(EAP Id. Resp.) |              |
     | 1. Association     |              |-------------- >|   (7)                    |                    |
     |------------------->|                    |                    |                |Access Req. (
     |     2. EAP Id.Req. |                    |                    |                |EAP Id. Resp.)|
     |        (NAIRealms) |                    |                |------------ >|                    |
     |<-------------------|                    |                    |
     |              |Access Request 3. EAP Id.Resp.    |                    |                    |
     |------------------->|                    |              |(EAP Id. Resp.)|                    |
     |                    |              |------------- >| 4. Access-Request  |   ...                    |     ...        |..
     |  ...                    |    (EAP Id.Resp.)  |                  < EAP Authentication Methods >                    |
     |   ...                    |------------------->|                    |                |...
     | ...                    |                    | 5. Access-Request  |
     |                    |                    |    (EAP Id.Resp.)  | EAP Success
     |                    |                    |------------------->|
     |                    |
       |< ------------|                    |                    |
     |


   The following describes each message flow in details.

   1.  The wireless client associates with the AP.

   2.  An EAP-Start message encapsulated within a RADIUS Access-Request
        sent to the access network RADIUS server.

   3.  The access network RADIUS server processes the received
        Access-Request message and initiates an                   <-- EAP conversation by
        sending an EAP-Identity Request containing mediating network
        information encapsulated within a RADIUS Access-Challenge.

   4.  The AP extracts the EAP-Identity Request from the received
        Access-Challenge and sends it to the wireless client.

   5.  The wireless client sends an EAP-Identity Response containing its
        decorated NAI indicating the selected MN to the AP.  OR,

   6.  The wireless client sends an EAP-Identity Response containing a
        normal NAI (i.e., non-decorated) to the AP.

   7.  The AP sends a RADIUS Access-Request packet containing the
        EAP-Identity Response  to the -->                   |

   Current access network RADIUS server as
        described in [4].  Please note that NAI in the EAP-Identity
        Response is copied to points do not support this mechanism, so other options
   may be preferable.  This option can also require configuring the RADIUS User-Name attribute
   identity hint information in the
        Access-Request packet as per [4].

   8.  The a potentially large number of access network RADIUS proxy/server forwards
   points, which may be problematic if the received information changes often.






Adrangi, et al.         Expires December 16, 2004 February 6, 2005                [Page 10] 4]

Internet-Draft      Identity selection hints for EAP Network Discovery                 June         August 2004


        Access-Request packet


3.2  Option 2: Initial request from access network RADIUS server

   This is similar to Option 1, but the next AAA hop based on the realm
        portion of the NAI in initial EAP Identity Request is
   created by the access network RADIUS User-Name attribute.

   9.  The MN RADIUS proxy/server forwards the received Access-Request
        packet based on the NAI in server instead of the RADIUS User-Name attribute  to access
   point.  Once a client associates with an access network AP using IEEE
   802.11 procedures, the next AAA hop (i.e., HN AP sends an EAP-Start message [5] within a
   RADIUS Server).

   10. Access-Request.  The EAP Authentication continues as described in [4].

   Option 3 - Use a subsequent EAP-Identity Request issued by the access network RADIUS server can then
   send the EAP Identity Request containing the identity hint
   information.

   Wireless               AP              AN RADIUS       MN RADIUS    HN         next RADIUS
      Client
    client                                  server              server      Server
     |     (1)                    |                    |                    |
     | 1. Association     | EAP Id. Req.                    |                    |
     |------------------->|                    |                    |
       |< ------------|
     |                    | 2. Access-Request  |                    |
     |                    |    (EAP-Start)     |                    |
     |    (2)                    |------------------->|                    |
     |                    | 3.Access-Challenge |                    |
     | EAP Id. Resp.|                    |  (EAP Id.Req. with |                    |
       |------------ >|     (3)
     |                    |         NAIRealms) |                    |              |Access Request
     |                    |<-------------------|                    |
     |     4. EAP Id.Req. |                    |              |(EAP Id. Resp.)                    |
     |        (NAIRealms) |                    |              |-------------- >|                    |
     |<-------------------|                    |                    |
     | 5. EAP Id.Resp.    |                    |                    |
     |------------------->|                    |                    |     (4)
     |                    | 6. Access-Request  |                    |              |Access Challenge|
     |                    |    (EAP Id.Resp.)  |              |(EAP Id. Req. +                    |
     |                    |------------------->|                    |
     |                    | (Network Info)                    | 7. Access-Request  |
     |                    |    (5)       |< --------------|                    |    (EAP Id.Resp.)  |
     | EAP Id. Req.                    |                    |------------------->|
     |                    |                    |
       |(Network Info)|                    |
     |                   <-- EAP conversation -->                   |

   This option can work with current access points if they support the
   EAP-Start message.

3.3  Option 3: Subsequent request from access network RADIUS server

   In the third option, the access point sends the initial EAP Idntity
   Request without any hint information.  The client then responds with
   an Identity Response, which is forwarded to the local RADIUS server.
   If the RADIUS server cannot route the message based on the identity
   provided by the client, it sends a second EAP Identity Request
   containing the identity hint information.




Adrangi, et al.         Expires February 6, 2005                [Page 5]

Internet-Draft      Identity selection hints for EAP         August 2004


   Wireless               AP              AN RADIUS         next RADIUS
    client                                  server              server
     |
       |< ------------|                    |                    |                    |
     | 1. Association     |                    |                    |
     |------------------->|                    |                    |    (6)
     |     2. EAP Id.Req. |                    |                    |
       |EAP Id. Resp.
     |    (w/o NAIRealms) |                    |                    |
     |<-------------------|                    |                    |
     | 3. EAP Id.Resp.    |                    |
       |------------ >|    (7)                    |
     |------------------->|                    |                    |
     |              |Access Request                    | 4. Access-Request  |                    |
     |              |(EAP Id. Resp.)                    |    (EAP Id.Resp.)  |                    |
     |              |-------------- >|   (8)                    |------------------->|                    |
     |                    | 5.Access-Challenge |                |Access Req.(                    |
     |                    |  (EAP Id.Req. with |                |EAP Id. Resp.)|                    |
     |                    |                |------------ >|         NAIRealms) |                    |
     |                    |<-------------------|                    |              |Access Request
     |     6. EAP Id.Req. |                    |                    |              |(EAP Id. Resp.)|
     |        (NAIRealms) |                    |              |------------- >|                    |   ...
     |<-------------------|                    |     ...        |..                    |  ...
     |



Adrangi, et al.        Expires December 16, 2004               [Page 11]

Internet-Draft 7. EAP Network Discovery                 June 2004 Id.Resp.    |                   < EAP Authentication Methods >                    |                    |   ...
     |------------------->|                    |     ...        |...                    | ...
     |                    | 8. Access-Request  |                    |
     |                    | EAP Success    (EAP Id.Resp.)  |                    |
     |                    |------------------->|                    |
       |< ------------|
     |                    |                    |

   The following describes each message flow in details.

   1.  The access network AP issues an EAP-Identity Request to a
       wireless client

   2.  The wireless client replies with an EAP-Identity Response
       containing a normal NAI (i.e., non-decorated), or perhaps a
       Decorated NAI [6] based on the mediating network information
       cached from the most recent authentication session to the access
       network.

   3.  The AP creates a RADIUS 9. Access-Request packet encapsulating the
       EAP-Identity Response and sends it to  |
     |                    |                    |    (EAP Id.Resp.)  |
     |                    |                    |------------------->|
     |                    |                    |                    |
     |                   <-- EAP conversation -->                   |

   When the access network RADIUS
       server.

   4.  The access network RADIUS proxy/server sends a initial RADIUS
       Access-Challenge packet encapsulating an EAP-Identity Request
       containing mediating network information.  Or, the step 8 Access-Request is
       executed received, if the access
   network proxy/server can RADIUS proxy cannot route the packet
       based on the realm portion of the NAI in the RADIUS User-Name
       attribute packet to the next AAA hop.

   5.  The access network AP forwards the EAP-Identity Request
       containing the mediating network
   hop, it SHOULD send identity hint information to the wireless
       client.

   6.  The wireless client replies with (via
   Access-Challenge encapsulating an EAP-Identity Response
       containing EAP Identity Request).  When a Decorated NAI indicating the preferred MN.  Wireless
       client can still send an undecorated NAI to the
   subsequent RADIUS proxy/
       server, if it Access-Request is a legacy client.  It should also be noted that
       the wireless client may also decide not to connect to received, if the access network in the absence of
   RADIUS proxy still cannot route the desired MN in RADIUS packet to the received MN
       information in step (4).

   7.  The access network AP forwards next AAA
   hop, then it SHOULD discard the EAP-Identity Response to packet.  Optionally, the access
   network RADIUS server over RADIUS protocol.

   8.  The access network RADIUS proxy/server forwards the received
       Access Request to the can also send an error notification (via
   Access-Challenge encapsulating an EAP Notification) with an
   appropriate MN RADIUS server based on the
       realm portion of the NAI error message.

   This option does not require changes to existing NASes, so it may be
   preferable in the RADIUS User-Name attribute.

   9.  The MN RADIUS proxy/server forwards the received Access-Request many environments.

4.  IANA Considerations

   This document does not define any new namespaces to be managed by



Adrangi, et al.         Expires December 16, 2004 February 6, 2005                [Page 12] 6]

Internet-Draft      Identity selection hints for EAP Network Discovery                 June         August 2004


       packet based on


   IANA, and does not require any assignments in existing namespaces.

5.  Security considerations

   Identity hint information is delivered inside an EAP Identity Request
   before the user authenticates to the network, and before the network
   is authenticated to the user.  This information can be modified by an
   attacker.  Therefore, is MUST be considered just an unauthenticated
   hint that does not override any local policies at the client.

   In case the identity hint information is used to select a mediating
   network for NAI in decoration, it should be noted that at least with
   some EAP methods, there is no way for the home network RADIUS User-Name attribute server
   to verify that the
       next AAA hop (i.e., HN RADIUS Server).  The EAP Authentication
       continues as described in [4].


8.  Acknowledgement mediating network used was actually the same one
   that the client had requested.

6.  Acknowledgements

   The authors would specially like to thank Jari Arkko (of Ericsson) and Bernard
   Aboba for his their help in scoping the problem, for reviewing the draft
   work in progress and for suggesting improvements to it.

   The authors would also like to acknowledge and thank Jari Arkko (of
   Ericson), Bernard Aboba (of Microsoft), Adrian Buckley (of RIM), Buckley,
   Blair Bullock (of iPass) , Bullock, Jose Puthenkulam (of Intel), Puthenkulam, Johanna Wild
   (of Motorola), Wild, Joe Salowey (of Cisco), Salowey, Marco Spini (of Telecom
   Italia),
   Spini, Simone Ruffino (of Telecom Italia) and Ruffino, Mark Grayson (of
   Cisco)for Grayson, and Avi Lior for their support,
   feedback and guidance during the various stages of this work.

9.

7.  References

9.1

7.1  Normative References references

   [1]  Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
        Access Identifier", draft-arkko-roamops-rfc2486bis-02 (work in
        progress), July 2004.

   [2]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
        Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
        June 2004.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [2]  Rigney, C., Willens, S., Rubens, A.

7.2  Informative references

   [5]  Aboba, B. and W. Simpson, "Remote P. Calhoun, "RADIUS (Remote Authentication Dial In



Adrangi, et al.         Expires February 6, 2005                [Page 7]

Internet-Draft      Identity selection hints for EAP         August 2004


        User Service (RADIUS)", Service) Support For Extensible Authentication Protocol
        (EAP)", RFC 2865, June
        2000.

   [3] 3579, September 2003.

   [6]  Arkko, J. and B. Aboba, "Network Discovery and Selection
        Problem", draft-ietf-eap-netsel-problem-01 (work in progress),
        July 2004.

   [7]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.

   [4]  Aboba, B.

   [8]  Rigney, C., Willens, S., Rubens, A. and P. Calhoun, "RADIUS (Remote W. Simpson, "Remote
        Authentication Dial In User Service) Support For Extensible Authentication Protocol
        (EAP)", Service (RADIUS)", RFC 3579, September 2003.

   [5]  Blunk, L., "Extensible Authentication Protocol (EAP)",
        draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004.

   [6]  Aboba, B., "The Network Access Identifier",
        draft-arkko-roamops-rfc2486bis-00 (work in progress), February
        2004.

9.2  Informative References






Adrangi, et al.        Expires December 16, 2004               [Page 13]

Internet-Draft           EAP Network Discovery 2865, June 2004
        2000.


Authors' Addresses

   Farid Adrangi
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro
   Hillsboro, OR  97124
   USA

   Phone: +1 503-712-1791
   EMail: farid.adrangi@intel.com


   Victor Lortz
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro
   Hillsboro, OR  97124
   USA

   Phone: +1 503-264-3253
   EMail: victor.lortz@intel.com


   Farooq Bari
   AT&T Wireless
   7277 164th Avenue N.E.
   Redmond
   Redmond, WA  98052
   USA

   Phone: +1 425-580-5526
   EMail: Farooq.bari@attws.com farooq.bari@attws.com






Adrangi, et al.         Expires February 6, 2005                [Page 8]

Internet-Draft      Identity selection hints for EAP         August 2004


   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-0005
   FIN-00045 Nokia Group
   Finland

   EMail: pasi.eronen@nokia.com


   Mark Watson
   Nortel
   2221, Networks
   2221 Lakeside Blvd
   Richardson
   Richardson, TX  75082
   USA

   EMail: mwatson@nortel.com



































Adrangi, et al.         Expires December 16, 2004 February 6, 2005                [Page 14] 9]

Internet-Draft      Identity selection hints for EAP Network Discovery                 June         August 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Adrangi, et al.         Expires December 16, 2004 February 6, 2005               [Page 15] 10]




----