PANA Working Group                                               Y. Ohba
Internet-Draft                                                   Toshiba
Expires: September 4, 2006                                 March 3, 2006 May 21, 2008                                  November 18, 2007

                  Pre-authentication Support for PANA
                       draft-ietf-pana-preauth-01
                       draft-ietf-pana-preauth-02

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 September 4, 2006. May 21, 2008.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

Abstract

   This document defines an extension to the PANA protocol used for
   proactively establishing a PANA SA (Security Association) between a
   PaC in an access network and a PAA in another access network to which
   the PaC may move.  The proposed method operates across multiple
   administrative domains.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Specification of Requirements  . . . . . . . . . . . . . .  3
   2.  Terminogy  . . . . . . . . . . . . . . . . . . . . . . . . . .  5  3
   3.  Pre-authentication Procedure . . . . . . . . . . . . . . . . .  7  4
   4.  PANA Extensions  . . . . . . . . . . . . . . . . . . . . . . . 11  7
   5.  Authorization and Accounting Considerations  . . . . . . . . . 12  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14  9
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 18 10

1.  Introduction

   The PANA protocol [I-D.ietf-pana-pana] carries EAP messages between a
   PaC (PANA Client) and a PAA (PANA Authentication Agent) in the access
   network.  If the PaC is a mobile device and is capable of moving one
   access network to another while running its applications, it is
   critical for the PaC to perform a handover seamlessly without
   degrading the performance of the applications during the handover
   period.  When the handover requires the PaC to establish a PANA
   session with the PAA in the new access network, the signaling to
   establish the PANA session should be completed as fast as possible.

   There is an optimization method based on Context Transfer Protocol
   (CTP) [RFC4067] to reduce the signaling delay for establishing a PANA
   session with a new PAA upon a handover [I-D.ietf-pana-mobopts][I-
   D.ietf-pana-cxtp].

   The CTP-based method have the following issues.  First, it is not
   readily applicable to handovers across multiple administrative
   domains since having a security association between PAAs in different
   administrative domains is practically difficult.  Second, even within
   a single administrative domain, the CTP-based method is difficult to
   work when the previous and new access networks have different
   authorization characteristics, e.g., on use of NAP and ISP separate
   authentication.  Third, the CTP-based method relies on deriving the
   PANA_MAC_Key used between the PaC and the PAA in the new access
   network from the AAA-Key used between the PaC and the PAA in the
   previous access network, which does not provide perfect cryptographic
   separation between the PAAs.

   To address the issues on the CTP-based method, this

   This document defines an extension to the PANA protocol
   [I-D.ietf-pana-pana] used for proactively executing EAP
   authentication and establishing a PANA SA (Security Association)
   between a PaC in an access network and a PAA in another access
   network to which the PaC may move.  The proposed method operates
   across multiple administrative AAA domains.

   Although the proposed method covers the case that is also covered by
   the CTP-based method (i.e., homogeneous authorization characteristics
   in a single administrative domain), the purpose of this document is
   not  The extension to replace the CTP-based method.  Instead, the purpose of this
   document PANA protocol is
   designed to provide a way to cover the cases that are not covered
   by the other method.  For the case covered by the CTP-based method,
   the CTP-based method may be used. realize direct pre-authentication defined in
   [I-D.ietf-hokey-preauth-ps].

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.  Terminogy

   The following terms are used in this document in addition to the
   terms defined in [I-D.ietf-pana-pana].

   Access Network:

   Serving PAA (SPAA):  A PAA that resides in the serving network and
      provides network through which a PaC can access authentication for a particular PaC.  For
      simplicity, this document assumes that there is only one SPAA in
      the serving network while the pre-authentication mechanism
      described in this document is generally applicable to the Internet via one
      or more EPs controlled by one case
      where there are two or more PAAs.  An access network may
      consist of multiple IP links.

   Local PAA: SPAAs in the serving network.

   Candidate PAA (CPAA):  A PAA that resides in the access a candidate network where the PaC is
      connected.  The term "local" is relative to
      which the location of PaC may move.  A CPAA for a particular PaC.

   Remote PAA:

      A PAA that is not a local PAA for the PaC.  The term "remote" is
      relative to the location of a particular PaC.  A PAA that is a
      remote PAA for one PaC may be a local PAA SPAA
      for another PaC.

   Local PaC:

      A PaC that resides in the same access network as a particular PAA.
      The term "local" is relative

   Pre-authentication:  Pre-authentication refers to EAP pre-
      authentication and defined as the location utilization of a specific PaC.

   Remote PaC:

      A PaC that is not a local PaC for a particular PAA.  The term
      "remote" is relative EAP to the location pre-
      establish EAP keying material on an authenticator prior to arrival
      of a particular PAA.  A PaC the peer at the access network served by that authenticator
      [I-D.ietf-hokey-preauth-ps].  In this draft, EAP pre-
      authentication is performed between a remote PaC for one PAA may be and a local PaC CPAA.

   Pre-authorization:  An authorization for another
      PAA.

   Active PAA:

      A local PAA a PaC, made by a CPAA for which
      the PaC has a PANA session.

   Preparing PAA:

      A remote PAA which performs pre-authentication with at the PaC.  A
      PAA that is serving as time of pre-authentication.

   Post-authorization:  An authorization for a preparing PAA PaC, made by a CPAA for one
      the PaC may be serving
      as an active PAA when the CPAA becomes the SPAA for another PaC.

   Pre-authentication:

      Authentication performed between the PaC and a preparing PAA.

   Pre-authentication PaC.

   Pre-authorization SA:  A PANA SA that is established between the a PaC and a preparing PAA
      as a result of successful pre-authentication.

   Active its
      CPAA.

   Post-authorization SA:  A PANA SA that is established between the PaC and an active PAA.

   Pre-authorization:

      An authorization that is made for the PaC by a preparing PAA as a
      result of successful pre-authentication.

   Post-authorization:

      An authorization that was made for the PaC by a PAA that was
      acting as a preparing PAA and has become the active PAA. its
      SPAA.

