include RFC 5998

1 files changed, 0 insertions, 729 deletions

diff --git a/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt b/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt
deleted file mode 100644
index f5fd3cc0c..000000000
--- a/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt
+++ /dev/null
@@ -1,729 +0,0 @@
-
-
-
-Network Working Group                                          P. Eronen
-Internet-Draft                                                     Nokia
-Expires: December 28, 2006                                 H. Tschofenig
-                                                                 Siemens
-                                                           June 26, 2006
-
-
-               Extension for EAP Authentication in IKEv2
-                draft-eronen-ipsec-ikev2-eap-auth-05.txt
-
-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 December 28, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   IKEv2 specifies that EAP authentication must be used together with
-   public key signature based responder authentication.  This is
-   necessary with old EAP methods that provide only unilateral
-   authentication using, e.g., one-time passwords or token cards.
-
-   This document specifies how EAP methods that provide mutual
-   authentication and key agreement can be used to provide extensible
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 1]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-   responder authentication for IKEv2 based on other methods than public
-   key signatures.
-
-
-1.  Introduction
-
-   The Extensible Authentication Protocol (EAP), defined in [4], is an
-   authentication framework which supports multiple authentication
-   mechanisms.  Today, EAP has been implemented at end hosts and routers
-   that connect via switched circuits or dial-up lines using PPP [13],
-   IEEE 802 wired switches [9], and IEEE 802.11 wireless access points
-   [11].
-
-   One of the advantages of the EAP architecture is its flexibility.
-   EAP is used to select a specific authentication mechanism, typically
-   after the authenticator requests more information in order to
-   determine the specific authentication method to be used.  Rather than
-   requiring the authenticator (e.g., wireless LAN access point) to be
-   updated to support each new authentication method, EAP permits the
-   use of a backend authentication server which may implement some or
-   all authentication methods.
-
-   IKEv2 [3] is a component of IPsec used for performing mutual
-   authentication and establishing and maintaining security associations
-   for IPsec ESP and AH.  In addition to supporting authentication using
-   public key signatures and shared secrets, IKEv2 also supports EAP
-   authentication.
-
-   IKEv2 provides EAP authentication since it was recognized that public
-   key signatures and shared secrets are not flexible enough to meet the
-   requirements of many deployment scenarios.  By using EAP, IKEv2 can
-   leverage existing authentication infrastructure and credential
-   databases, since EAP allows users to choose a method suitable for
-   existing credentials, and also makes separation of the IKEv2
-   responder (VPN gateway) from the EAP authentication endpoint (backend
-   AAA server) easier.
-
-   Some older EAP methods are designed for unilateral authentication
-   only (that is, EAP peer to EAP server).  These methods are used in
-   conjunction with IKEv2 public key based authentication of the
-   responder to the initiator.  It is expected that this approach is
-   especially useful for "road warrior" VPN gateways that use, for
-   instance, one-time passwords or token cards to authenticate the
-   clients.
-
-   However, most newer EAP methods, such as those typically used with
-   IEEE 802.11i wireless LANs, provide mutual authentication and key
-   agreement.  Currently, IKEv2 specifies that also these EAP methods
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 2]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-   must be used together with public key signature based responder
-   authentication.
-
-   In some environments, requiring the deployment of PKI for just this
-   purpose can be counterproductive.  Deploying new infrastructure can
-   be expensive, and it may weaken security by creating new
-   vulnerabilities.  Mutually authenticating EAP methods alone can
-   provide a sufficient level of security in many circumstances, and
-   indeed, IEEE 802.11i uses EAP without any PKI for authenticating the
-   WLAN access points.
-
-   This document specifies how EAP methods that offer mutual
-   authentication and key agreement can be used to provide responder
-   authentication in IKEv2 completely based on EAP.
-
-1.1.  Terminology
-
-   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 [2].
-
-
-2.  Scenarios
-
-   In this section we describe two scenarios for extensible
-   authentication within IKEv2.  These scenarios are intended to be
-   illustrative examples rather than specifying how things should be
-   done.
-
-   Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
-   are co-located.  Authenticating the IKEv2 responder using both EAP
-   and public key signatures is redundant.  Offering EAP based
-   authentication has the advantage that multiple different
-   authentication and key exchange protocols are available with EAP with
-   different security properties (such as strong password based
-   protocols, protocols offering user identity confidentiality and many
-   more).  As an example it is possible to use GSS-API support within
-   EAP [6] to support Kerberos based authentication which effectively
-   replaces the need for KINK [14].
-
-          +------+-----+                            +------------+
-     O    |   IKEv2    |                            |   IKEv2    |
-    /|\   | Initiator  |<---////////////////////--->| Responder  |
-    / \   +------------+          IKEv2             +------------+
-    User  |  EAP Peer  |          Exchange          | EAP Server |
-          +------------+                            +------------+
-
-   Figure 1: EAP and IKEv2 endpoints are co-located
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 3]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-   Figure 2 shows a typical corporate network access scenario.  The
-   initiator (client) interacts with the responder (VPN gateway) in the
-   corporate network.  The EAP exchange within IKE runs between the
-   client and the home AAA server.  As a result of a successful EAP
-   authentication protocol run, session keys are established and sent
-   from the AAA server to the VPN gateway, and then used to authenticate
-   the IKEv2 SA with AUTH payloads.
-
-   The protocol used between the VPN gateway and AAA server could be,
-   for instance, Diameter [4] or RADIUS [5].  See Section 5 for related
-   security considerations.
-
-                                +-------------------------------+
-                                |       Corporate network       |
-                                |                               |
-                           +-----------+            +--------+  |
-                           |   IKEv2   |     AAA    |  Home  |  |
-     IKEv2      +////----->+ Responder +<---------->+  AAA   |  |
-     Exchange   /          | (VPN GW)  |  (RADIUS/  | Server |  |
-                /          +-----------+  Diameter) +--------+  |
-                /               |        carrying EAP           |
-                |               |                               |
-                |               +-------------------------------+
-                v
-         +------+-----+
-     o   |   IKEv2    |
-    /|\  | Initiator  |
-    / \  | VPN client |
-   User  +------------+
-
-   Figure 2: Corporate Network Access
-
-
-3.  Solution
-
-   IKEv2 specifies that when the EAP method establishes a shared secret
-   key, that key is used by both the initiator and responder to generate
-   an AUTH payload (thus authenticating the IKEv2 SA set up by messages
-   1 and 2).
-
-   When used together with public key responder authentication, the
-   responder is in effect authenticated using two different methods: the
-   public key signature AUTH payload in message 4, and the EAP-based
-   AUTH payload later.
-
-   If the initiator does not wish to use public key based responder
-   authentication, it includes an EAP_ONLY_AUTHENTICATION notification
-   payload (type TBD-BY-IANA) in message 3.  The SPI size field is set
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 4]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-   to zero, and there is no additional data associated with this
-   notification.
-
-   If the responder supports this notification, it omits the public key
-   based AUTH payload and CERT payloads from message 4.
-
-   If the responder does not support the EAP_ONLY_AUTHENTICATION
-   notification, it ignores the notification payload, and includes the
-   AUTH payload in message 4.  In this case the initiator can, based on
-   its local policy, choose to either ignore the AUTH payload, or verify
-   it and any associated certificates as usual.
-
-   Both the initiator and responder MUST verify that the EAP method
-   actually used provided mutual authentication and established a shared
-   secret key.  The AUTH payloads sent after EAP Success MUST use the
-   EAP-generated key, and MUST NOT use SK_pi or SK_pr.
-
-   An IKEv2 message exchange with this modification is shown below:
-
-
-      Initiator                   Responder
-     -----------                 -----------
-      HDR, SAi1, KEi, Ni,
-           [N(NAT_DETECTION_SOURCE_IP),
-            N(NAT_DETECTION_DESTINATION_IP)]  -->
-
-                            <--   HDR, SAr1, KEr, Nr, [CERTREQ],
-                                       [N(NAT_DETECTION_SOURCE_IP),
-                                        N(NAT_DETECTION_DESTINATION_IP)]
-
-      HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
-                N(EAP_ONLY_AUTHENTICATION),
-                [CP(CFG_REQUEST)] }  -->
-
-                            <--   HDR, SK { IDr, EAP(Request) }
-
-      HDR, SK { EAP(Response) }  -->
-
-                            <--   HDR, SK { EAP(Request) }
-
-      HDR, SK { EAP(Response) }  -->
-
-                            <--   HDR, SK { EAP(Success) }
-
-      HDR, SK { AUTH }  -->
-
-                            <--   HDR, SK { AUTH, SAr2, TSi, TSr,
-                                            [CP(CFG_REPLY] }
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 5]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-   The NAT detection and Configuration payloads are shown for
-   informative purposes only; they do not change how EAP authentication
-   works.
-
-
-4.  IANA considerations
-
-   This document defines a new IKEv2 Notification Payload type,
-   EAP_ONLY_AUTHENTICATION, described in Section 3.  This payload must
-   be assigned a new type number from the "status types" range.
-
-   This document does not define any new namespaces to be managed by
-   IANA.
-
-
-5.  Security Considerations
-
-   Security considerations applicable to all EAP methods are discussed
-   in [1].  The EAP Key Management Framework [7] deals with issues that
-   arise when EAP is used as a part of a larger system.
-
-5.1.  Authentication of IKEv2 SA
-
-   It is important to note that the IKEv2 SA is not authenticated by
-   just running an EAP conversation: the crucial step is the AUTH
-   payload based on the EAP-generated key.  Thus, EAP methods that do
-   not provide mutual authentication or establish a shared secret key
-   MUST NOT be used with the modifications presented in this document.
-
-5.2.  Authentication with separated IKEv2 responder/EAP server
-
-   As described in Section 2, the EAP conversation can terminate either
-   at the IKEv2 responder or at a backend AAA server.
-
-   If the EAP method terminates at the IKEv2 responder then no key
-   transport via the AAA infrastructure is required.  Pre-shared secret
-   and public key based authentication offered by IKEv2 is then replaced
-   by a wider range of authentication and key exchange methods.
-
-   However, typically EAP will be used with a backend AAA server.  See
-   [7] for a more complete discussion of the related security issues;
-   here we provide only a short summary.
-
-   When a backend server is used, there are actually two authentication
-   exchanges: the EAP method between the client and the AAA server, and
-   another authentication between the AAA server and IKEv2 gateway.  The
-   AAA server authenticates the client using the selected EAP method,
-   and they establish a session key.  The AAA server then sends this key
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 6]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-   to the IKEv2 gateway over a connection authenticated using, e.g.,
-   IPsec or TLS.
-
-   Some EAP methods do not have any concept of pass-through
-   authenticator (e.g., NAS or IKEv2 gateway) identity, and these two
-   authentications remain quite independent of each other.  That is,
-   after the client has verified the AUTH payload sent by the IKEv2
-   gateway, it knows that it is talking to SOME gateway trusted by the
-   home AAA server, but not which one.  The situation is somewhat
-   similar if a single cryptographic hardware accelerator, containing a
-   single private key, would be shared between multiple IKEv2 gateways
-   (perhaps in some kind of cluster configuration).  In particular, if
-   one of the gateways is compromised, it can impersonate any of the
-   other gateways towards the user (until the compromise is discovered
-   and access rights revoked).
-
-   In some environments it is not desirable to trust the IKEv2 gateways
-   this much (also known as the "Lying NAS Problem").  EAP methods that
-   provide what is called "connection binding" or "channel binding"
-   transport some identity or identities of the gateway (or WLAN access
-   point/NAS) inside the EAP method.  Then the AAA server can check that
-   it is indeed sending the key to the gateway expected by the client.
-   A potential solution is described in [16].
-
-   In some deployment configurations, AAA proxies may be present between
-   the IKEv2 gateway and the backend AAA server.  These AAA proxies MUST
-   be trusted for secure operation, and therefore SHOULD be avoided when
-   possible; see [4] and [7] for more discussion.
-
-5.3.  Protection of EAP payloads
-
-   Although the EAP payloads are encrypted and integrity protected with
-   SK_e/SK_a, this does not provide any protection against active
-   attackers.  Until the AUTH payload has been received and verified, a
-   man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
-   modify the EAP payloads.
-
-   In IEEE 802.11i WLANs, the EAP payloads are neither encrypted nor
-   integrity protected (by the link layer), so EAP methods are typically
-   designed to take that into account.
-
-   In particular, EAP methods that are vulnerable to dictionary attacks
-   when used in WLANs are still vulnerable (to active attackers) when
-   run inside IKEv2.
-
-5.4.  User identity confidentiality
-
-   IKEv2 provides confidentiality for the initiator identity against
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 7]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-   passive eavesdroppers, but not against active attackers.  The
-   initiator announces its identity first (in message #3), before the
-   responder has been authenticated.  The usage of EAP in IKEv2 does not
-   change this situation, since the ID payload in message #3 is used
-   instead of the EAP Identity Request/Response exchange.  This is
-   somewhat unfortunate since when EAP is used with public key
-   authentication of the responder, it would be possible to provide
-   active user identity confidentiality for the initiator.
-
-   IKEv2 protects the responder identity even against active attacks.
-   This property cannot be provided when using EAP.  If public key
-   responder authentication is used in addition to EAP, the responder
-   reveals its identity before authenticating the initiator.  If only
-   EAP is used (as proposed in this document), the situation depends on
-   the EAP method used (in some EAP methods, the server reveals its
-   identity first).
-
-   Hence, if active user identity confidentiality for the initiator is
-   required then EAP methods that offer this functionality have to be
-   used (see [1], Section 7.3).
-
-
-6.  Acknowledgments
-
-   This document borrows some text from [1], [3], and [4].  We would
-   also like to thank Hugo Krawczyk for interesting discussions about
-   this topic.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [1]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
-        Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
-        June 2004.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", RFC 2119, March 1997.
-
-   [3]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
-        December 2005.
-
-   [4]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
-        Authentication Protocol (EAP) Application", RFC 4072,
-        August 2005.
-
-
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 8]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-7.2.  Informative References
-
-   [5]   Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
-         In User Service) Support For Extensible Authentication Protocol
-         (EAP)", RFC 3579, September 2003.
-
-   [6]   Aboba, B. and D. Simon, "EAP GSS Authentication Protocol",
-         draft-aboba-pppext-eapgss-12 (work in progress), April 2002.
-
-   [7]   Aboba, B., "Extensible Authentication Protocol (EAP) Key
-         Management Framework", draft-ietf-eap-keying-13 (work in
-         progress), May 2006.
-
-   [8]   Forsberg, D., "Protocol for Carrying Authentication for Network
-         Access (PANA)", draft-ietf-pana-pana-11 (work in progress),
-         March 2006.
-
-   [9]   Institute of Electrical and Electronics Engineers, "Local and
-         Metropolitan Area Networks: Port-Based Network Access Control",
-         IEEE Standard 802.1X-2001, 2001.
-
-   [10]  Institute of Electrical and Electronics Engineers, "Information
-         technology - Telecommunications and information exchange
-         between systems - Local and metropolitan area networks -
-         Specific Requirements Part 11: Wireless LAN Medium Access
-         Control (MAC) and Physical Layer (PHY) Specifications", IEEE
-         Standard 802.11-1999, 1999.
-
-   [11]  Institute of Electrical and Electronics Engineers, "IEEE
-         Standard for Information technology - Telecommunications and
-         information exchange between systems - Local and metropolitan
-         area networks - Specific requirements - Part 11: Wireless
-         Medium Access Control (MAC) and Physical Layer (PHY)
-         specifications: Amendment 6: Medium Access Control (MAC)
-         Security Enhancements", IEEE Standard 802.11i-2004, July 2004.
-
-   [12]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
-         Authentication Dial In User Service (RADIUS)", RFC 2865,
-         June 2000.
-
-   [13]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
-         RFC 1661, July 1994.
-
-   [14]  Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
-         "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430,
-         March 2006.
-
-   [15]  Tschofenig, H., "EAP IKEv2 Method",
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006               [Page 9]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-         draft-tschofenig-eap-ikev2-11 (work in progress), June 2006.
-
-   [16]  Arkko, J. and P. Eronen, "Authenticated Service Information for
-         the Extensible Authentication Protocol  (EAP)",
-         draft-arkko-eap-service-identity-auth-04 (work in progress),
-         October 2005.
-
-
-Appendix A.  Alternative Approaches
-
-   In this section we list alternatives which have been considered
-   during the work on this document.  Finally, the solution presented in
-   Section 3 seems to fit better into IKEv2.
-
-A.1.  Ignore AUTH payload at the initiator
-
-   With this approach, the initiator simply ignores the AUTH payload in
-   message #4 (but obviously must check the second AUTH payload later!).
-   The main advantage of this approach is that no protocol modifications
-   are required and no signature verification is required.
-
-   The initiator could signal the responder (using a NOTIFY payload)
-   that it did not verify the first AUTH payload.
-
-A.2.  Unauthenticated PKs in AUTH payload (message 4)
-
-   The first solution approach suggests the use of unauthenticated
-   public keys in the public key signature AUTH payload (for message 4).
-
-   That is, the initiator verifies the signature in the AUTH payload,
-   but does not verify that the public key indeed belongs to the
-   intended party (using certificates)--since it doesn't have a PKI that
-   would allow this.  This could be used with X.509 certificates (the
-   initiator ignores all other fields of the certificate except the
-   public key), or "Raw RSA Key" CERT payloads.
-
-   This approach has the advantage that initiators that wish to perform
-   certificate-based responder authentication (in addition to EAP) may
-   do so, without requiring the responder to handle these cases
-   separately.
-
-   If using RSA, the overhead of signature verification is quite small
-   (compared to g^xy calculation).
-
-A.3.  Use EAP derived session keys for IKEv2
-
-   It has been proposed that when using an EAP methods that provides
-   mutual authentication and key agreement, the IKEv2 Diffie-Hellman
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006              [Page 10]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-   exchange could also be omitted.  This would mean that the sessions
-   keys for IPsec SAs established later would rely only on EAP-provided
-   keys.
-
-   It seems the only benefit of this approach is saving some computation
-   time (g^xy calculation).  This approach requires designing a
-   completely new protocol (which would not resemble IKEv2 anymore) we
-   do not believe that it should be considered.  Nevertheless, we
-   include it for completeness.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006              [Page 11]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-Authors' Addresses
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006              [Page 12]
-
-Internet-Draft         Extension for EAP in IKEv2              June 2006
-
-
-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.
-
-
-
-
-Eronen & Tschofenig     Expires December 28, 2006              [Page 13]
-
-