PANA Working Group Y. Ohba Internet-Draft Toshiba Expires: May 15, 2008 November 12, 2007 Network Selection Support for Protocol for Carrying Authentication for Network Access (PANA) draft-ohba-pana-netsel-00 Status of this Memo 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 May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines an extension to PANA for network selection function. The network selection function allows a PaC to select an ISP (Internet Service Provider) among multiple choices. It also allows NAP (Network Access Provider) authentication and ISP authentication to be performed in separate PANA sessions. Ohba Expires May 15, 2008 [Page 1] Internet-Draft PANA Network Selection November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 2. Network Selection . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. NAP and ISP Separate Authentication . . . . . . . . . . . . 3 2.2. ISP Selection . . . . . . . . . . . . . . . . . . . . . . . 4 3. New Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. ISP-Information AVP . . . . . . . . . . . . . . . . . . . . 5 4.2. NAP-Information AVP . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Ohba Expires May 15, 2008 [Page 2] Internet-Draft PANA Network Selection November 2007 1. Introduction PANA (Protocol for carrying Authentication for Network Access) [I-D.ietf-pana-pana] is a link-layer agnostic network access authentication protocol that runs between a client that wants to gain access to the network and a server on the network side. PANA defines a new EAP [RFC3748] lower layer that uses IP between the protocol end points. This document defines a network selection function. The network selection function allows a PaC to select an ISP (Internet Service Provider) among multiple choices. It also allows NAP (Network Access Provider) authentication and ISP authentication to be performed in separate PANA sessions. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Network Selection The network selection function is provided by using 'N' (Network Selection) bit, a new bit in Flags field of PANA header. The PAA and PaC advertise their support for the network selection function in the initial PANA-Auth-Request and PANA-Auth-Answer messages with the 'S' (Start) bit set by having the 'N' (Network Selection) bits set. If the 'N' (Network Selection) bit is set in both messages, the PAA and PaC may start NAP and ISP Separate Authentication and/or ISP selection as described in the following subsections. 2.1. NAP and ISP Separate Authentication When NAP and ISP separate authentication is performed, two PANA sessions are established between the PaC and PAA, one for NAP authentication and the other for ISP authentication. For the PANA session used for NAP authentication, PANA-Auth-Request message sent in response to the initial PANA-Auth-Answer message with the 'S' (Start) bit set carries one NAP-Information AVP. The PANA session used for ISP authentication MUST NOT carry a NAP-Information AVP. When a PANA SA is established, the same NAP-Information AVP MUST be carried in the last PANA-Auth-Request message with 'C' (Complete) bit set with an AUTH AVP. Ohba Expires May 15, 2008 [Page 3] Internet-Draft PANA Network Selection November 2007 When NAP and ISP separate authentication is performed, cryptographic binding MUST be made between the two session. How the cryptographic binding is created is TBD. 2.2. ISP Selection ISP selection MAY be performed over a session on which the use of network selection function has been negotiated. ISP selection MUST NOT be performed over a session used for NAP authentication. ISP selection MAY be performed in the absence of NAP and ISP separate authentication. The PANA-Auth-Request message for the session used for ISP selection and sent in response to the initial PANA-Auth-Answer message with both the 'S' (Start) and 'N' (Network Selection) bits set carries one or more ISP-Information AVPs. The PANA-Auth-Answer message sent in response to this PANA-Auth-Request message carries at most one ISP- Information AVP to indicate the ISP chosen by the PaC. When a PANA SA is established, the ISP-Information AVP for the selected ISP MUST be carried in the last PANA-Auth-Request message with 'C' (Complete) bit set with an AUTH AVP. In the absence of an ISP explicitly selected and conveyed by the PaC, ISP selection is typically performed based on the client identifier (e.g., using the realm portion of an NAI carried in EAP method). A backend AAA protocol (e.g., RADIUS) will run between the AAA client on the PAA and a AAA server in the selected ISP domain. The PANA-based ISP selection mechanism dictates the next-hop AAA proxy on the PAA. If the NAP requires all AAA traffic to go through its local AAA proxy, it may have to rely on a mechanism to relay the selected ISP information from PAA (AAA client) to the local AAA proxy. The local AAA proxy can forward the AAA traffic to the selected ISP domain upon processing. Further details, including how the AAA client relays AAA routing information to the AAA proxy, are outside the scope of PANA. An alternative ISP selection mechanism is outlined in [RFC4284] which suggests advertising ISP information in-band with the ongoing EAP method execution. Deployments using the ISP selection mechanism defined in PANA need not use the alternative ISP selection mechanism. 3. New Flag A new 'N' (Network Selection) bit is defined in Flags field of PANA header as follows. Ohba Expires May 15, 2008 [Page 4] Internet-Draft PANA Network Selection November 2007 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R S C A P I N r r r r r r r r r| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N(Network Selection) This bit is set when the sender supports network selection function. The exact usage of this bit is described in Section 2. This bit is to be assigned by IANA. 4. New AVPs 4.1. ISP-Information AVP The ISP-Information AVP (AVP Code to be assigned by IANA) is of type Octet-String that carries an ISP name encoded as a RADIUS Operator- Name attribute value [I-D.ietf-geopriv-radius-lo]. 4.2. NAP-Information AVP The NAP-Information AVP (AVP Code to be assigned by IANA) is of type Octet-String that carries a NAP name encoded as a RADIUS Operator- Name attribute value [I-D.ietf-geopriv-radius-lo]. 5. Security Considerations When a PANA SA is not established, the information used for network selection function is not integrity protected and hence it is subject to be altered by an active attacker. When a PANA SA is established, the information used for network selection function is integrity protected with an AUTH AVP in the final PANA-Auth-Request and PANA-Auth-Answer exchange with 'C' (Complete) bit set. Therefore, It is strongly RECOMMENDED that the network selection function is used with a PANA SA. 6. IANA Considerations This document requires two PANA AVP Code values for ISP-Information AVP and NAP-Information AVP to be assigned by IANA. This document requires Bit 6 of Flags field of PANA header for 'N' (Network Selection) bit to be assigned by IANA. Ohba Expires May 15, 2008 [Page 5] Internet-Draft PANA Network Selection November 2007 7. Acknowledgments TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [I-D.ietf-pana-pana] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-18 (work in progress), September 2007. [I-D.ietf-geopriv-radius-lo] Tschofenig, H., "Carrying Location Objects in RADIUS and Diameter", draft-ietf-geopriv-radius-lo-16 (work in progress), August 2007. 8.2. Informative References [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006. Author's Address Yoshihiro Ohba Toshiba America Research, Inc. 1 Telcordia Drive Piscateway, NJ 08854 USA Phone: +1 732 699 5365 Email: yohba@tari.toshiba.com Ohba Expires May 15, 2008 [Page 6] Internet-Draft PANA Network Selection November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ohba Expires May 15, 2008 [Page 7]