3.  Pre-authentication Procedure

   A PaC that supports pre-authentication may have one or more PANA
   sessions for preparing PAAs in addition to the establish a PANA session
   for one
   of local PAAs. each CPAA.

   There may be several mechanisms for a number of ways PaC and a CPAA to discover a remote PAA, however,
   remote PAA discovery and remote PaC discovery is each
   other.  However, such mechanisms are out of the scope of this proposal.
   document.

   There may be a number of criteria as for CPAA selection, the timing to when and with which remote
   PAA
   start pre-authentication is performed.  Such criteria can be and the timing to make a pre-authorization
   SA a post-authorization SA (and hence the CPAA becomes the SPAA).
   Such criteria can be implementation specific and thus are outside the
   scope of this document.

   Pre-authentication may be initiated by both a PaC and a preparing
   PAA. CPAA.  A new flag P-flag
   'E' (prE-authentication) bit is defined in the PANA header.  When pre-
   authentication
   pre-authentication is performed, the P-flag 'E' (prE-authentication) bit of
   PANA messages are set in order to indicate whether this PANA run is
   for establishing a pre-
   authentication SA.  Pre-authentication pre-authentication.  Use of pre-authentication is negotiated in the PANA
   discovery and handshake phase as
   follows.

   o  When a PaC initiates pre-authentication, it sends a PANA-PAA-
      Discover PANA-Client-
      Initiation (PCI) message with the P-flag 'E' (prE-authentication) bit
      set.  The PANA-PAA-Discover PCI message MUST be unicast.  The PAA CPAA responds with a PANA-Start-
      Request
      PANA-Start-Request (PSR) message with the P-flag 'S' (Start) and 'E'
      (prE-authentication) bits set only when if it supports pre-
      authentication.  Otherwise, it MUST silently discard the message.

   o  When a preparing PAA CPAA initiates pre-authentication, it sends a
      PANA-Start-Request PSR message
      with the P-flag 'S' (Start) and 'E' (prE-authentication) bits set.  The
      PaC responds with a PANA-Start-Answer (PSA) message with the P-flag 'S'
      (Start) and 'E' (prE-authentication) bits set only when if it supports
      pre-authentication.  Otherwise, it MUST silently discard the
      message.

   o  Once the PaC and preparing PAA CPAA have agreed on performing pre-
      authentication during pre-authentication
      using the discovery 'S' (Start) and handshake phase, 'E' (prE-authentication) bits, the
      subsequent PANA messages exchanged between them MUST have the
      P-flag 'E'
      (prE-authentication) bit set.

   When a CPAA with which the preparing PAA PaC has a pre-authorization SA becomes an active PAA the
   SPAA due to to, e.g., movement of the PaC, the PaC performs an IP
   address update procedure using PANA-
   Update exchange defined in Section 5.6 of
   [I-D.ietf-pana-pana] in order to update the PAA SPAA with the PaC's new
   address obtained from the remote network where the PAA resides. new serving network.  PANA-Notification-
   Request (PNR) and PANA-Notification-Answer (PNA) messages with 'P'
   (Ping) bit set are used for this purpose.  The completion of the PANA-Update IP
   address update procedure will change the pre-
   authentication pre-authorization SA to the active a
   post-authorization SA.  The P-flag is not  In this case, the 'E' MUST NOT be set in the
   PANA-Update
   PNR and PNA messages and subsequent PANA messages.

   When

   If there is another CPAA with which the PaC having an active SA with an active PAA as well as has a pre-
   authentication pre-authorization
   SA with a preparing PAA changes its active PAA but
   without changing and the PaC wants to keep the preparing PAA, pre-authorization SA after the
   change of SPAA, the PaC also performs an IP address update procedure using PANA-Update exchange
   defined in Section 5.6 of [I-D.ietf-pana-pana] in order to update the
   PAA of
   CPAA with the PaC's new address obtained from the remote network where
   the new active PAA resides.  The completion of the PANA-Update
   procedure will not change the pre-authentication SA to the active SA.
   The P-flag is set in the PANA-Update messages and subsequent PANA
   messages.

   The pre-authentication SA and corresponding PANA session between the
   PaC address.  PNR and the pre-authenticated PAA can be deleted by entering the
   termination phase of the PANA protocol and performing the required
   procedure for that phase.

   An example call flow for PaC-initiated pre-authentication is shown in
   Figure 1.

   A PaC in an access network establishes a PANA session with a local
   PAA (l-PAA).  At some point, it receives a trigger for pre-
   authenticating to a remote PAA (r-PAA) in another access network.
   The PaC then initiates a pre-authentication procedure by sending a
   PANA-PAA-Discover message with the P-bit set.  PANA PNA messages are
   exchanged between the PaC and r-PAA, with the P-bit 'P'
   (Ping) bit set is used for all
   messages.  On successful completion of this purpose.  In this case, the PANA exchanges for pre-
   authentication and pre-authorization, a pre-authentication SA will 'E' (prE-
   authentication) bit MUST be
   established between set in the PaC PNR and l-PAA.  On the other hand, the active
   SA established between the PaC PNA messages and l-PAA stays active.

   At some point after establishing the pre-authentication SA, the PaC
   moves to the access network of the r-PAA.
   subsequent PANA messages.  The r-PAA may be found by
   running PAA discovery over a newly created session or immediately
   when the PaC attaches a link-layer device that is acting as an EP
   whose device identifier was contained in the list of EP device
   identifiers advertised by the r-PAA in the pre-authentication
   procedure.  If the r-PAA is found, the PaC initiates a PANA-Update
   exchange over the session in which the pre-authentication SA has been
   maintained to inform the PAA of the IP address change.  In this PANA-
   Update exchange, the P-bit is unset.  On successful completion of the
   PANA-Update exchange and post-authorization procedure, the pre-
   authentication SA becomes the active SA.  The active SA between the
   PaC and l-PAA may stay active for a while to deal with the case in
   which the PaC immediately switches back to the previous access
   network.

   If no such an r-PAA is found but other PAA(s) in address update procedure with the new access
   network,
   CPAA will not change the pre-authorization SA to a full PANA authentication or post-authorization
   SA.

   The pre-authorization SA and the corresponding PANA mobility optimization may
   be performed session between
   the PaC and one a CPAA is deleted by entering the termination phase of those PAA(s) based on
   the
   procedures described PANA protocol.

   Example call flows for PaC-initiated pre-authentication and PAA-
   initiated pre-authentication are shown in [I-D.ietf-pana-pana] Figure 1 and [I-D.ietf-pana-
   cxtp]. Figure 1,
   respectively.

        PaC                      l-PAA                    r-PAA
         |                        |                        |
         |  PANA w/o P-bit set    |                        |
         |<---------------------->|                                               CPAA
         |                                                 |                        |                        |
         .                        .                        .
         .                        .                        .
   +------------------+                                    |                        |
   |Pre-authentication|                                    |                        |
   |trigger           |                                    |                        |
   +------------------+                                    |
         |
         |                  PDI w/P-bit                  PCI w/'E' bit set              |
         |------------------------------------------------>|
         |                  PSR w/P-bit            PAR w/'S' and 'E' bits set           |
         |<------------------------------------------------|
         |                  PSA w/P-bit            PAN w/'S' and 'E' bits set           |
         |------------------------------------------------>|
         |           PAR-PAN exchange w/P-bit w/'E' bit set        |
         |<----------------------------------------------->|
         |                        |                                        +------------------+
         |                        |                                        |pre-authorization |
         |                        |                                        +------------------+
         |           PBR-PBA exchange w/P-bit            PAR w/'C' and 'E' bits set           |
         |<----------------------------------------------->|
         |<------------------------------------------------|
         |            PAN w/'C' and 'E' bits set           |
         |------------------------------------------------>|
         .                        .                        .
         .                        .                        .
   +----------+                                            |
   |
   | Movement |                                            |                        |
   +----------+                                            |
         |
         |                 PUR        PNR w/ 'P' bit set and w/o P-bit 'E' bit set   |
         |------------------------------------------------>|
         |                                        +-------------------+
         |               +------------------+
         |                                        |post-authorization |               |post-authorization|
         |                                        |(CPAA becomes SPAA)|
         |               +------------------+                                        +-------------------+
         |                 PUA        PNA w/ 'P' bit set and w/o P-bit 'E' bit set   |
         |<------------------------------------------------|
         |                                                 |                        |

           Figure 1: PaC-initiated Pre-authentication Call Flow

   An example call flow for PAA-initiated pre-authentication is shown in
   Figure 2.
        PaC                      l-PAA                    r-PAA
         |                        |                        |
         |  PANA w/o P-bit set    |                        |
         |<---------------------->|                                               CPAA
         |                                                 |
         |                        |
         .                        .                        .
         .                        .                        .
         |                        |                                        +------------------+
         |                        |                                        |Pre-authentication|
         |                        |                                        |trigger           |
         |                        |                                        +------------------+
         |                  PSR w/P-bit            PAR w/'S' and 'E' bits set           |
         |<------------------------------------------------|
         |                  PSA w/P-bit            PAN w/'S' and 'E' bits set           |
         |------------------------------------------------>|
         |           PAR-PAN exchange w/P-bit w/'E' bit set        |
         |<----------------------------------------------->|
         |                        |                                        +------------------+
         |                        |                                        |pre-authorization |
         |                        |                                        +------------------+
         |           PBR-PBA exchange w/P-bit            PAR w/'C' and 'E' bits set           |
         |<----------------------------------------------->|
         |<------------------------------------------------|
         |            PAN w/'C' and 'E' bits set           |
         |------------------------------------------------>|
         .                        .                        .
         .                        .                        .
   +----------+                                            |
   |
   | Movement |                                            |                        |
   +----------+                                            |
         |
         |                 PUR        PNR w/ 'P' bit set and w/o P-bit 'E' bit set   |
         |------------------------------------------------>|
         |                                        +-------------------+
         |               +------------------+
         |                                        |post-authorization |               |post-authorization|
         |                                        |(CPAA becomes SPAA)|
         |               +------------------+                                        +-------------------+
         |                 PUA        PNA w/ 'P' bit set and w/o P-bit 'E' bit set   |
         |<------------------------------------------------|
         |                                                 |                        |

           Figure 2: PAA-initiated Pre-authentication Call Flow

