Add.

1 files changed, 728 insertions, 0 deletions

diff --git a/doc/protocol/draft-salowey-tls-ticket-05.txt b/doc/protocol/draft-salowey-tls-ticket-05.txt
new file mode 100644
index 0000000000..8e1c2d9d4d
--- /dev/null
+++ b/doc/protocol/draft-salowey-tls-ticket-05.txt
@@ -0,0 +1,728 @@
+
+
+
+Network Working Group                                         J. Salowey
+Internet-Draft                                                   H. Zhou
+Expires: April 21, 2006                                    Cisco Systems
+                                                               P. Eronen
+                                                                   Nokia
+                                                           H. Tschofenig
+                                                                 Siemens
+                                                        October 18, 2005
+
+
+ Transport Layer Security Session Resumption without Server-Side State
+                    draft-salowey-tls-ticket-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 April 21, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes a mechanism which enables the Transport Layer
+   Security (TLS) server to resume sessions and avoid keeping per-client
+   session state.  The TLS server encapsulates the session state into a
+   ticket and forwards it to the client.  The client can subsequently
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 1]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+   resume a session using the obtained ticket.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.2   SessionTicket TLS extension  . . . . . . . . . . . . . . .  5
+     3.3   SessionTicket handshake message  . . . . . . . . . . . . .  5
+     3.4   Interaction with TLS session ID  . . . . . . . . . . . . .  6
+   4.  Recommended Ticket Construction  . . . . . . . . . . . . . . .  7
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . .  9
+     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . .  9
+     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . .  9
+     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . .  9
+     5.5   Ticket Protection Key Lifetime . . . . . . . . . . . . . .  9
+     5.6   Alternate Ticket Formats and Distribution Schemes  . . . . 10
+   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
+   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     8.1   Normative References . . . . . . . . . . . . . . . . . . . 10
+     8.2   Informative References . . . . . . . . . . . . . . . . . . 11
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
+       Intellectual Property and Copyright Statements . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 2]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+1.  Introduction
+
+   This document defines a way to resume a Transport Layer Security
+   (TLS) [RFC2246] session without requiring session-specific state at
+   the TLS server.  This mechanism may be used with any TLS ciphersuite.
+   The mechanism makes use of TLS extensions defined in [I-D.ietf-tls-
+   rfc3546bis] and defines a new TLS message type.
+
+   This mechanism is useful in the following types of situations
+      (1) servers that handle a large number of transactions from
+      different users
+      (2) servers that desire to cache sessions for a long time
+      (3) ability to load balance requests across servers
+      (4) embedded servers with little memory
+
+2.  Terminology
+
+   Within this document the term 'ticket' refers to a cryptographically
+   protected data structure which is created by the server and consumed
+   by the server to rebuild session specific state.
+
+   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].
+
+3.  Protocol
+
+   This specification describes a mechanism to distribute encrypted
+   session state information in a ticket from a TLS server to a TLS
+   client and for a TLS client to present a ticket to a TLS server to
+   resume a session.  Implementations of this specification are expected
+   to support both mechanism.  Other specifications can take advantage
+   of the session tickets, perhaps specifying alternative means for
+   distribution or selection.  For example a separate specification may
+   describe an alternate way to distribute a ticket and use the TLS
+   extension in this document to resume the session.  This behavior is
+   beyond the scope of the document and would need to be described in a
+   separate specification.
+
+3.1  Overview
+
+   The client indicates that it supports this mechanism by including a
+   SessionTicket TLS extension in the ClientHello message.  The
+   extension will be empty if the client does not already possess a
+   ticket for the server.  The extension is described in Section 3.2
+
+   If the server wants to use this mechanism, it stores its session
+   state (such as ciphersuite and master secret) to a ticket that is
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 3]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+   encrypted and integrity-protected by a key known only to the server.
+   The ticket is distributed to the client using the SessionTicket TLS
+   handshake message described in Section 3.3.  This message is sent
+   during the TLS handshake before the ChangeCipherSpec message after
+   the server has successfully verified the client's Finished message.
+
+
+         Client                                               Server
+
+         ClientHello                   -------->
+        (empty SessionTicket extension)
+                                                         ServerHello
+                                                        Certificate*
+                                                  ServerKeyExchange*
+                                                 CertificateRequest*
+                                      <--------      ServerHelloDone
+         Certificate*
+         ClientKeyExchange
+         CertificateVerify*
+         [ChangeCipherSpec]
+         Finished                     -------->
+                                                       SessionTicket
+                                                  [ChangeCipherSpec]
+                                      <--------             Finished
+         Application Data             <------->     Application Data
+
+   The client caches this ticket along with the master secret and other
+   parameters associated with the current session.  When the client
+   wishes to resume the session, it includes the ticket in the
+   SessionTicket extension within ClientHello message.  The server then
+   verifies that the ticket has not been tampered with, decrypts the
+   contents, retrieves the session state from the contents of the ticket
+   and uses this state to resume the session.  The interaction with the
+   TLS Session ID is described in Section 3.4.  If the server
+   successfully verifies the client's ticket then it may renew the
+   ticket by including a SessionTicket handshake message after the
+   ServerHello.
+
+
+         ClientHello
+         (SessionTicket extension)      -------->
+                                                          ServerHello
+                                                        SessionTicket
+                                                   [ChangeCipherSpec]
+                                       <--------             Finished
+         [ChangeCipherSpec]
+         Finished                      -------->
+         Application Data              <------->     Application Data
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 4]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+   A recommended ticket format is given in Section 4.  If the server
+   cannot or does not want to honor the ticket then it can initiate a
+   full handshake with the client.
+
+3.2  SessionTicket TLS extension
+
+   The SessionTicket TLS extension is based on [I-D.ietf-tls-
+   rfc3546bis].  The format of the ticket is an opaque structure used to
+   carry session specific state information.  This extension is sent in
+   the ClientHello.  If the client posses a ticket that it wants to use
+   to resume a session then it includes it in the SessionTicket
+   extension in the ClientHello.  If the client does not have a ticket
+   and it is prepared to receive one in the SessionTicket handshake
+   message then it MUST include a zero length ticket in the
+   SessionTicket extension.  If the client is not prepared to receive a
+   ticket in the SessionTicket handshake message then it MUST NOT
+   include a zero length SessionTicket extension.
+
+   If the server fails to verify the ticket then it falls back to
+   performing a full handshake.  If the ticket is accepted by the server
+   but the handshake fails the client SHOULD delete the ticket.
+
+   The SessionTicket extension has been assigned the number TBD1.  The
+   format of the SessionTicket extension is given below.
+
+
+      struct {
+          opaque ticket<0..2^16-1>;
+      } SessionTicket;
+
+
+3.3  SessionTicket handshake message
+
+   This message is sent during the TLS handshake before the
+   ChangeCipherSpec message.  This message MUST only be sent if either
+   the client included a SessionTicket extension with a zero length
+   ticket in the ClientHello or if the client included a ticket that was
+   previously issued in a SessionTicket handshake message.  In the case
+   of a full handshake, the server MUST verify the client's Finished
+   message before sending the ticket.  The client MUST NOT treat the
+   ticket as valid until it has verified the server's Finished message.
+
+   If the server successfully verifies the client's ticket then it MAY
+   renew the ticket by including a SessionTicket handshake message after
+   the ServerHello in the abbreviated handshake.  The client should
+   start using the new ticket as soon as possible after it verifies the
+   Server's finished message for new connections.  Note that since the
+   updated ticket is issued before the handshake completes it is
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 5]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+   possible that the client may not put the new ticket into use before
+   it initiates new connections.  The server MUST NOT assume the client
+   actually received the updated ticket until it successfully verifies
+   the client's finished message.
+
+   The SessionTicket handshake message has been assigned the number
+   TBD2.  The definition of the SessionTicket handshake message is given
+   below.
+
+
+      struct {
+          HandshakeType msg_type;
+          uint24 length;
+          select (HandshakeType) {
+              case hello_request:       HelloRequest;
+              case client_hello:        ClientHello;
+              case server_hello:        ServerHello;
+              case certificate:         Certificate;
+              case server_key_exchange: ServerKeyExchange;
+              case certificate_request: CertificateRequest;
+              case server_hello_done:   ServerHelloDone;
+              case certificate_verify:  CertificateVerify;
+              case client_key_exchange: ClientKeyExchange;
+              case finished:            Finished;
+              case new_session_ticket:  SessionTicket; /* NEW */
+          } body;
+      } Handshake;
+
+
+      struct {
+          opaque ticket<0..2^16-1>;
+      } SessionTicket;
+
+
+3.4  Interaction with TLS session ID
+
+   If a server is planning on issuing a SessionTicket to a client that
+   does not present one it SHOULD include an empty Session ID in the
+   ServerHello.  If the server includes a non-empty session ID then it
+   is indicating intent to use stateful session resume.  If the client
+   receives a SessionTicket from the server then it discards any Session
+   ID that was sent in the ServerHello.
+
+   When presenting a ticket the client MAY generate and include a
+   Session ID in the TLS ClientHello.  If the server accepts the ticket
+   and the Session ID is not empty then it MUST respond with the same
+   Session ID present in the ClientHello.  This allows the client to
+   easily differentiate when the server is resuming a session or falling
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 6]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+   back to a full handshake.  Since the client generates a Session ID
+   the server MUST NOT rely upon the Session ID having a particular
+   value when validating the ticket.  If a ticket is presented by the
+   client the server MUST NOT attempt to use the Session ID in the
+   ClientHello for stateful session resume.  Alternatively, the client
+   MAY include an empty Session ID in the ClientHello.  In this case the
+   client ignores the Session ID sent in the ServerHello and must
+   determine if the server is resuming a session by the subsequent
+   handshake messages.
+
+4.  Recommended Ticket Construction
+
+   This section describes a recommended format and protection for the
+   ticket.  Note that the ticket is opaque to the client so the
+   structure is not subject to interoperability concerns, so
+   implementations may diverge from this format.  If implementations do
+   diverge from this format they must take security concerns seriously.
+   Clients MUST NOT examine the ticket under the assumption that it
+   complies with this document.
+
+   The server uses two different keys, one 128-bit key for AES
+   encryption and one 128-bit key for HMAC-SHA1.
+
+   The ticket is structured as follows:
+
+      struct {
+          uint32 key_version;
+          opaque iv[16]
+          opaque encrypted_state<0..2^16-1>;
+          opaque mac[20];
+      } Ticket;
+
+   Here key_version identifies a particular set of keys.  One
+   possibility is to generate new random keys every time the server is
+   started, and use the timestamp as the key version.  The same
+   mechanisms known from a number of other protocols can be reused for
+   this purpose.
+
+   The actual state information in encrypted_state is encrypted using
+   128-bit AES in CBC mode with the given IV.  The MAC is calculated
+   using HMAC-SHA1 over key_version (4 octets)and IV (16 octets),
+   followed by the length of the encrypted_state field (2 octets) and
+   its contents (variable length).
+
+
+
+
+
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 7]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+      struct {
+          ProtocolVersion protocol_version;
+          CipherSuite cipher_suite;
+          CompressionMethod compression_method;
+          opaque master_secret[48];
+          ExampleClientIdentity client_identity;
+          uint32 timestamp;
+      } StatePlaintext;
+
+      enum {
+         anonymous(0),
+         certificate_based(1),
+         psk(2)
+     } ClientAuthenticationType;
+
+      struct {
+          ClientAuthenticationType client_authentication_type;
+          select (ClientAuthenticationType) {
+              case anonymous: struct {};
+              case certificate_based:
+                  ASN.1Cert certificate_list<0..2^24-1>;
+              case psk:
+                  opaque psk_identity<0..2^16-1>;
+
+          }
+       } ClientIdentity;
+
+   The structure StatePlaintext stores the TLS session state including
+   the master_secret.  The timestamp within this structure allows the
+   TLS server to expire tickets.  To cover the authentication and key
+   exchange protocols provided by TLS the ClientIdentity structure
+   contains the authentication type of the client used in the initial
+   exchange (see ClientAuthenticationType).  To offer the TLS server
+   with the same capabilities for authentication and authorization a
+   certificate list is included in case of public key based
+   authentication.  The TLS server is therefore able to inspect a number
+   of different attributes within these certificates.  A specific
+   implementation might choose to store a subset of this information or
+   additional information.  Other authentication mechanism such as
+   Kerberos [RFC2712] would require different client identity data.
+
+5.  Security Considerations
+
+   This section addresses security issues related to the usage of a
+   ticket.  Tickets must be sufficiently authenticated and encrypted to
+   prevent modification or eavesdropping by an attacker.  Several
+   attacks described below will be possible if this is not carefully
+   done.
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 8]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+   Implementations should take care to ensure that the processing of
+   tickets does not increase the chance of denial of serve as described
+   below.
+
+5.1  Invalidating Sessions
+
+   The TLS specification requires that TLS sessions be invalidated when
+   errors occur.  [CSSC] discusses the security implications of this in
+   detail.  In the analysis in this paper, failure to invalidate
+   sessions does not pose a security risk.  This is because the TLS
+   handshake uses a non-reversible function to derive keys for a session
+   so information about one session does not provide an advantage to
+   attack the master secret or a different session.  If a session
+   invalidation scheme is used the implementation should verify the
+   integrity of the ticket before using the contents to invalidate a
+   session to ensure an attacker cannot invalidate a chosen session.
+
+5.2  Stolen Tickets
+
+   An eavesdropper or man-in-the-middle may obtain the ticket and
+   attempt to use the ticket to establish a session with the server,
+   however since the ticket is encrypted and the attacker does not know
+   the secret key a stolen key does not help an attacker resume a
+   session.  A TLS server MUST use strong encryption and integrity
+   protection for the ticket to prevent an attacker from using a brute
+   force mechanism to obtain the tickets contents.
+
+5.3  Forged Tickets
+
+   A malicious user could forge or alter a ticket in order to resume a
+   session, to extend its lifetime, to impersonate as another user or
+   gain additional privileges.  This attack is not possible if the
+   ticket is protected using a strong integrity protection algorithm
+   such as a keyed HMAC.
+
+5.4  Denial of Service Attacks
+
+   An adversary could store or forge a large number of tickets to send
+   to the TLS server for verification.  To minimize the possibility of a
+   denial of service the verification of the ticket should be
+   lightweight (e.g., using efficient symmetric key cryptographic
+   algorithms).
+
+5.5  Ticket Protection Key Lifetime
+
+   The management of the keys used to protect the ticket is beyond the
+   scope of this document.  It is advisable to limit the lifetime of
+   these keys to ensure they are not overused.
+
+
+
+Salowey, et al.          Expires April 21, 2006                 [Page 9]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+5.6  Alternate Ticket Formats and Distribution Schemes
+
+   If a different ticket format or distribution scheme than the ones
+   defined in this document is used then great care must be taken in
+   analyzing the security of the solution.  In particular if a secret is
+   transferred to the client it MUST be done using secure communication
+   so as to prevent attackers from obtaining or modifying the key.  Also
+   the ticket MUST have its integrity and privacy protected with strong
+   cryptographic techniques to prevent a breach in the security of the
+   system.
+
+6.  Acknowledgments
+
+   The authors would like to thank the following people for their help
+   with preparing and reviewing this document: Eric Rescorla, Mohamad
+   Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
+   Rob Dugal and members of the TLS working group.
+
+   [CSSC] describes a solution that is very similar to the one described
+   in this document and gives a detailed analysis of the security
+   considerations involved.  [RFC2712] describes a mechanism for using
+   Kerberos ([RFC1510]) in TLS ciphersuites, which helped inspire the
+   use of tickets to avoid server state.  [I-D.cam-winget-eap-fast]
+   makes use of a similar mechanism to avoid maintaining server state
+   for the cryptographic tunnel.  [SC97] also investigates the concept
+   of stateless sessions.
+
+7.  IANA considerations
+
+   IANA has assigned a TLS extension number of TBD1 (the value 35 is
+   suggested) to the SessionTicket TLS extension from the TLS registry
+   of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
+
+   IANA has assigned a TLS HandshakeType number TBD2 to the
+   SessionTicket handshake type from the TLS registry of HandshakeType
+   values defined in [I-D.ietf-tls-rfc2246-bis].
+
+8.  References
+
+8.1  Normative References
+
+   [AES]      National Institute of Standards and Technology, "Advanced
+              Encryption Standard (AES)", Federal Information
+              Processing Standards (FIPS) Publication 197,
+              November 2001.
+
+   [CBC]      National Institute of Standards and Technology,
+              "Recommendation for Block Cipher Modes of Operation -
+
+
+
+Salowey, et al.          Expires April 21, 2006                [Page 10]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+              Methods and Techniques", NIST Special Publication 800-38A,
+              December 2001.
+
+   [I-D.ietf-tls-rfc2246-bis]
+              Dierks, T. and E. Rescorla, "The TLS Protocol Version
+              1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
+              June 2005.
+
+   [I-D.ietf-tls-rfc3546bis]
+              Blake-Wilson, S., "Transport Layer Security (TLS)
+              Extensions", draft-ietf-tls-rfc3546bis-02 (work in
+              progress), October 2005.
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              February 1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+   [SHA1]     National Institute of Standards and Technology, "Secure
+              Hash Standard (SHS)", Federal Information Processing
+              Standards    (FIPS) Publication  180-2, August 2002.
+
+8.2  Informative References
+
+   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client-side
+              caching for TLS", Transactions on Information and
+              System Security (TISSEC) , Volume 7, Issue 4,
+              November 2004.
+
+   [I-D.cam-winget-eap-fast]
+              Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP
+              Flexible Authentication via Secure Tunneling (EAP-FAST)",
+              draft-cam-winget-eap-fast-02 (work in progress),
+              April 2005.
+
+   [I-D.ietf-tls-psk]
+              Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
+              for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
+              (work in progress), June 2005.
+
+   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
+              Authentication Service (V5)", RFC 1510, September 1993.
+
+
+
+
+Salowey, et al.          Expires April 21, 2006                [Page 11]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
+              Suites to Transport Layer Security (TLS)", RFC 2712,
+              October 1999.
+
+   [SC97]     Aura, T. and P. Nikander, "Stateless Connections",
+              Proceedings of the First International Conference on
+              Information and Communication Security (ICICS '97) , 1997.
+
+
+Authors' Addresses
+
+   Joseph Salowey
+   Cisco Systems
+   2901 3rd Ave
+   Seattle, WA  98121
+   US
+
+   Email: jsalowey@cisco.com
+
+
+   Hao Zhou
+   Cisco Systems
+   4125 Highlander Parkway
+   Richfield, OH  44286
+   US
+
+   Email: hzhou@cisco.com
+
+
+   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
+
+
+
+
+
+
+Salowey, et al.          Expires April 21, 2006                [Page 12]
+
+Internet-Draft      Stateless TLS Session Resumption        October 2005
+
+
+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 (2005).  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.
+
+
+
+
+Salowey, et al.          Expires April 21, 2006                [Page 13]
+