Network Working Group M. Abid Internet-Draft INRIA Expires: Juanuary 12, 2006 H. Afifi Int F. Kamoun CRISTAL N. Golmie NIST July 11, 2005 OSFR (Optimized network Selection for Fast Roaming) draft-abid-eap-osfr-00 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, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on Juanuary 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abid, et al. Expires Juanuary 12, 2006 [Page 1] Internet-Draft OSFR July 2005 Abstract In a public WLAN hotspot, we need to have an easy and secure way to authenticate users. We have to find also mobility solutions, given by providers, to perform well the roaming. A roaming mobile terminal MT may be within radio range of more than one access point AP. Therefore, we need to make an intelligent network selection decision after receiving some roaming information. Currently, the information is typically provisioned on the MTs as static roaming tables. But, this approach is not scalable when there is a large number of access points. In this draft, we propose our solution called OSFR, Optimized Network Selection for Fast Roaming to improve association speed and scalability. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2 Probe Request . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Probe Response . . . . . . . . . . . . . . . . . . . . . . . 9 4.4 Authentication Request . . . . . . . . . . . . . . . . . . . . 9 4.5 Authentication Response or Challenge Text . . . . . . . . . . 10 4.6 (Re)Association Request . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Abid, et al. Expires Juanuary 12, 2006 [Page 2] Internet-Draft OSFR July 2005 1. Introduction In a public WLAN hotspot, a roaming MT mobile terminal may be within radio range of more than one access point (AP). Therefore, we need to make an intelligent network selection decision after receiving some roaming information. Currently, the information is typically provisioned on the MTs as static roaming tables. But, this approach is not scalable when there are a large number of access points. In this draft, we propose our solution called OSFR, Optimized Network Selection for Fast Roaming to improve association speed and scalability. It consists in piggybacking the information in the 802.11 Authentication Request/Response. The main advantage of our system is that we donÆt need to (re)associate each time with the new AP, rather associate only with the appropriate one which speeds up the connection procedure and results in a seamless handover. 1.1 Terminology AAA Authentication ,Authorization and Accounting NAI Network Address Identifier [rfc2486bis]. MT Mobile Terminal AP The new Access Point that MT wants to associate with. AAA Wlan Server It is the Local Wireless LAN Server which has a list of vWISP virtual WISP that it has agreements with them. AAA Mediating Server The mediating Server that is localized in the path between AAA Wlan Server and AAA Home server. Abid, et al. Expires Juanuary 12, 2006 [Page 3] Internet-Draft OSFR July 2005 AAA Home Server The server which provides service for mobile node (MT has an account there). For clarity, we will omit AAA from the terminology. 1.2 Applicability Our solution is really helpful in these cases described in [ARK04]: o There is more than one available network attachment point, and the different points may have different characteristics. o The user has multiple sets of credentials. For instance, the user could have one set of credentials from a public service provider and another set from his company. o Providers share the same infrastructure, such as wireless access points. The mobile terminal will need to associate with the right network, so that it can reach its home server. Especially, working in public places can causes high latency, especially, when the place is full of clients. One of the problem that all people hate is the cut of receiving services. If we can not avoid it, at least, we try to reduce this time needed for network discovery and selection. 2. Design One of the important characteristics of our solution is that we want to know the roaming information before getting associated with AP. We also need to send the information in a secure way because we work before the association and the channel isnÆt secure. Our idea is based on Diffie-Hellman Key exchange (D-H Key) [RFC2631] and optimized to use the 802.11 Management Frames [WIR03]. First of all, in Beacon frame, we add the two parameters needed to generate the D-H keys. Then, in Probe Request, MT sends its public key YMT and in Probe Response, AP sends its public key YAP. Now the two devices can send encrypted data with D-H keys. In IEEE 802.11 specification, we have two kinds of authentication algorithm (Open System and Shared Key). In our solution, using one of the two will not cause problems because we only use Auth Request and Auth Response for Open System, Auth Request and Challenge Text for Shared Key. Abid, et al. Expires Juanuary 12, 2006 [Page 4] Internet-Draft OSFR July 2005 We aim to add roaming information which consists essentially in the identity of the intermediary WISP needed for Network Selection. If MT finds the WISP that it can reach its Home Server, it will send the identity of this Mediating Server. In that case, we will use the path passing by this Mediating Server in EAP session. We choose to send the list of WISP in the body of Management frame because this method helps us to use the maximum length for information. In some solution like Adrangi, et all [ADR05], the length used will be less than 1020 bytes. But when we use Management Frame body the least possibility will be when we piggyback information after Challenge Text and it will be 2048 bytes. OSFR assumes also backward compatibility with devices that do not support this technique. LetÆs give now more details about how OSFR performs. 3. Scenario In this scenario, we present all possible interactions between the actors. In the fellowing, we see all the message in OSFR scenario. MT AP AAA WLAN AAA Mediating AAA Home server Server Server | | | | | | /-------------| | | | |/ beacon | | | | |\ (p, g) | | | | | \-------------| | | | | | | | | | (1) | | | | | Probe Request | | | | | + YMN | | | | |------------- >| | | | | | | | | | (2) | | | | | Probe Response| | | | | +YAP | | | | |< ------------ | | | | | | | | | | (3) | | | | | Auth Request | | | | | + | | | | |(user@realm)D-H| | | | |------------- >| | | | | | | | | Abid, et al. Expires Juanuary 12, 2006 [Page 5] Internet-Draft OSFR July 2005 MT AP AAA WLAN AAA Mediating AAA Home server Server Server | | | | | | | EAP.Req | | | | | (user@realm) | | | | |------------- >| | | | | (4) | | | | | EAP.Resp | | | | | (List vWISP) | | | | |< ------------ | | | | | | | | | (5) | | | | | Auth Response | | | | | or | | | | | Challenge Text| | | | | + | | | | |(List vWISP)D-H| | | | |< ------------ | | | | | | | | | |Challenge Resp | | | | |............. >| | | | | | | | | |Confirm Success| | | | |< ............ | | | | | | | | | | (6a) | | | | |(re)association| | | | | Request | | | | | + | | | | |(NAI {Medaiting| | | | | Server})D-H | | | | |------------- >| | | | | (7) | | | | |(re)association| | | | | Response | | | | |< ------------ | | | | | | | | | | (8) | | | | | EAP Id. Req. | | | | |< -------------| | | | | | | | | | EAP Id. Resp. | | | | |------------- >| | | | | | Access Request| | | | |(EAP Id. Resp.)| | | | |------------- >| | | | | | | | Abid, et al. Expires Juanuary 12, 2006 [Page 6] Internet-Draft OSFR July 2005 MT AP AAA WLAN AAA Mediating AAA Home server Server Server | | | Access Request| | | | |(EAP Id. Resp.)| | | | |------------- >| | | | | | | | | | |Access Request | | | | |(EAP Id. Resp.)| | | | |------------- >| | ... | ... | ... | ... | | < EAP Authentication Methods > | | ... | ... | ... | ... | | | | | | | EAP Success | | | | |< ------------ | | | | | | | | | AP sends Beacon to alert the users about its presence. In our solution, AP is the one who chooses the parameters (prime number 'p' and base 'g') needed to generate the D-H keys. Here are all possible interactions in our scenario: 1 When MT sends to AP a Probe Request, it piggybacks its public key YMT. 2 AP sends Probe Response to MT and piggybacks its public key YAP. After exchanging the public keys, we can begin a secure session using D-H keys. Our modification will not depend on the type of IEEE 802.11 Authentication. 3 MT sends an Authentication Request including its identity user@realm encrypted with D-H key. 4 AP will send the identity in an EAP Request to WLAN Server. This later has a list of vWISP virtual WISP. WLAN Server will send the list to AP within an EAP Response. 5 A can be the Authentication Response "Open System" or the Challenge Text "Shared Key". AP piggybacks the list (encrypted with D-H key). MT needs this list to choose the "right" Mediating Server to reach its Home Server. If we choose Open System, we pass directly to (re)association. Otherwise, if it is Shared Key, we continue to send the Challenge Response and Success Access. 6 Now, all depends on the list received by MT: Abid, et al. Expires Juanuary 12, 2006 [Page 7] Internet-Draft OSFR July 2005 6a MT doesnÆt find the right Mediating Server in the list sent by AP; it will not (re)associate with AP and will seek for another one. For example, MT wants a French WISP but in the list there is only American WISP. 6b In the other case, MT sends (re)Association Request and piggybacks the NAI of the Mediating Server encrypted with D-H key. 7 AP sends (re)Association response to MT. 8 Now, EAP session can begin and we are sure that WLAN Server will reach the Home Server using a path including the chosen Mediating Server. 4. Packet Format In this section, we introduce all the changes that we need to do in the body of some Management Frames. The maximum size of the frame body is 2312 bytes. We will add some new Information Elements that have 3 fields: +---------------+----------+--------------------+ | Element ID(1) |Length(1) | Information(length)| +---------------+----------+--------------------+ We found in the IEEE 802.11 specification some reserved element ID (7-15, 32-255). We project to use some of this element ID to add our new Information Elements. The length given between () is in bytes for all fields. 4.1 Beacon We piggyback the prime 'p' and base 'g'. The length of the parameters 'p' and 'g' will be 1024 bits (128 bytes). In the IEEE 802.11 specification, the maximum length free in Beacon frame body is 334 bytes. We just add after TIM (Traffic Indication Map) 2 new fields one for parameter 'p' and the other for 'g'. The length of each field is 128 bytes. P: Information Elements +-----------------+---------------+--------+ | Element ID(1)=7 | Length(1)=128 | p(128) | +-----------------+---------------+--------+ Abid, et al. Expires Juanuary 12, 2006 [Page 8] Internet-Draft OSFR July 2005 G: Information Elements +-----------------+---------------+--------+ | Element ID(1)=8 | Length(1)=128 | g(128) | +-----------------+---------------+--------+ The new beacon frame body seems like: +----------------------+--------+--------+ | 802.11 Beacon Fields | P(130) | G(130) | +----------------------+--------+--------+ 4.2 Probe Request In the probe request, we add the MTÆs public key YMT. The later will be a new element information. +-----------------+---------------+--------+ | Element ID(1)=9 | Length(1)=128 | y(128) | +-----------------+---------------+--------+ The new Probe Request frame body seems like: +----------+---------------------+--------+ | SSID(34) | Supported rates(10) | Y(128) | +----------+---------------------+--------+ 4.3 Probe Response It is like Probe Request but source now is AP. We have the same Information Element y (Element ID=9) called YAP. The new Probe Request frame body seems like: +------------------------------+--------+ | 802.11 Probe Response Fields | Y(128) | +------------------------------+--------+ 4.4 Authentication Request Identity is a string which identifies user (ex mail address, login). The new Element Information contains the identity encrypted by D-H key. The max length of Identity will be 2304 bytes. +------------------+-----------+------------------+ | Element ID(1)=10 | Length(1) | identity(Length) | +------------------+-----------+------------------+ Abid, et al. Expires Juanuary 12, 2006 [Page 9] Internet-Draft OSFR July 2005 The frame body will be: +---------------------------+---------------------+ |802.11 Auth Request Fields | Identity(length +2) | +---------------------------+---------------------+ 4.5 Authentication Response or Challenge Text We add a new Element Information called List (encrypted with D-H key). +------------------+-----------+--------------+ | Element ID(1)=11 | Length(1) | list(Length) | +------------------+-----------+--------------+ 1 If Authentication algorithm number equals 0 (Open System), the frame body will be: +----------------------------+----------------+ |802.11 Auth Response Fields |List(length +2) | +----------------------------+----------------+ Here the maximum length of List is 2304 bytes. 2 If Authentication algorithm number equals 1 (Shared Key), the frame body will be: +----------------------------+----------------+ |802.11 Challenge Text Fields|List(length +2) | +----------------------------+----------------+ Here the maximum length of List is 2048 bytes. The 2 next frames in Shared Key Authentication wonÆt be modified. 4.6 (Re)Association Request Here we will add the last new Information Element NAI. It is the identifier of the Mediating Server (encrypted with D-H key). The maximum possible length for NAI is 2262 bytes. +------------------+-----------+-------------+ | Element ID(1)=12 | Length(1) | nai(Length) | +------------------+-----------+-------------+ 1 If we have Association Request, the frame body will be: +---------------------------------+----------------+ |802.11 Association Request Fields|NAI(length +2) | +---------------------------------+----------------+ Abid, et al. Expires Juanuary 12, 2006 [Page 10] Internet-Draft OSFR July 2005 2 If we have Re-association Request, the frame body will be: +-----------------------------------+----------------+ |802.11 Reassociation Request Fields|NAI(length +2) | +-----------------------------------+----------------+ The final (re)Association response will not be changed. Abid, et al. Expires Juanuary 12, 2006 [Page 11] Internet-Draft OSFR July 2005 5. Security Considerations OSFR use Diffie Hellman to secure the exchange of encryted data in the management level. All the security in this system is provided by the secrecy of the private keying material. If either sender or recipient private keys are disclosed, all messages sent or received using that key are compromised. Similarly, loss of the private key results in an inability to read messages sent using that key [RFC 2631]. Abid, et al. Expires Juanuary 12, 2006 [Page 12] Internet-Draft OSFR July 2005 6. Acknowledgments The authors would like to thank Walid Dabbous and our colleagues at Planete team for their comments and suggestions. Also, we thank the members of CRISTAL Laboratory. Abid, et al. Expires Juanuary 12, 2006 [Page 13] Internet-Draft OSFR July 2005 References [ARK04] J. Arkko and B. Aboba, "Network Discovery and Selection Problem", draft-ietf-eap-netsel-problem-02, October 2004. [WIR03] ANSI/IEEE Std 802.11, 1999 Edition (R2003), Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. [ADR05] F. Adrangi, V. Lortz, F. Bari, P. Eronen. "Identity selection hints for Extensible Authentication Protocol (EAP)", draft-adrangi-eap-network-discovery-and-selection-13.txt, May 2005. [RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631,June 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [rfc2486bis] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", draft-ietf-radext-rfc2486bis-05 (work in progress), July 2004. Authors' Addresses Mohamed Abid INRIA Sophia Antipolis 2004 route des lucioles BP 93 06902 Sophia Antipolis France EMail: Mohamed.Abid@sophia.inria.fr Hossam Afifi INT 9 rue, Charles Fourier Evry 91011 FRANCE Phone: +33 1 60 76 47 08 EMail: Hossam.Afifi@int-evry.fr Abid, et al. Expires Juanuary 12, 2006 [Page 14] Internet-Draft OSFR July 2005 Farouk Kamoun CRISTAL ENSI Universit‰ de la Manouba 2010 Tunisia Phone: +216 71 600 444 / +216 98 328 083 EMail: Farouk.kamoun@ensi.rnu.tn Nada Golmie NIST 100 Bureau Drive, Mail Stop 8920, Gaithersburg, Maryland, U.S.A. Phone: +1 301-975-4190 Mail: nada.golmie@nist.gov Abid, et al. Expires Juanuary 12, 2006 [Page 15] Internet-Draft OSFR July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2005). 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. 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. Abid, et al. Expires Juanuary 12, 2006 [Page 16]