doc: removed protocol/ directory

While it was used during the first years of development, today
it is way more easy to access protocol documents via the IETF
web site.

Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>

1 files changed, 0 insertions, 1123 deletions

diff --git a/doc/protocol/rfc5077.txt b/doc/protocol/rfc5077.txt
deleted file mode 100644
index 13e7abe66e..0000000000
--- a/doc/protocol/rfc5077.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Salowey
-Request for Comments: 5077                                       H. Zhou
-Obsoletes: 4507                                            Cisco Systems
-Category: Standards Track                                      P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                  Nokia Siemens Networks
-                                                            January 2008
-
-
-       Transport Layer Security (TLS) Session Resumption without
-                           Server-Side State
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document describes a mechanism that 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
-   resume a session using the obtained ticket.  This document obsoletes
-   RFC 4507.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 1]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.2.  SessionTicket TLS Extension  . . . . . . . . . . . . . . .  7
-     3.3.  NewSessionTicket Handshake Message . . . . . . . . . . . .  8
-     3.4.  Interaction with TLS Session ID  . . . . . . . . . . . . .  9
-   4.  Recommended Ticket Construction  . . . . . . . . . . . . . . . 10
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-     5.1.  Invalidating Sessions  . . . . . . . . . . . . . . . . . . 12
-     5.2.  Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12
-     5.3.  Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12
-     5.4.  Denial of Service Attacks  . . . . . . . . . . . . . . . . 12
-     5.5.  Ticket Protection Key Management . . . . . . . . . . . . . 13
-     5.6.  Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 13
-     5.7.  Alternate Ticket Formats and Distribution Schemes  . . . . 13
-     5.8.  Identity Privacy, Anonymity, and Unlinkability . . . . . . 14
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
-   Appendix A.  Discussion of Changes to RFC 4507 . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 2]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) session without requiring session-specific state at the TLS
-   server.  This mechanism may be used with any TLS ciphersuite.  This
-   document applies to both TLS 1.0 defined in [RFC2246], and TLS 1.1
-   defined in [RFC4346].  The mechanism makes use of TLS extensions
-   defined in [RFC4366] and defines a new TLS message type.
-
-   This mechanism is useful in the following 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
-
-   This document obsoletes RFC 4507 [RFC4507] to correct an error in the
-   encoding that caused the specification to differ from deployed
-   implementations.  At the time of this writing, there are no known
-   implementations that follow the encoding specified in RFC 4507.  This
-   update to RFC 4507 aligns the document with currently deployed
-   implementations.  More details of the change are given in Appendix A.
-
-2.  Terminology
-
-   Within this document, the term 'ticket' refers to a cryptographically
-   protected data structure that is created 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 to the client in the form of a ticket and a
-   mechanism to present the ticket back to the server.  The ticket is
-   created by a TLS server and sent to a TLS client.  The TLS client
-   presents the ticket to the TLS server to resume a session.
-   Implementations of this specification are expected to support both
-   mechanisms.  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
-
-
-
-Salowey, et al.             Standards Track                     [Page 3]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   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 server sends an empty SessionTicket
-   extension to indicate that it will send a new session ticket using
-   the NewSessionTicket handshake message.  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
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the NewSessionTicket
-   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
-                                     (empty SessionTicket extension)
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                    NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 4]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   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 the ClientHello message.  Appendix A
-   provides a detailed description of the encoding of the extension and
-   changes from RFC 4507.  The server then decrypts the received ticket,
-   verifies the ticket's validity, 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 NewSessionTicket handshake message
-   after the ServerHello.
-
-         Client                                                Server
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                      (empty SessionTicket extension)
-                                                     NewSessionTicket
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-    Figure 2: Message Flow for Abbreviated Handshake Using New Session
-                                  Ticket
-
-   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.
-
-   In the case that the server does not wish to issue a new ticket at
-   this time, it just completes the handshake without including a
-   SessionTicket extension or NewSessionTicket handshake message.  This
-   is shown below (this flow is identical to Figure 1 in RFC 4346,
-   except for the SessionTicket extension in the first message):
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 5]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-         Client                                               Server
-
-         ClientHello
-         (SessionTicket extension)    -------->
-                                                         ServerHello
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-    Figure 3: Message Flow for Server Completing Full Handshake Without
-                        Issuing New Session Ticket
-
-   It is also permissible to have an exchange similar to Figure 3 using
-   the abbreviated handshake defined in Figure 2 of RFC 4346, where the
-   client uses the SessionTicket extension to resume the session, but
-   the server does not wish to issue a new ticket, and therefore does
-   not send a SessionTicket extension.
-
-   If the server rejects the ticket, it may still wish to issue a new
-   ticket after performing the full handshake as shown below (this flow
-   is identical to Figure 1, except the SessionTicket extension in the
-   ClientHello is not empty):
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 6]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-         Client                                               Server
-
-         ClientHello
-         (SessionTicket extension) -------->
-                                                         ServerHello
-                                     (empty SessionTicket extension)
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                  <--------          ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                 -------->
-                                                    NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                  <--------                 Finished
-         Application Data         <------->         Application Data
-
-    Figure 4: Message Flow for Server Rejecting Ticket, Performing Full
-                 Handshake, and Issuing New Session Ticket
-
-3.2.  SessionTicket TLS Extension
-
-   The SessionTicket TLS extension is based on [RFC4366].  The format of
-   the ticket is an opaque structure used to carry session-specific
-   state information.  This extension may be sent in the ClientHello and
-   ServerHello.
-
-   If the client possesses a ticket that it wants to use to resume a
-   session, then it includes the ticket in the SessionTicket extension
-   in the ClientHello.  If the client does not have a ticket and is
-   prepared to receive one in the NewSessionTicket 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
-   NewSessionTicket handshake message, then it MUST NOT include a
-   SessionTicket extension unless it is sending a non-empty ticket it
-   received through some other means from the server.
-
-   The server uses a zero-length SessionTicket extension to indicate to
-   the client that it will send a new session ticket using the
-   NewSessionTicket handshake message described in Section 3.3.  The
-   server MUST send this extension in the ServerHello if it wishes to
-   issue a new ticket to the client using the NewSessionTicket handshake
-   message.  The server MUST NOT send this extension if it does not
-   receive one in the ClientHello.
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 7]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   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 35.  The
-   extension_data field of SessionTicket extension contains the ticket.
-
-3.3.  NewSessionTicket Handshake Message
-
-   This message is sent by the server during the TLS handshake before
-   the ChangeCipherSpec message.  This message MUST be sent if the
-   server included a SessionTicket extension in the ServerHello.  This
-   message MUST NOT be sent if the server did not include a
-   SessionTicket extension in the ServerHello.  This message is included
-   in the hash used to create and verify the Finished 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 determines that it does not want to include a
-   ticket after it has included the SessionTicket extension in the
-   ServerHello, then it sends a zero-length ticket in the
-   NewSessionTicket handshake message.
-
-   If the server successfully verifies the client's ticket, then it MAY
-   renew the ticket by including a NewSessionTicket 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 possible that the client may not put the new ticket
-   into use before it initiates new connections.  The server MUST NOT
-   assume that the client actually received the updated ticket until it
-   successfully verifies the client's Finished message.
-
-   The NewSessionTicket handshake message has been assigned the number 4
-   and its definition is given at the end of this section.  The
-   ticket_lifetime_hint field contains a hint from the server about how
-   long the ticket should be stored.  The value indicates the lifetime
-   in seconds as a 32-bit unsigned integer in network byte order
-   relative to when the ticket is received.  A value of zero is reserved
-   to indicate that the lifetime of the ticket is unspecified.  A client
-   SHOULD delete the ticket and associated state when the time expires.
-   It MAY delete the ticket earlier based on local policy.  A server MAY
-   treat a ticket as valid for a shorter or longer period of time than
-   what is stated in the ticket_lifetime_hint.
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 8]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-      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 session_ticket:      NewSessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          uint32 ticket_lifetime_hint;
-          opaque ticket<0..2^16-1>;
-      } NewSessionTicket;
-
-3.4.  Interaction with TLS Session ID
-
-   If a server is planning on issuing a session ticket to a client that
-   does not present one, it SHOULD include an empty Session ID in the
-   ServerHello.  If the server rejects the ticket and falls back to the
-   full handshake then it may include a non-empty Session ID to indicate
-   its support for stateful session resumption.  If the client receives
-   a session ticket 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 from when
-   it is falling 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 resumption.
-   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 determines if the server is resuming a session by
-   the subsequent handshake messages.
-
-
-
-Salowey, et al.             Standards Track                     [Page 9]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-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, and
-   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 Advanced
-   Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode
-   [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634].
-
-   The ticket is structured as follows:
-
-      struct {
-          opaque key_name[16];
-          opaque iv[16];
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[32];
-      } ticket;
-
-   Here, key_name serves to identify a particular set of keys used to
-   protect the ticket.  It enables the server to easily recognize
-   tickets it has issued.  The key_name should be randomly generated to
-   avoid collisions between servers.  One possibility is to generate new
-   random keys and key_name every time the server is started.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The Message
-   Authentication Code (MAC) is calculated using HMAC-SHA-256 over
-   key_name (16 octets) and IV (16 octets), followed by the length of
-   the encrypted_state field (2 octets) and its contents (variable
-   length).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 10]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ClientIdentity 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>;   /* from [RFC4279] */
-          };
-       } 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 mechanisms, such as
-   Kerberos [RFC2712], would require different client identity data.
-   Other TLS extensions may require the inclusion of additional data in
-   the StatePlaintext structure.
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 11]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be authenticated and encrypted to prevent
-   modification or eavesdropping by an attacker.  Several attacks
-   described below will be possible if this is not carefully done.
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of service 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 within 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 that 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 it to establish a session with the server; however,
-   since the ticket is encrypted and the attacker does not know the
-   secret key, a stolen ticket 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 ticket's 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 another user, or to
-   gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC-SHA-256.
-
-5.4.  Denial of Service Attacks
-
-   The key_name field defined in the recommended ticket format helps the
-   server efficiently reject tickets that it did not issue.  However, an
-   adversary could store or generate a large number of tickets to send
-
-
-
-Salowey, et al.             Standards Track                    [Page 12]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   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 Management
-
-   A full description of the management of the keys used to protect the
-   ticket is beyond the scope of this document.  A list of RECOMMENDED
-   practices is given below.
-
-   o  The keys should be generated securely following the randomness
-      recommendations in [RFC4086].
-
-   o  The keys and cryptographic protection algorithms should be at
-      least 128 bits in strength.  Some ciphersuites and applications
-      may require cryptographic protection greater than 128 bits in
-      strength.
-
-   o  The keys should not be used for any purpose other than generating
-      and verifying tickets.
-
-   o  The keys should be changed regularly.
-
-   o  The keys should be changed if the ticket format or cryptographic
-      protection algorithms change.
-
-5.6.  Ticket Lifetime
-
-   The TLS server controls the lifetime of the ticket.  Servers
-   determine the acceptable lifetime based on the operational and
-   security requirements of the environments in which they are deployed.
-   The ticket lifetime may be longer than the 24-hour lifetime
-   recommended in [RFC4346].  TLS clients may be given a hint of the
-   lifetime of the ticket.  Since the lifetime of a ticket may be
-   unspecified, a client has its own local policy that determines when
-   it discards tickets.
-
-5.7.  Alternate Ticket Formats and Distribution Schemes
-
-   If the ticket format or distribution scheme defined in this document
-   is not used, then great care must be taken in analyzing the security
-   of the solution.  In particular, if confidential information, such as
-   a secret key, 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
-   confidentiality protected with strong cryptographic techniques to
-   prevent a breach in the security of the system.
-
-
-
-Salowey, et al.             Standards Track                    [Page 13]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-5.8.  Identity Privacy, Anonymity, and Unlinkability
-
-   This document mandates that the content of the ticket is
-   confidentiality protected in order to avoid leakage of its content,
-   such as user-relevant information.  As such, it prevents disclosure
-   of potentially sensitive information carried within the ticket.
-
-   The initial handshake exchange, which was used to obtain the ticket,
-   might not provide identity confidentiality of the client based on the
-   properties of TLS.  Another relevant security threat is the ability
-   for an on-path adversary to observe multiple TLS handshakes where the
-   same ticket is used, therefore concluding they belong to the same
-   communication endpoints.  Application designers that use the ticket
-   mechanism described in this document should consider that
-   unlinkability [ANON] is not necessarily provided.
-
-   While a full discussion of these topics is beyond the scope of this
-   document, it should be noted that it is possible to issue a ticket
-   using a TLS renegotiation handshake that occurs after a secure tunnel
-   has been established by a previous handshake.  This may help address
-   some privacy and unlinkability issues in some environments.
-
-6.  Acknowledgements
-
-   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, Russ Housley, Amir Herzberg, Bernard Aboba, 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 [RFC4120] in TLS ciphersuites, which helped inspire the use
-   of tickets to avoid server state.  [RFC4851] makes use of a similar
-   mechanism to avoid maintaining server state for the cryptographic
-   tunnel.  [SC97] also investigates the concept of stateless sessions.
-
-   The authors would also like to thank Jan Nordqvist, who found the
-   encoding error in RFC 4507, corrected by this document.  In addition
-   Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico provided
-   useful feedback during the review of this document.
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 14]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-7.  IANA Considerations
-
-   IANA has assigned a TLS extension number of 35 to the SessionTicket
-   TLS extension from the TLS registry of ExtensionType values defined
-   in [RFC4366].
-
-   IANA has assigned a TLS HandshakeType number 4 to the
-   NewSessionTicket handshake type from the TLS registry of
-   HandshakeType values defined in [RFC4346].
-
-   This document does not require any actions or assignments from IANA.
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC4507]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
-              "Transport Layer Security (TLS) Session Resumption without
-              Server-Side State", RFC 4507, May 2006.
-
-8.2.  Informative References
-
-   [AES]      National Institute of Standards and Technology, "Advanced
-              Encryption Standard (AES)", Federal Information Processing
-              Standards (FIPS) Publication 197, November 2001.
-
-   [ANON]     Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
-              Unobservability, Pseudonymity, and Identity Management - A
-              Consolidated Proposal for Terminology", http://
-              dud.inf.tu-dresden.de/literatur/
-              Anon_Terminology_v0.26-1.pdf Version 0.26, December 2005.
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 15]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", NIST Special Publication 800-38A,
-              December 2001.
-
-   [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.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
-              (SHA and HMAC-SHA)", RFC 4634, July 2006.
-
-   [RFC4851]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
-              Flexible Authentication via Secure Tunneling Extensible
-              Authentication Protocol Method (EAP-FAST)", RFC 4851,
-              May 2007.
-
-   [SC97]     Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 16]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-Appendix A.  Discussion of Changes to RFC 4507
-
-   RFC 4507 [RFC4507] defines a mechanism to resume a TLS session
-   without maintaining server side state by specifying an encrypted
-   ticket that is maintained on the client.  The client presents this
-   ticket to the server in a SessionTicket hello extension.  The
-   encoding in RFC 4507 used the XDR style encoding specified in TLS
-   [RFC4346].
-
-   An error in the encoding caused the specification to differ from
-   deployed implementations.  At the time of this writing there are no
-   known implementations that follow the encoding specified in RFC 4507.
-   This update to RFC 4507 aligns the document with these currently
-   deployed implementations.
-
-   Erroneous encoding in RFC 4507 resulted in two length fields; one for
-   the extension contents and one for the ticket itself.  Hence, for a
-   ticket that is 256 bytes long and begins with the hex value FF FF,
-   the encoding of the extension would be as follows according to RFC
-   4507:
-
-        00 23          Ticket Extension type 35
-        01 02          Length of extension contents
-        01 00          Length of ticket
-        FF FF .. ..    Actual ticket
-
-   The update proposed in this document reflects what implementations
-   actually encode, namely it removes the redundant length field.  So,
-   for a ticket that is 256 bytes long and begins with the hex value FF
-   FF, the encoding of the extension would be as follows according to
-   this update:
-
-        00 23          Extension type 35
-        01 00          Length of extension contents (ticket)
-        FF FF .. ..    Actual ticket
-
-   A server implemented according to RFC 4507 receiving a ticket
-   extension from a client conforming to this document would interpret
-   the first two bytes of the ticket as the length of this ticket.  This
-   will result in either an inconsistent length field or in the
-   processing of a ticket missing the first two bytes.  In the first
-   case, the server should reject the request based on a malformed
-   length.  In the second case, the server should reject the ticket
-   based on a malformed ticket, incorrect key version, or failed
-   decryption.  A server implementation based on this update receiving
-   an RFC 4507 extension would interpret the first length field as the
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 17]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   length of the ticket and include the second two length bytes as the
-   first bytes in the ticket, resulting in the ticket being rejected
-   based on a malformed ticket, incorrect key version, or failed
-   decryption.
-
-   Note that the encoding of an empty SessionTicket extension was
-   ambiguous in RFC 4507.  An RFC 4507 implementation may have encoded
-   it as:
-
-        00 23      Extension type 35
-        00 02      Length of extension contents
-        00 00      Length of ticket
-
-   or it may have encoded it the same way as this update:
-
-        00 23      Extension type 35
-        00 00      Length of extension contents
-
-   A server wishing to support RFC 4507 clients should respond to an
-   empty SessionTicket extension encoded the same way as it received it.
-
-   A server implementation can construct tickets such that it can detect
-   an RFC 4507 implementation, if one existed, by including a cookie at
-   the beginning of the tickets that can be differentiated from a valid
-   length.  For example, if an implementation constructed tickets to
-   start with the hex values FF FF, then it could determine where the
-   ticket begins and determine the length correctly from the type of
-   length fields present.
-
-   This document makes a few additional changes to RFC 4507 listed
-   below.
-
-   o  Clarifying that the server can allow session resumption using a
-      ticket without issuing a new ticket in Section 3.1.
-
-   o  Clarifying that the lifetime is relative to when the ticket is
-      received in section 3.3.
-
-   o  Clarifying that the NewSessionTicket handshake message is included
-      in the hash generated for the Finished messages in Section 3.3.
-
-   o  Clarifying the interaction with TLS Session ID in Section 3.4.
-
-   o  Recommending the use of SHA-256 for the integrity protection of
-      the ticket in Section 4.
-
-   o  Clarifying that additional data can be included in the
-      StatePlaintext structure in Section 4.
-
-
-
-Salowey, et al.             Standards Track                    [Page 18]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-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
-   Nokia Siemens Networks
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   EMail: Hannes.Tschofenig@nsn.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 19]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 20]
-