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]
