Transport Layer Security (TLS) Session Resumption without Server-Side State
RFC 4507

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

Network Working Group                                         J. Salowey
Request for Comments: 4507                                       H. Zhou
Category: Standards Track                                  Cisco Systems
                                                               P. Eronen
                                                                   Nokia
                                                           H. Tschofenig
                                                                 Siemens
                                                                May 2006

                 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.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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.

Salowey, et al.             Standards Track                     [Page 1]
RFC 4507            Stateless TLS Session Resumption            May 2006

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Protocol ........................................................3
      3.1. Overview ...................................................4
      3.2. SessionTicket TLS Extension ................................6
      3.3. NewSessionTicket Handshake Message .........................7
      3.4. Interaction with TLS Session ID ............................8
   4. Recommended Ticket Construction .................................9
   5. Security Considerations ........................................10
      5.1. Invalidating Sessions .....................................11
      5.2. Stolen Tickets ............................................11
      5.3. Forged Tickets ............................................11
      5.4. Denial of Service Attacks .................................11
      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 ............12
   6. Acknowledgements ...............................................13
   7. IANA Considerations ............................................13
   8. References .....................................................14
      8.1. Normative References ......................................14
      8.2. Informative References ....................................14

Salowey, et al.             Standards Track                     [Page 2]
RFC 4507            Stateless TLS Session Resumption            May 2006

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

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