4.  PANA Extensions

   A new P-flag 'E' (prE-authentication) bit is defined in Flags field of PANA
   header as follows.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R S N C A P r r r I E r r r r r r r r r|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   P(re-authentication)
   E(PrE-authentication)  When pre-authentication is performed, the P-flag 'E'
      (prE-authentication) bit of PANA messages are set in order to
      indicate whether this PANA run is for establishing a pre-authentication pre-
      authorization SA.  The exact usage of this
      flag bit is described in
      Section 3.  This flag bit is to be assigned by IANA.

5.  Authorization and Accounting Considerations

   A pre-authorization and a post-authorization for the PaC may have
   different authorization policies.  For example, the pre-authorization
   policy may not allow the PaC to sent or receive packets through the
   EP(s) an
   (Enforcement Point) that is under control of the preparing PAA, CPAA, while both the pre-
   authorization
   pre-authorization and post-authorization policies may allow
   installing credentials to the EP(s), EP, where the credentials are used for
   establishing a security association for per-packet cryptographic
   filtering.

   In an access network where accounting is performed, accounting starts
   when the pre-authentication pre-authorization SA becomes the active post-authorization SA by
   default.  Depending on the pre-authorization policy, accounting may
   start immediately after the pre-authentication pre-authorization SA is established.

