[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 RFC 4507

TLS Working Group                                             J. Salowey
Internet-Draft                                                   H. Zhou
Expires: February 17, 2005                                 Cisco Systems
                                                               P. Eronen
                                                                   Nokia
                                                           H. Tschofenig
                                                                 Siemens
                                                         August 19, 2004


            TLS Session Resumption without Server-Side State
                    draft-salowey-tls-ticket-01.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document describes a mechanism which enables the 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 mechanism makes use of TLS extensions.



Salowey, et al.        Expires February 17, 2005                [Page 1]

Internet-Draft      Stateless TLS Session Resumption         August 2004


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 . . . . . . . . . . . . . . . . . .  5
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
     5.1   Stolen Ticket  . . . . . . . . . . . . . . . . . . . . . .  7
     5.2   MitM Attack  . . . . . . . . . . . . . . . . . . . . . . .  7
     5.3   Forged Ticket  . . . . . . . . . . . . . . . . . . . . . .  8
     5.4   Privilege Escalation Attack  . . . . . . . . . . . . . . .  8
     5.5   Denial of Service Attacks  . . . . . . . . . . . . . . . .  8
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.1   Normative References . . . . . . . . . . . . . . . . . . . .  9
   8.2   Informative References . . . . . . . . . . . . . . . . . . .  9
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       Intellectual Property and Copyright Statements . . . . . . . . 11





























Salowey, et al.        Expires February 17, 2005                [Page 2]

Internet-Draft      Stateless TLS Session Resumption         August 2004


1.  Introduction

   This document defines a way to resume a TLS session without requiring
   session-specific state at the TLS server.  This mechanism is not tied
   to any particular TLS ciphersuite, but can be used with any of them.
   The mechanism makes use of TLS extensions  [RFC3546] 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 data structure
   which is created by the server and used 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 an
   empty SessionTicket TLS extension in the ClientHello message.

   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.
   One mechanism to deliver this ticket to the client using a new TLS
   handshake message, NewSessionTicket.  Other mechanisms for
   distributing tickets and keys are possible, but they are beyond the
   scope of this document.












Salowey, et al.        Expires February 17, 2005                [Page 3]

Internet-Draft      Stateless TLS Session Resumption         August 2004


         Client                                               Server

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

   The client caches this ticket along with the master secret and
   session ID associated with the current session.  When the client
   wishes to resume the session, it includes a SessionTicket TLS
   extension in the ClientHello message.  The server then verifies that
   the ticket has not been tampered with, decrypts the contents, and
   retrieves the session state it needs to resume a session in a normal
   way.


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

   Since the ticket is interpreted by the same server 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.

   It is possible that the session ticket and 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.




Salowey, et al.        Expires February 17, 2005                [Page 4]

Internet-Draft      Stateless TLS Session Resumption         August 2004


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;


3.3  Format of NewSessionTicket handshake message

   This message can be sent at any point in the TLS conversation.
   Typically this would be before the Finished message.  Would it be
   better to distribute it after the proection has started to prevent a
   bad ticket from being inserted?


      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;


4.  Sample ticket construction

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




Salowey, et al.        Expires February 17, 2005                [Page 5]

Internet-Draft      Stateless TLS Session Resumption         August 2004


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


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

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

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



Salowey, et al.        Expires February 17, 2005                [Page 6]

Internet-Draft      Stateless TLS Session Resumption         August 2004


   In ExampleStatePlaintext the TLS session state including the
   SessionID and the master_secret is stored.  The timestamp within this
   structure assures that the TLS server is able 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 want to
   use only the subject name instead of other information such as
   subjectAltName.  Other authentication mechanism such as kerberos or
   pre-shared keys would require different client identity data.

5.  Security Considerations

   This section addresses security issues related to the usage of a
   ticket.  Tickets must be sufficiently authenticated and encrypted to
   prevent modification or eavesdropping by an attacker.  Several
   attacks described below will be possible if this is not carefully
   done.

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

   Threat: If an eavesdropper can learn the ticket (e.g., by
      eavesdropping) and, then the eavesdropper could be learn the
      content of the ticket (in particular sensitive information such as
      the session key).
   Countermeasures: As shown in Section 4 a TLS server MUST encrypt the
      ticket in order not to reveal the embedded session key and other
      state information.

5.2  MitM Attack

   Threat: Since the SessionTicket TLS extension is included in the
      ClientHello message in cleartext an eavesdropper could store the
      ticket and use it in a later protocol session in order to
      impersonate the legitimate user.
   Countermeasures: The session key which is included in the ticket is
      not available to the adversary assuming that the ticket is
      properly protected with a key known only to the TLS server.  An
      adversary reusing the ticket would be detected immediately after
      the session key has to be used.



Salowey, et al.        Expires February 17, 2005                [Page 7]

Internet-Draft      Stateless TLS Session Resumption         August 2004


5.3  Forged Ticket

   Threat: A malicious user could forge or alter a ticket in order to
      resume a session, to extend its lifetime or to impersonate as
      another user.
   Countermeasures: To avoid this kind of attack, the TLS server must
      assure that proper mechanisms for protecting the ticket are in
      place.  It is recommended to protect the ticket using a keyed
      message digest or a digital signature.

5.4  Privilege Escalation Attack

   Threat: A malicious user could modify content of the ticket to
      increase its authorization privileges by modifying authorization
      information stored in the ticket.
   Countermeasures: The TLS server MUST integrity protect the ticket to
      protect the authorization part of the ticket against
      modifications.

5.5  Denial of Service Attacks

   Threat: An adversary could store a large number of tickets (possibly
      forged tickets) to send them to the TLS server for verification.
      Depending on the complexity of the verification procedure the TLS
      server might experience a denial of service attack.  Additionally,
      an adversary might inject faked tickets which cause effects
      similar to buffer overflow attacks at the TLS server.
   Countermeasures: The verification of the ticket MUST be lightweight
      (e.g., no digital signature or other expensive computations
      involving other entities for verifications).  Furthermore, the TLS
      server MUST provide integrity protection of the ticket to avoid
      tampering.

6.  Acknowledgments

   The authors would like to thank the following people for their help
   with a previous version of this draft and for their input: 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.  [EAP-FAST] makes use of a similar mechanism to avoid
   maintaing 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.




Salowey, et al.        Expires February 17, 2005                [Page 8]

Internet-Draft      Stateless TLS Session Resumption         August 2004


7.  IANA considerations

   Needs a TLS extension number (for including the ticket in client
   hello), and HandshakeType number (for delivering the ticket to the
   client).

8.  References

8.1  Normative References

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

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

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

   [EAP-FAST]
              Cam-Winget, N., McGrew, D., Salowey, J. and H. Zhou, "EAP
              Flexible Authentication via Secure Tunneling (EAP-FAST)",
              Internet-Draft work-in-progress, February 2004.

   [RFC1510]  Kohl, J. and C. 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.










Salowey, et al.        Expires February 17, 2005                [Page 9]

Internet-Draft      Stateless TLS Session Resumption         August 2004


Authors' Addresses

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

   EMail: jsalowey@cisco.com


   Hao Zhou
   Cisco Systems
   4125 Highlander Parkway
   Richfield, OH  44286
   US

   EMail: hzhou@cisco.com


   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-00045 Nokia Group
   Finland

   EMail: pasi.eronen@nokia.com


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   EMail: Hannes.Tschofenig@siemens.com















Salowey, et al.        Expires February 17, 2005               [Page 10]

Internet-Draft      Stateless TLS Session Resumption         August 2004


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 (2004).  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 17, 2005               [Page 11]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/