Network Working Group J. Salowey
Internet-Draft H. Zhou
Expires: June 18, 2006 Cisco Systems
P. Eronen
Nokia
H. Tschofenig
Siemens
December 15, 2005
Transport Layer Security Session Resumption without Server-Side State
draft-salowey-tls-ticket-06.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 June 18, 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 June 18, 2006 [Page 1]
Internet-Draft Stateless TLS Session Resumption December 2005
resume a session using the obtained ticket.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 SessionTicket TLS extension . . . . . . . . . . . . . . . 5
3.3 SessionTicket handshake message . . . . . . . . . . . . . 6
3.4 Interaction with TLS session ID . . . . . . . . . . . . . 7
4. Recommended Ticket Construction . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1 Invalidating Sessions . . . . . . . . . . . . . . . . . . 10
5.2 Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10
5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 10
5.5 Ticket Protection Key Lifetime . . . . . . . . . . . . . . 10
5.6 Alternate Ticket Formats and Distribution Schemes . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Salowey, et al. Expires June 18, 2006 [Page 2]
Internet-Draft Stateless TLS Session Resumption December 2005
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 [I-D.ietf-tls-rfc2246-bis]. 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
This specification describes a mechanism to distribute encrypted
session state information in a ticket from a TLS server to a TLS
client and a mechanism for a TLS client to present a ticket to a TLS
server to resume a session. Implementations of this specification
are expected to support both mechanisms. Other specifications can
take advantage of the session tickets, perhaps specifying alternative
means for distribution or selection. For example a separate
specification may describe an alternate way to distribute a ticket
and use the TLS extension in this document to resume the session.
This behavior is beyond the scope of the document and would need to
be described in a separate specification.
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. The extension is described in Section 3.2
Salowey, et al. Expires June 18, 2006 [Page 3]
Internet-Draft Stateless TLS Session Resumption December 2005
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 SessionTicket TLS
handshake message described in Section 3.3. This message is sent
during the TLS handshake before the ChangeCipherSpec message after
the server has successfully verified the client's Finished message.
Client Server
ClientHello -------->
(empty SessionTicket extension)
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
SessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
The client caches this ticket along with the master secret and other
parameters associated with the current session. When the client
wishes to resume the session, it includes the ticket in the
SessionTicket extension within ClientHello message. The server then
decrypts the received ticket, verifies that the ticket is valid and
has not been tampered with, retrieves the session state from the
contents of the ticket and uses this state to resume the session.
The interaction with the TLS Session ID is described in Section 3.4.
If the server successfully verifies the client's ticket then it may
renew the ticket by including a SessionTicket handshake message after
the ServerHello.
Salowey, et al. Expires June 18, 2006 [Page 4]
Internet-Draft Stateless TLS Session Resumption December 2005
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
SessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
A recommended 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.
3.2 SessionTicket TLS extension
The SessionTicket TLS extension is based on [I-D.ietf-tls-
rfc3546bis]. The format of the ticket is an opaque structure used to
carry session specific state information. This extension may be sent
in the ClientHello and ServerHello.
If the client possesses a ticket that it wants to use to resume a
session then it includes it in the SessionTicket extension in the
ClientHello. If the client does not have a ticket and it is prepared
to receive one in the SessionTicket handshake message then it MUST
include a zero length ticket in the SessionTicket extension. If the
client is not prepared to receive a ticket in the SessionTicket
handshake message then it MUST NOT include a SessionTicket extension
unless it is sending a non-empty ticket it received through some
other means from the server.
The server uses an zero length SessionTicket extension to indicate to
the client that it will send a new session ticket using the
SessionTicket handshake message described in Section 3.3. The server
MUST send this extension in the ServerHello if the server wishes to
issue a new ticket to the client using the SessionTicket handshake
message. The server MUST NOT send this extension if the client does
not include a SessionTicket handshake message in the client hello.
If the server fails to verify the ticket then it falls back to
performing a full handshake. If the ticket is accepted by the server
but the handshake fails the client SHOULD delete the ticket.
The SessionTicket extension has been assigned the number TBD1. The
format of the SessionTicket extension is given below.
Salowey, et al. Expires June 18, 2006 [Page 5]
Internet-Draft Stateless TLS Session Resumption December 2005
struct {
opaque ticket<0..2^16-1>;
} SessionTicket;
3.3 SessionTicket handshake message
This message is sent by the server during the TLS handshake before
the ChangeCipherSpec message. This message MUST be sent if the
server included a SessionTicket extension in the ServerHello. This
message MUST NOT be sent if the server did not include a
SessionTicket extension in the ServerHello. In the case of a full
handshake, the server MUST verify the client's Finished message
before sending the ticket. The client MUST NOT treat the ticket as
valid until it has verified the server's Finished message. If the
server determines that it does not want to include a ticket after it
has included the SessionTicket extension in the ServerHello then it
MAY send a zero length ticket in the SessionTicket handshake message.
If the server successfully verifies the client's ticket then it MAY
renew the ticket by including a SessionTicket handshake message after
the ServerHello in the abbreviated handshake. The client should
start using the new ticket as soon as possible after it verifies the
Server's finished message for new connections. Note that since the
updated ticket is issued before the handshake completes it is
possible that the client may not put the new ticket into use before
it initiates new connections. The server MUST NOT assume the client
actually received the updated ticket until it successfully verifies
the client's Finished message.
The SessionTicket handshake message has been assigned the number
TBD2. The definition of the SessionTicket handshake message is given
below.
Salowey, et al. Expires June 18, 2006 [Page 6]
Internet-Draft Stateless TLS Session Resumption December 2005
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 session_ticket: SessionTicket; /* NEW */
} body;
} Handshake;
struct {
opaque ticket<0..2^16-1>;
} SessionTicket;
3.4 Interaction with TLS session ID
If a server is planning on issuing a SessionTicket to a client that
does not present one it SHOULD include an empty Session ID in the
ServerHello. If the server includes a non-empty session ID then it
is indicating intent to use stateful session resume. If the client
receives a SessionTicket from the server then it discards any Session
ID that was sent in the ServerHello.
When presenting a ticket the client MAY generate and include a
Session ID in the TLS ClientHello. If the server accepts the ticket
and the Session ID is not empty then it MUST respond with the same
Session ID present in the ClientHello. This allows the client to
easily differentiate when the server is resuming a session or falling
back to a full handshake. Since the client generates a Session ID
the server MUST NOT rely upon the Session ID having a particular
value when validating the ticket. If a ticket is presented by the
client the server MUST NOT attempt to use the Session ID in the
ClientHello for stateful session resume. Alternatively, the client
MAY include an empty Session ID in the ClientHello. In this case the
client ignores the Session ID sent in the ServerHello and determines
if the server is resuming a session by the subsequent handshake
messages.
Salowey, et al. Expires June 18, 2006 [Page 7]
Internet-Draft Stateless TLS Session Resumption December 2005
4. Recommended Ticket Construction
This section describes a recommended format and protection for the
ticket. Note that the ticket is opaque to the client so the
structure is not subject to interoperability concerns, so
implementations may diverge from this format. If implementations do
diverge from this format they must take security concerns seriously.
Clients MUST NOT examine the ticket under the assumption that it
complies with this document.
The server uses two different keys, one 128-bit key for AES [AES] in
CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
[SHA1].
The ticket is structured as follows:
struct {
uint32 key_version;
opaque iv[16]
opaque encrypted_state<0..2^16-1>;
opaque mac[20];
} Ticket;
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 length of the encrypted_state field (2 octets) and
its contents (variable length).
Salowey, et al. Expires June 18, 2006 [Page 8]
Internet-Draft Stateless TLS Session Resumption December 2005
struct {
ProtocolVersion protocol_version;
CipherSuite cipher_suite;
CompressionMethod compression_method;
opaque master_secret[48];
ExampleClientIdentity client_identity;
uint32 timestamp;
} StatePlaintext;
enum {
anonymous(0),
certificate_based(1),
psk(2)
} ClientAuthenticationType;
struct {
ClientAuthenticationType client_authentication_type;
select (ClientAuthenticationType) {
case anonymous: struct {};
case certificate_based:
ASN.1Cert certificate_list<0..2^24-1>;
case psk:
opaque psk_identity<0..2^16-1>;
}
} ClientIdentity;
The structure StatePlaintext stores the TLS session state including
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 ClientIdentity structure
contains the authentication type of the client used in the initial
exchange (see ClientAuthenticationType). 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 or
additional information. Other authentication mechanism such as
Kerberos [RFC2712] 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.
Salowey, et al. Expires June 18, 2006 [Page 9]
Internet-Draft Stateless TLS Session Resumption December 2005
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 ticket 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-SHA1.
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).
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.
Salowey, et al. Expires June 18, 2006 [Page 10]
Internet-Draft Stateless TLS Session Resumption December 2005
5.6 Alternate Ticket Formats and Distribution Schemes
If a different ticket format or distribution scheme than the ones
defined in this document is used then great care must be taken in
analyzing the security of the solution. In particular if a secret is
transferred to the client it MUST be done using secure communication
so as to prevent attackers from obtaining or modifying the key. Also
the ticket MUST have its integrity and privacy protected with strong
cryptographic techniques to prevent a breach in the security of the
system.
6. Acknowledgments
The authors would like to thank the following people for their help
with preparing and reviewing this document: Eric Rescorla, Mohamad
Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
Rob Dugal and members of the TLS working group.
[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. [RFC2712] describes a mechanism for using
Kerberos ([RFC4120]) 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. [SC97] also investigates the concept
of stateless sessions.
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
SessionTicket 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)
Salowey, et al. Expires June 18, 2006 [Page 11]
Internet-Draft Stateless TLS Session Resumption December 2005
Extensions", draft-ietf-tls-rfc3546bis-02 (work in
progress), October 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
8.2 Informative References
[AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information
Processing Standards (FIPS) Publication 197,
November 2001.
[CBC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation -
Methods and Techniques", NIST Special Publication 800-38A,
December 2001.
[CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
caching for TLS", Transactions on Information and
System Security (TISSEC) , Volume 7, Issue 4,
November 2004.
[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.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279,
December 2005.
Salowey, et al. Expires June 18, 2006 [Page 12]
Internet-Draft Stateless TLS Session Resumption December 2005
[SC97] Aura, T. and P. Nikander, "Stateless Connections",
Proceedings of the First International Conference on
Information and Communication Security (ICICS '97) , 1997.
[SHA1] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", Federal Information Processing
Standards (FIPS) Publication 180-2, August 2002.
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 June 18, 2006 [Page 13]
Internet-Draft Stateless TLS Session Resumption December 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 June 18, 2006 [Page 14]