6.  Security Considerations

   Since the mechanism described in this document is designed to work
   across multiple access networks, each EP (Enforcement Point) in the serving network
   SHOULD be configured to allow PANA messages to be forwarded between a
   PaC and a preparing PAA in a different access network CPAA only if the PaC has
   an active a post-authorization SA with a local PAA the
   SPAA in order to avoid an unauthorized PaC to initiate pre-authentication. pre-
   authentication.  Also, each access network that supports pre-authentication pre-
   authentication SHOULD block pre-authentication attempts from networks
   from which a handover is not likely to occur.

   When pre-authentication is initiated by a remote PAA, CPAA, it is possible that
   the PaC simultaneously communicates with multiple remote PAAs CPAAs initiating
   pre-authentication.  In order to avoid possible resource consumption
   attacks on the PaC caused by a blind attacker initiating
   pre-authentication pre-
   authentication for the PaC by changing source addresses, the PaC
   SHOULD limit the maximum number of PAAs CPAAs allowed to communicate.

   The pre-authentication mechanism defined in this document does not
   have an issue on context binding in which link-layer independent
   context carried over pre-authentication signaling is bound to the
   link-layer specific context [I-D.ietf-hokey-preauth-ps], because the
   same EAP transport protocol (i.e., PANA) is used for normal
   authentication and pre-authentication in the candidate network.

