Network Working Group F. Adrangi Internet-Draft V. Lortz Expires: February 6, 2005 Intel F. Bari AT&T Wireless P. Eronen Nokia M. Watson Nortel August 8, 2004 Identity selection hints for Extensible Authentication Protocol (EAP) 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, 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 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 6, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a mechanism that allows an access network to Adrangi, et al. Expires February 6, 2005 [Page 1] Internet-Draft Identity selection hints for EAP August 2004 provide identity selection hints to an EAP client. The purpose is to help the client in selecting the most appropriate 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 client's home network, but instead a mediating network, such as a roaming consortium or broker, is used. 1. Introduction In many roaming situations, an access network can have several roaming relationship, either with several home networks, or mediating networks such as 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 client in an EAP Identity Request message by appending it after the displayable message and a NUL character. Exactly how the identity hint information is used by the client depends largely on the client's local policy and configuration, and is outside the scope of this document. One possible application for this mechanism is to help in selecting what kind of NAI decoration [1] must be applied to allow proper routing of AAA messages to the home AAA server. If there are several possible mediating networks, the client can choose which one to use. However, exactly how the selection is made is beyond the scope of this document. See [6] for more detailed discussion about this problem space. 1.1 Applicability Although the proposed solution here is discussed in the context of public IEEE 802.11 access networks, it is applicable to other access networks that use EAP [2] for authentication and use the NAI format [1] for identifying users. This document assumes that the AAA protocol in use is RADIUS [8]. Diameter [7] could also be used instead of 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 "OPTIONAL" in this Adrangi, et al. Expires February 6, 2005 [Page 2] Internet-Draft Identity selection hints for EAP August 2004 document are to be interpreted as described in [3]. 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 [1] for more details on NAI format. 2. Packet format Identity hint information is placed after the displayable string and a NUL character in the EAP Identity Request. The following ABNF [4] defines a "NAIRealms" attribute for presenting the identity hint information. The attribute's value consists of a set of realm names separated by a semicolon. identity-request-data = [ displayable-string ] [ %x00 "NAIRealms=" realm-list ] displayable-string = *OCTET realm-list = realm / ( realm-list ";" realm ) The "OCTET" rule is defined in [4] and the "realm" rule is defined in [1]. A sample hex dump of an EAP Identity Request packet is 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 size of identity hint information is limited by the link MTU. The exact limit depends on the lower layer in question, but it is at least 1020 octets. Some existing systems are known to use Identity Request messages to Adrangi, et al. Expires February 6, 2005 [Page 3] Internet-Draft Identity selection hints for EAP August 2004 send proprietary information to the client. This proprietary information is considered to be part of the displayable-string in the ABNF shown above. In other words, the NUL character followed by the NAIRealms list MUST be placed at the end. 3. Delivery mechanisms This section describes three different options for delivering the identity hint information to the client. The main difference is which entity in the access network creates the EAP Identity Request: this could be either the access point or a RADIUS server. Access network operators can choose to deploy any of the options. Client implementation MUST support all three options. 3.1 Option 1: Initial request from access point In typical IEEE 802.11 wireless LANs, the initial 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 | | | | | 1. Association | | | |------------------->| | | | 2. EAP Id.Req. | | | | (NAIRealms) | | | |<-------------------| | | | 3. EAP Id.Resp. | | | |------------------->| | | | | 4. Access-Request | | | | (EAP Id.Resp.) | | | |------------------->| | | | | 5. Access-Request | | | | (EAP Id.Resp.) | | | |------------------->| | | | | | <-- EAP conversation --> | Current access points do not support this mechanism, so other options may be preferable. This option can also require configuring the identity hint information in a potentially large number of access points, which may be problematic if the information changes often. Adrangi, et al. Expires February 6, 2005 [Page 4] Internet-Draft Identity selection hints for EAP August 2004 3.2 Option 2: Initial request from access network RADIUS server This is similar to Option 1, but the initial EAP Identity Request is created by the access network RADIUS server instead of the access point. Once a client associates with an access network AP using IEEE 802.11 procedures, the AP sends an EAP-Start message [5] within a RADIUS Access-Request. The access network RADIUS server can then send the EAP Identity Request containing the identity hint information. Wireless AP AN RADIUS next RADIUS client server server | | | | | 1. Association | | | |------------------->| | | | | 2. Access-Request | | | | (EAP-Start) | | | |------------------->| | | | 3.Access-Challenge | | | | (EAP Id.Req. with | | | | NAIRealms) | | | |<-------------------| | | 4. EAP Id.Req. | | | | (NAIRealms) | | | |<-------------------| | | | 5. EAP Id.Resp. | | | |------------------->| | | | | 6. Access-Request | | | | (EAP Id.Resp.) | | | |------------------->| | | | | 7. Access-Request | | | | (EAP Id.Resp.) | | | |------------------->| | | | | | <-- 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 | | | |------------------->| | | | 2. EAP Id.Req. | | | | (w/o NAIRealms) | | | |<-------------------| | | | 3. EAP Id.Resp. | | | |------------------->| | | | | 4. Access-Request | | | | (EAP Id.Resp.) | | | |------------------->| | | | 5.Access-Challenge | | | | (EAP Id.Req. with | | | | NAIRealms) | | | |<-------------------| | | 6. EAP Id.Req. | | | | (NAIRealms) | | | |<-------------------| | | | 7. EAP Id.Resp. | | | |------------------->| | | | | 8. Access-Request | | | | (EAP Id.Resp.) | | | |------------------->| | | | | 9. Access-Request | | | | (EAP Id.Resp.) | | | |------------------->| | | | | | <-- EAP conversation --> | When the initial RADIUS Access-Request is received, if the access network RADIUS proxy cannot route the RADIUS packet to the next AAA hop, it SHOULD send identity hint information to the client (via Access-Challenge encapsulating an EAP Identity Request). When a subsequent RADIUS Access-Request is received, if the access network RADIUS proxy still cannot route the RADIUS packet to the next AAA hop, then it SHOULD discard the packet. Optionally, the access network RADIUS server can also send an error notification (via Access-Challenge encapsulating an EAP Notification) with an appropriate error message. This option does not require changes to existing NASes, so it may be preferable in many environments. 4. IANA Considerations This document does not define any new namespaces to be managed by Adrangi, et al. Expires February 6, 2005 [Page 6] Internet-Draft Identity selection hints for EAP August 2004 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 decoration, it should 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 client had requested. 6. Acknowledgements The authors would specially like to thank Jari Arkko and Bernard Aboba for 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 Adrian Buckley, Blair Bullock, Jose Puthenkulam, Johanna Wild, Joe Salowey, Marco Spini, Simone Ruffino, Mark Grayson, and Avi Lior for their support, feedback and guidance during the various stages of this work. 7. References 7.1 Normative 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. 7.2 Informative references [5] Aboba, B. and 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) Support For Extensible Authentication Protocol (EAP)", RFC 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. [8] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Authors' Addresses Farid Adrangi Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503-712-1791 EMail: farid.adrangi@intel.com Victor Lortz Intel Corporation 2111 N.E. 25th Avenue 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, WA 98052 USA Phone: +1 425-580-5526 EMail: 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-00045 Nokia Group Finland EMail: pasi.eronen@nokia.com Mark Watson Nortel Networks 2221 Lakeside Blvd Richardson, TX 75082 USA EMail: mwatson@nortel.com Adrangi, et al. Expires February 6, 2005 [Page 9] Internet-Draft Identity selection hints for EAP 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 February 6, 2005 [Page 10]