Transport Layer Security (TLS) Session Resumption without Server-Side State
RFC 4507
Document | Type |
RFC - Proposed Standard
(May 2006; No errata)
Obsoleted by RFC 5077
Was draft-salowey-tls-ticket (individual in sec area)
|
|
---|---|---|---|
Authors | Joseph Salowey , Hao Zhou , Hannes Tschofenig , Pasi Eronen | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4507 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
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 sessionShow full document text