view Side-By-Side changes
Network Working Group F. Adrangi Internet-Draft V. Lortz Expires: February6,12, 2005 Intel F. Bari AT&T Wireless P. Eronen Nokia M. Watson Nortel August8,14, 2004 Identity selection hints for Extensible Authentication Protocol (EAP)draft-adrangi-eap-network-discovery-02draft-adrangi-eap-network-discovery-03 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 athttp:// 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 February6,12, 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 February6,12, 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 usefulin roaming scenarios wherewhen the access network does not have a direct roaming relationship with the client's home network,but insteadso 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 clientAn EAP peer (hereafter, also referred to as peer) 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 EAPclient.peer. This information is sent to theclientpeer in an EAPIdentity RequestIdentity/Request message by appending it after the displayable message and a NUL character. Exactly how the identity hint information is used by theclientpeer depends largely on theclient'speer'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, theclientpeer 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 AlthoughAn EAP peer implementing this specification MUST be able to receive an identity hint in an initial EAP Identity/Request, or in a subsequent EAP Identity/Request. The EAP authenticator MAY send an identity hint to theproposed solution here is discussedpeer in thecontext of public IEEE 802.11 access networks, itinitial EAP Identity/Request. If the identity hint isapplicable to other access networks that usenot sent initially (such as when the authenticator does not support this specification), then if the EAP[2] for authentication and useserver receives an EAP Identity/ Response with an unacceptable NAI Realm, EAP servers implementing this specification SHOULD reply with an EAP Identity/Request containing an identity hint. If after the EAP server sends an EAP Identity/Request containing an identity hint, the peer responds with an EAP Identity/Response Adrangi, et al. Expires February 12, 2005 [Page 2] Internet-Draft Identity selection hints for EAP August 2004 containing an unacceptable NAIformat [1]Realm, then the EAP server MAY respond immediately with an EAP Failure packet, or it MAY first send an EAP-Notification providing information on the reason foridentifying users. This document assumes thattheAAA protocolfailure. Section 2 describes the packet format for structuring and presenting identity hint information to an EAP peer. The appendix inuse is RADIUS [8]. Diameter [7] could alsosection 6 describes the delivery options that can beused instead of RADIUS without introducing significant architectural differences. 1.2implemented by an access network to deliver identity hint information to an EAP peer. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thisAdrangi, et al. Expires February 6, 2005 [Page 2] Internet-Draft Identity selection hints for EAP August 2004document 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 NAI2. Packet format Identity hint information isuser@realm, where the realm part of the NAI indicatesplaced after thedomain 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 stringdisplayable 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 Adrangi, et al. Expires February 12, 2005 [Page 3] Internet-Draft Identity selection hints for EAP August 2004 EAP does not support fragmentation forIdentity RequestIdentity/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 useIdentity RequestEAP Identity/Request messages toAdrangi, et al. Expires February 6, 2005 [Page 3] Internet-Draft Identity selection hints for EAP August 2004send proprietary information to theclient.peer. 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 mechanismsIANA Considerations Thissection describes three different options for delivering the identitydocument does not define any new namespaces to be managed by IANA, and does not require any assignments in existing namespaces. 4. Security considerations Identity hint informationto the client. The main differenceiswhich entity in the access network creates thedelivered inside an EAP IdentityRequest: this could be eitherRequest before theaccess point or a RADIUS server. Access network operators can chooseuser authenticates todeploy any oftheoptions. Client implementation MUST support all three options. 3.1 Option 1: Initial request from access point In typical IEEE 802.11 wireless LANs,network, and before theinitial EAP Identity Requestnetwork issentauthenticated to the user. This information can be modified by an attacker. Therefore, it MUST be considered an unauthenticated hint that does not override any local policies at theaccess point.peer. Inthe simplest case,case the identity hint information issimply included in this request, as shown below. Wireless AP AN RADIUS next RADIUS client server server | | | | | 1. Association | | | |------------------->| | | | 2. EAP Id.Req. | | | | (NAIRealms) | | | |<-------------------| | | | 3.used to select a mediating network for NAI decoration, it should be noted that at least with some EAPId.Resp. | | | |------------------->| | | |methods, there is no way for the home network AAA server to verify that the mediating network used was actually the same one that the peer had requested. 5. 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. 6. Appendix (informative) - Delivery Options Although the delivery options are described in the context of IEEE 802.11 access networks, they are applicable to other access networks that use EAP [2] for authentication and use the NAI format [1] for identifying users. Also, the options assume that the AAA protocol in use is RADIUS [8]. Diameter [7] could also be used instead of RADIUS Adrangi, et al. Expires February 12, 2005 [Page 4] Internet-Draft Identity selection hints for EAP August 2004 without introducing significant architectural differences. The main difference amongst the options is which entity in the access network creates the EAP Identity/ Request. For example, the role of EAP server may be played by the EAP authenticator (where an initial EAP Request/Identity is sent with an identity hint), or a RADIUS proxy/server (where the NAI Realm is used for forwarding). When an Identity hint is sent by a RADIUS proxy/server, a RADIUS State (24) attribute can be used to help the RADIUS proxy/server determine if an identity hint had previously been sent by it to the EAP peer. The RADIUS proxy/server is EAP aware. It acts only on the RADIUS UserName(1) attribute and does not have to parse the EAP-Message attribute. Option 1: Initial EAP Identity/Request from access point In typical IEEE 802.11 wireless LANs, the initial EAP Identity/ Request is sent by the access point (i.e., EAP authenticator). In the simplest case, the identity hint information is simply included in this request, as shown below. EAP Access Point local RADIUS home RADIUS Peer proxy/server server |4.1. EAP | | | | Identity/Request | | | | (NAIRealms) | | | |<------------------| | | | 2. EAP | | | | Identity/Response | | | |------------------>| | | | | 3. Access-Request | | | | (EAPId.Resp.)| | | | Identity/Response) | | | |------------------->| | | | |5. Access-Request4.Access-Request | | | | (EAPId.Resp.)| | ||------------------->|| Identity/Response) | | | |------------------->| |<-- EAP conversation -->| | | |<-------------------EAP conversation ----------------------->| Current access points do not support this mechanism, so other options Adrangi, et al. Expires February 12, 2005 [Page 5] Internet-Draft Identity selection hints for EAP August 2004 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.2Option 2: InitialrequestEAP Identity/Request fromaccess networklocal RADIUSserverproxy/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 aclientpeer 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 EAPIdentity RequestIdentity/Request containing the identity hint information.Wireless AP ANEAP Access Point local RADIUSnexthome RADIUSclientPeer proxy/server serverserver | | || | 1.AssociationAccess-Request | | ||------------------->|| (EAP-Start) | | |2. Access-Request|------------------->| | | | 2.Access-Challenge |(EAP-Start)| | ||------------------->|(EAP | | |3.Access-Challenge| Identity/Request | | | |(EAP Id.Req.with NAIRealms) | | | |<-------------------| |NAIRealms)| 3. EAP | ||<-------------------|| |4. EAP Id.Req.Identity/Request | | | | (NAIRealms) | | ||<-------------------||<------------------| | | |5.4. EAPId.Resp.| | ||------------------->|| Identity/Response | | |6.|------------------>| | | | | 5. Access-Request | | | | (EAPId.Resp.)| | | | Identity/Response) | | | |------------------->| | | | |7.6. Access-Request | | | | (EAPId.Resp.)| | ||------------------->|| Identity Response) | | | |------------------->| | | | |<--|<------------------- EAP conversation--> |---------------------->| This option can work with current access points if they support the EAP-Start message.3.3Adrangi, et al. Expires February 12, 2005 [Page 6] Internet-Draft Identity selection hints for EAP August 2004 Option 3: SubsequentrequestEAP-Identity/Request fromaccess networklocal RADIUS proxy/ server In the third option, the access point sends the initial EAPIdntityIdentity/ Request without any hint information. Theclientpeer 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 theclient,peer, 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 forEAPAugust 2004 Wireless AP ANAccess Point local RADIUSnexthome RADIUSclient serverPeer Proxy/Server server | | | | | 1.Association | |EAP ||------------------->|| | |2. EAP Id.Req.Identity Request | | | | (w/o NAIRealms) | | ||<-------------------||<------------------| | | |3.2. EAPId.Resp.| | ||------------------->|| Identity Response | | |4.|------------------>| | | | | 3. Access-Request | | | | (EAPId.Resp.)| | | | Identity Response) | | | |------------------->| | | |5.Access-Challenge4.Access-Challenge | | | | (EAPId.Req. with| | | | Identity Request | | | | with NAIRealms) | | | |<-------------------| | |6.5. EAPId.Req.| | | | Identity Request | | | | (NAIRealms) | | ||<-------------------||<------------------| | | |7.6. EAPId.Resp.| | ||------------------->|| Identity Response | | |8.|------------------>| | | | | 7. Access-Request | | | | (EAPId.Resp.) || ||------------------->|| | Identity Response) | |9. Access-Request| |------------------->| | | |(EAP Id.Resp.)| 8. Access-Request | ||------------------->|| | (EAP | | |<-- 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 EAPIdentityRequest). 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 byResponse) | | | |------------------->| | | | | |<-------------------- EAP conversation --------------------->| Adrangi, et al. Expires February6,12, 2005 [Page6]7] Internet-Draft Identity selection hints for EAP August 2004IANA, 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.Thisinformation can be modified by an attacker. Therefore, is MUST be considered just an unauthenticated hint thatoption does notoverride any local policies at the client. In case the identity hint information is usedrequire changes toselect a mediating network for NAI decoration,existing NASes, so itshouldmay benoted 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 workpreferable inprogress 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.many environments. 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 InAdrangi, et al. Expires February 6, 2005 [Page 7] Internet-Draft Identity selection hints for EAP August 2004User 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. Adrangi, et al. Expires February 12, 2005 [Page 8] Internet-Draft Identity selection hints for EAP August 2004 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.comAdrangi, et al. Expires February 6, 2005 [Page 8] Internet-Draft Identity selection hints for EAP August 2004Pasi 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 February6,12, 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 February6,12, 2005 [Page 10] ----