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

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

• Versions
• 01

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