Network Working Group                                         J. Salowey
Internet-Draft                                                   H. Zhou
Obsoletes: 4507 (if approved)                              Cisco Systems
Intended status: Standards Track                               P. Eronen
Expires: December 13, 2007                                         Nokia
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                           June 11, 2007


 Transport Layer Security (TLS) Session Resumption without Server-Side
                                 State
                  draft-salowey-tls-rfc4507bis-00.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 13, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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



Salowey, et al.         Expires December 13, 2007               [Page 1]


Internet-Draft      Stateless TLS Session Resumption           June 2007


   ticket and forwards it to the client.  The client can subsequently
   resume a session using the obtained ticket.  This document obsoletes
   RFC 4507.


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 . . . . . . . . . . . .  7
     3.4.  Interaction with TLS Session ID  . . . . . . . . . . . . .  9
   4.  Recommended Ticket Construction  . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
     5.1.  Invalidating Sessions  . . . . . . . . . . . . . . . . . . 11
     5.2.  Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 11
     5.3.  Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  Denial of Service Attacks  . . . . . . . . . . . . . . . . 12
     5.5.  Ticket Protection Key Management . . . . . . . . . . . . . 12
     5.6.  Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 12
     5.7.  Alternate Ticket Formats and Distribution Schemes  . . . . 12
     5.8.  Identity Privacy, Anonymity, and Unlinkability . . . . . . 13
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Discussion of Changes to RFC4507  . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18



















Salowey, et al.         Expires December 13, 2007               [Page 2]


Internet-Draft      Stateless TLS Session Resumption           June 2007


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 this 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 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 the form of a ticket.  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
   alternate way to distribute a ticket and use the TLS extension in



Salowey, et al.         Expires December 13, 2007               [Page 3]


Internet-Draft      Stateless TLS Session Resumption           June 2007


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

   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.  The server
   then decrypts the received ticket, verifies the ticket's validity,
   retrieves the session state from the contents of the ticket, and uses



Salowey, et al.         Expires December 13, 2007               [Page 4]


Internet-Draft      Stateless TLS Session Resumption           June 2007


   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 2246,
   except for the session ticket extension in the first message):




















Salowey, et al.         Expires December 13, 2007               [Page 5]


Internet-Draft      Stateless TLS Session Resumption           June 2007


         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

   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
   Client Hello is not empty):


         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



Salowey, et al.         Expires December 13, 2007               [Page 6]


Internet-Draft      Stateless TLS Session Resumption           June 2007


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

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




Salowey, et al.         Expires December 13, 2007               [Page 7]


Internet-Draft      Stateless TLS Session Resumption           June 2007


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


      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;




Salowey, et al.         Expires December 13, 2007               [Page 8]


Internet-Draft      Stateless TLS Session Resumption           June 2007


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 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 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 determines 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, 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 AES [AES] in
   CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
   [SHA1].

   The ticket is structured as follows:

      struct {
          opaque key_name[16];
          opaque iv[16];
          opaque encrypted_state<0..2^16-1>;
          opaque mac[20];
      } ticket;




Salowey, et al.         Expires December 13, 2007               [Page 9]


Internet-Draft      Stateless TLS Session Resumption           June 2007


   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 MAC is calculated
   using HMAC-SHA1 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).


      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



Salowey, et al.         Expires December 13, 2007              [Page 10]


Internet-Draft      Stateless TLS Session Resumption           June 2007


   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.


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 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 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 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 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 as another user, or
   to gain additional privileges.  This attack is not possible if the
   ticket is protected using a strong integrity protection algorithm



Salowey, et al.         Expires December 13, 2007              [Page 11]


Internet-Draft      Stateless TLS Session Resumption           June 2007


   such as a keyed HMAC-SHA1.

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
   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.
   o  The keys should not be used for any other purpose 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 [RFC2246].  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



Salowey, et al.         Expires December 13, 2007              [Page 12]


Internet-Draft      Stateless TLS Session Resumption           June 2007


   prevent a breach in the security of the system.

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 and therefore to conclude that 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.


7.  IANA Considerations

   IANA has assigned a TLS extension number of 35 to the SessionTicket



Salowey, et al.         Expires December 13, 2007              [Page 13]


Internet-Draft      Stateless TLS Session Resumption           June 2007


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


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 Draft 0.26, December 2005.

   [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



Salowey, et al.         Expires December 13, 2007              [Page 14]


Internet-Draft      Stateless TLS Session Resumption           June 2007


              caching for TLS", Transactions on Information and
              System Security (TISSEC) , Volume 7, Issue 4,
              November 2004.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

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

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

   [SHA1]     National Institute of Standards and Technology, "Secure
              Hash Standard (SHS)", Federal Information Processing
              Standards    (FIPS) Publication  180-2, August 2002.


Appendix A.  Discussion of Changes to RFC4507

   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



Salowey, et al.         Expires December 13, 2007              [Page 15]


Internet-Draft      Stateless TLS Session Resumption           June 2007


   known implementations that follow the encoding specified in RFC 4507.
   This update to RFC 4507 aligns the document with this 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          SessionTicket 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 an 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
   and 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 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.

   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.




Salowey, et al.         Expires December 13, 2007              [Page 16]


Internet-Draft      Stateless TLS Session Resumption           June 2007


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@siemens.com















Salowey, et al.         Expires December 13, 2007              [Page 17]


Internet-Draft      Stateless TLS Session Resumption           June 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Salowey, et al.         Expires December 13, 2007              [Page 18]