7.  IANA Considerations

   As described in Section 4, a new flag in bit 6 of the Flags field of PANA Header
   needs to be assigned by IANA.  The new flag is bit 3 ('P're-
   authentication). IANA for the 'E' (prE-authentication) bit.

8.  Acknowledgments

   The author would like to thank Alper Yegin, Ashutosh Dutta, Julien
   Bournelle and Sasikanth Bharadwaj for their valuable comments.

9.  References

9.1.  Normative References

   [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-10 draft-ietf-pana-pana-18 (work in
              progress), September 2007.

   [I-D.ietf-hokey-preauth-ps]
              Ohba, Y., "EAP Pre-authentication Problem Statement",
              draft-ietf-hokey-preauth-ps-01 (work in progress), July 2005.
              October 2007.

9.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4067]  Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
              "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.

   [I-D.ietf-pana-mobopts]
              Forsberg, D., "PANA Mobility Optimizations",
              draft-ietf-pana-mobopts-01 (work in progress),
              October 2005.

   [I-D.ietf-pana-cxtp]
              Bournelle, J., "Use of Context Transfer Protocol (CXTP)
              for PANA", draft-ietf-pana-cxtp-00 (work in progress),
              October 2005.

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

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 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 (2006).  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. IETF
   Administrative Support Activity (IASA).