One document matched: draft-ohba-pana-netsel-00.txt




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]


PAFTECH AB 2003-20262026-04-23 08:53:58