path: root/doc/protocol/draft-salowey-tls-ticket-04.txt

Network Working Group                                         J. Salowey
Internet-Draft                                                   H. Zhou
Expires: February 2, 2006                                  Cisco Systems
                                                               P. Eronen
                                                                   Nokia
                                                           H. Tschofenig
                                                                 Siemens
                                                             August 2005


 Transport Layer Security Session Resumption without Server-Side State
                    draft-salowey-tls-ticket-04.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 February 2, 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 February 2, 2006                [Page 1]

Internet-Draft      Stateless TLS Session Resumption         August 2005


   resume a session using the obtained ticket.  This mechanism makes use
   of new TLS handshake messages and TLS hello extensions.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.2   Format of SessionTicket TLS extension  . . . . . . . . . .  5
     3.3   Format of NewSessionTicket handshake message . . . . . . .  5
   4.  Sample ticket construction . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . .  8
     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . .  8
     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . .  8
     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . .  8
     5.5   Ticket Protection Key Lifetime . . . . . . . . . . . . . .  9
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1   Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2   Informative References . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 12


























Salowey, et al.         Expires February 2, 2006                [Page 2]

Internet-Draft      Stateless TLS Session Resumption         August 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

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.

   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.  This message is sent during the TLS handshake
   before the ChangeCipherSpec message after the server has verified the
   client's Finished message.










Salowey, et al.         Expires February 2, 2006                [Page 3]

Internet-Draft      Stateless TLS Session Resumption         August 2005


         Client                                               Server

         ClientHello                   -------->
        (empty SessionTicket extension)
                                                         ServerHello
                                                        Certificate*
                                                  ServerKeyExchange*
                                                 CertificateRequest*
                                      <--------      ServerHelloDone
         Certificate*
         ClientKeyExchange
         CertificateVerify*
         [ChangeCipherSpec]
         Finished                     -------->
                                                  NewSessionTicket
                                                  [ChangeCipherSpec]
                                      <--------             Finished
         Application Data             <------->     Application Data

   The client caches this ticket along with the master secret, session
   ID and other parameters associated with the current session.  When
   the client wishes to resume the session, it includes a SessionTicket
   TLS extension in the SessionTicket extension within ClientHello
   message.  The server then verifies that the ticket has not been
   tampered with, decrypts the contents, and retrieves the session state
   from the contents of the ticket and uses this state to resume the
   session.  Since separate fields in the request are used for the
   session ID and the ticket standard stateful session resume can co-
   exist with the ticket based session resume described in this
   specification.


         ClientHello
         (SessionTicket extension)      -------->
                                                          ServerHello
                                                   [ChangeCipherSpec]
                                       <--------             Finished
         [ChangeCipherSpec]
         Finished                      -------->
         Application Data              <------->     Application Data

   Since the ticket is typically interpreted by the same server or group
   of servers that created it, the exact format of the ticket does not
   need to be the same for all implementations.  A sample 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.




Salowey, et al.         Expires February 2, 2006                [Page 4]

Internet-Draft      Stateless TLS Session Resumption         August 2005


   It is possible that the session ticket and master session key could
   be delivered through some out of band mechanism.  This behavior is
   beyond the scope of the document and would need to be described in a
   separate specification.

3.2  Format of SessionTicket TLS extension

   The format of the ticket is an opaque structure used to carry session
   specific state information.


      struct {
          opaque ticket<0..2^16-1>;
      } SessionTicket;

   The SessionTicket extension has been assigned the number TBD1.

3.3  Format of NewSessionTicket handshake message

   This message is sent during the TLS handshake before the
   ChangeCipherSpec message after the server has verified the client's
   Finished message.


      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:  NewSessionTicket; /* NEW */
          } body;
      } Handshake;


      struct {
          opaque ticket<0..2^16-1>;
      } NewSessionTicket;

   The NewSessionTicket handshake message has been assigned the number



Salowey, et al.         Expires February 2, 2006                [Page 5]

Internet-Draft      Stateless TLS Session Resumption         August 2005


   TBD2.

4.  Sample ticket construction

   This section describes one possibility how the ticket could be
   constructed, other implementations are possible.

   The server uses two 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];
      } ExampleTicket;

   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 contents of the encrypted_state field (without the
   length).





















Salowey, et al.         Expires February 2, 2006                [Page 6]

Internet-Draft      Stateless TLS Session Resumption         August 2005


      struct {
          ProtocolVersion protocol_version;
          SessionID session_id;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          opaque master_secret[48];
          ExampleClientIdentity client_identity;
          uint32 timestamp;
      } ExampleStatePlaintext;

      enum {
         anonymous(0),
         certificate_based(1),
         psk(2)
     } ExampleClientAuthenticationType;

      struct {
          ExampleClientAuthenticationType client_authentication_type;
          select (ExampleClientAuthenticationType) {
              case anonymous: struct {};
              case certificate_based:
                  ASN.1Cert certificate_list<0..2^24-1>;
              case psk:
                  opaque psk_identity<0..2^16-1>;

          }
       } ExampleClientIdentity;

   The structure ExampleStatePlaintext stores the TLS session state
   including the SessionID and 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
   ExampleClientIdentity structure contains the authentication type of
   the client used in the initial exchange (see
   ExampleClientAuthenticationType).  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.  Other authentication mechanism
   such as Kerberos [RFC2712] or pre-shared keys [I-D.ietf-tls-psk]
   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



Salowey, et al.         Expires February 2, 2006                [Page 7]

Internet-Draft      Stateless TLS Session Resumption         August 2005


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






Salowey, et al.         Expires February 2, 2006                [Page 8]

Internet-Draft      Stateless TLS Session Resumption         August 2005


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.

6.  Acknowledgments

   The authors would like to thank the following people for their help
   with this document: Eric Rescorla, Mohamad Badra, Nancy Cam-Winget
   and David McGrew.

   [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.
   [AURA97] also investigates the concept of stateless sessions.  [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.

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
   NewSessionTicket handshake type from the TLS registry of
   HandshakeType values defined in [I-D.ietf-tls-rfc2246-bis].

8.  References

8.1  Normative References

   [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-01 (work in
              progress), May 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Salowey, et al.         Expires February 2, 2006                [Page 9]

Internet-Draft      Stateless TLS Session Resumption         August 2005


   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

8.2  Informative References

   [AURA97]   Aura, T. and P. Nikander, "Stateless Connections",
              Proceedings of the First International Conference on
              Information and Communication Security (ICICS '97) , 1997.

   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client Side
              Caching for TLS",
              URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf.

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

   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
              Suites to Transport Layer Security (TLS)", RFC 2712,
              October 1999.


Authors' Addresses

   Joseph Salowey
   Cisco Systems
   2901 3rd Ave
   Seattle, WA  98121
   US

   Email: jsalowey@cisco.com










Salowey, et al.         Expires February 2, 2006               [Page 10]

Internet-Draft      Stateless TLS Session Resumption         August 2005


   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 February 2, 2006               [Page 11]

Internet-Draft      Stateless TLS Session Resumption         August 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 February 2, 2006               [Page 12]