added eap authentication draft for ikev2
authorMartin Willi <martin@strongswan.org>
Wed, 18 Oct 2006 11:49:37 +0000 (11:49 -0000)
committerMartin Willi <martin@strongswan.org>
Wed, 18 Oct 2006 11:49:37 +0000 (11:49 -0000)
src/charon/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt [new file with mode: 0644]

diff --git a/src/charon/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt b/src/charon/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt
new file mode 100644 (file)
index 0000000..f5fd3cc
--- /dev/null
@@ -0,0 +1,729 @@
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+