< draft-salowey-tls-ticket-06.txt   draft-salowey-tls-ticket-07.txt >
Network Working Group J. Salowey Network Working Group J. Salowey
Internet-Draft H. Zhou Internet-Draft H. Zhou
Expires: June 18, 2006 Cisco Systems Expires: July 29, 2006 Cisco Systems
P. Eronen P. Eronen
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
December 15, 2005 January 25, 2006
Transport Layer Security Session Resumption without Server-Side State Transport Layer Security Session Resumption without Server-Side State
draft-salowey-tls-ticket-06.txt draft-salowey-tls-ticket-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2006. This Internet-Draft will expire on July 29, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a mechanism which enables the Transport Layer This document describes a mechanism which enables the Transport Layer
Security (TLS) server to resume sessions and avoid keeping per-client Security (TLS) server to resume sessions and avoid keeping per-client
session state. The TLS server encapsulates the session state into a session state. The TLS server encapsulates the session state into a
ticket and forwards it to the client. The client can subsequently ticket and forwards it to the client. The client can subsequently
resume a session using the obtained ticket. resume a session using the obtained ticket.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 SessionTicket TLS extension . . . . . . . . . . . . . . . 5 3.2 SessionTicket TLS extension . . . . . . . . . . . . . . . 5
3.3 SessionTicket handshake message . . . . . . . . . . . . . 6 3.3 NewSessionTicket handshake message . . . . . . . . . . . . 6
3.4 Interaction with TLS session ID . . . . . . . . . . . . . 7 3.4 Interaction with TLS session ID . . . . . . . . . . . . . 7
4. Recommended Ticket Construction . . . . . . . . . . . . . . . 8 4. Recommended Ticket Construction . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1 Invalidating Sessions . . . . . . . . . . . . . . . . . . 10 5.1 Invalidating Sessions . . . . . . . . . . . . . . . . . . 10
5.2 Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10 5.2 Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10 5.3 Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10
5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 10 5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 10
5.5 Ticket Protection Key Lifetime . . . . . . . . . . . . . . 10 5.5 Ticket Protection Key Management . . . . . . . . . . . . . 10
5.6 Alternate Ticket Formats and Distribution Schemes . . . . 11 5.6 Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 5.7 Alternate Ticket Formats and Distribution Schemes . . . . 11
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 5.8 Identity Privacy, Anonymity and Unlinkability . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
8.2 Informative References . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14 8.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16
1. Introduction 1. Introduction
This document defines a way to resume a Transport Layer Security This document defines a way to resume a Transport Layer Security
(TLS) session without requiring session-specific state at the TLS (TLS) session without requiring session-specific state at the TLS
server. This mechanism may be used with any TLS ciphersuite. This 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 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 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 extensions defined in [I-D.ietf-tls-rfc3546bis] and defines a new
TLS message type. TLS message type.
This mechanism is useful in the following types of situations This mechanism is useful in the following types of situations:
(1) servers that handle a large number of transactions from
different users 1. servers that handle a large number of transactions from
(2) servers that desire to cache sessions for a long time different users
(3) ability to load balance requests across servers 2. servers that desire to cache sessions for a long time
(4) embedded servers with little memory 3. ability to load balance requests across servers
4. embedded servers with little memory
2. Terminology 2. Terminology
Within this document the term 'ticket' refers to a cryptographically Within this document the term 'ticket' refers to a cryptographically
protected data structure which is created by the server and consumed protected data structure which is created by the server and consumed
by the server to rebuild session specific state. by the server to rebuild session specific state.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Protocol 3. Protocol
This specification describes a mechanism to distribute encrypted This specification describes a mechanism to distribute encrypted
session state information in a ticket from a TLS server to a TLS session state information in the form of a ticket. The ticket is
client and a mechanism for a TLS client to present a ticket to a TLS created by a TLS server and sent to a TLS client. The TLS client
server to resume a session. Implementations of this specification presents the ticket to the TLS server to resume a session.
are expected to support both mechanisms. Other specifications can Implementations of this specification are expected to support both
take advantage of the session tickets, perhaps specifying alternative mechanisms. Other specifications can take advantage of the session
means for distribution or selection. For example a separate tickets, perhaps specifying alternative means for distribution or
specification may describe an alternate way to distribute a ticket selection. For example a separate specification may describe an
and use the TLS extension in this document to resume the session. alternate way to distribute a ticket and use the TLS extension in
This behavior is beyond the scope of the document and would need to this document to resume the session. This behavior is beyond the
be described in a separate specification. scope of the document and would need to be described in a separate
specification.
3.1 Overview 3.1 Overview
The client indicates that it supports this mechanism by including a The client indicates that it supports this mechanism by including a
SessionTicket TLS extension in the ClientHello message. The SessionTicket TLS extension in the ClientHello message. The
extension will be empty if the client does not already possess a extension will be empty if the client does not already possess a
ticket for the server. The extension is described in Section 3.2 ticket for the server. The extension is described in Section 3.2
If the server wants to use this mechanism, it stores its session If the server wants to use this mechanism, it stores its session
state (such as ciphersuite and master secret) to a ticket that is state (such as ciphersuite and master secret) to a ticket that is
encrypted and integrity-protected by a key known only to the server. encrypted and integrity-protected by a key known only to the server.
The ticket is distributed to the client using the SessionTicket TLS The ticket is distributed to the client using the NewSessionTicket
handshake message described in Section 3.3. This message is sent TLS handshake message described in Section 3.3. This message is sent
during the TLS handshake before the ChangeCipherSpec message after during the TLS handshake before the ChangeCipherSpec message after
the server has successfully verified the client's Finished message. the server has successfully verified the client's Finished message.
Client Server Client Server
ClientHello --------> ClientHello -------->
(empty SessionTicket extension) (empty SessionTicket extension)
ServerHello ServerHello
(empty SessionTicket extension) (empty SessionTicket extension)
Certificate* Certificate*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest* CertificateRequest*
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate* Certificate*
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
SessionTicket NewSessionTicket
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
Application Data <-------> Application Data Application Data <-------> Application Data
The client caches this ticket along with the master secret and other The client caches this ticket along with the master secret and other
parameters associated with the current session. When the client parameters associated with the current session. When the client
wishes to resume the session, it includes the ticket in the wishes to resume the session, it includes the ticket in the
SessionTicket extension within ClientHello message. The server then SessionTicket extension within ClientHello message. The server then
decrypts the received ticket, verifies that the ticket is valid and decrypts the received ticket, verifies that the ticket validity,
has not been tampered with, retrieves the session state from the retrieves the session state from the contents of the ticket and uses
contents of the ticket and uses this state to resume the session. this state to resume the session. The interaction with the TLS
The interaction with the TLS Session ID is described in Section 3.4. Session ID is described in Section 3.4. If the server successfully
If the server successfully verifies the client's ticket then it may verifies the client's ticket then it may renew the ticket by
renew the ticket by including a SessionTicket handshake message after including a NewSessionTicket handshake message after the ServerHello.
the ServerHello.
ClientHello ClientHello
(SessionTicket extension) --------> (SessionTicket extension) -------->
ServerHello ServerHello
(empty SessionTicket extension) (empty SessionTicket extension)
SessionTicket NewSessionTicket
[ChangeCipherSpec] [ChangeCipherSpec]
<-------- Finished <-------- Finished
[ChangeCipherSpec] [ChangeCipherSpec]
Finished --------> Finished -------->
Application Data <-------> Application Data Application Data <-------> Application Data
A recommended ticket format is given in Section 4. A recommended ticket format is given in Section 4.
If the server cannot or does not want to honor the ticket then it can If the server cannot or does not want to honor the ticket then it can
initiate a full handshake with the client. initiate a full handshake with the client.
3.2 SessionTicket TLS extension 3.2 SessionTicket TLS extension
The SessionTicket TLS extension is based on [I-D.ietf-tls- The SessionTicket TLS extension is based on [I-D.ietf-tls-
rfc3546bis]. The format of the ticket is an opaque structure used to rfc3546bis]. The format of the ticket is an opaque structure used to
carry session specific state information. This extension may be sent carry session specific state information. This extension may be sent
in the ClientHello and ServerHello. in the ClientHello and ServerHello.
If the client possesses a ticket that it wants to use to resume a 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 session then it includes the ticket in the SessionTicket extension in
ClientHello. If the client does not have a ticket and it is prepared the ClientHello. If the client does not have a ticket and it is
to receive one in the SessionTicket handshake message then it MUST prepared to receive one in the NewSessionTicket handshake message
include a zero length ticket in the SessionTicket extension. If the then it MUST include a zero length ticket in the SessionTicket
client is not prepared to receive a ticket in the SessionTicket extension. If the client is not prepared to receive a ticket in the
handshake message then it MUST NOT include a SessionTicket extension NewSessionTicket handshake message then it MUST NOT include a
unless it is sending a non-empty ticket it received through some SessionTicket extension unless it is sending a non-empty ticket it
other means from the server. received through some other means from the server.
The server uses an zero length SessionTicket extension to indicate to The server uses an zero length SessionTicket extension to indicate to
the client that it will send a new session ticket using the the client that it will send a new session ticket using the
SessionTicket handshake message described in Section 3.3. The server NewSessionTicket handshake message described in Section 3.3. The
MUST send this extension in the ServerHello if the server wishes to server MUST send this extension in the ServerHello if it wishes to
issue a new ticket to the client using the SessionTicket handshake issue a new ticket to the client using the NewSessionTicket handshake
message. The server MUST NOT send this extension if the client does message. The server MUST NOT send this extension if it does not
not include a SessionTicket handshake message in the client hello. receive on in the ClientHello.
If the server fails to verify the ticket then it falls back to 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 performing a full handshake. If the ticket is accepted by the server
but the handshake fails the client SHOULD delete the ticket. but the handshake fails the client SHOULD delete the ticket.
The SessionTicket extension has been assigned the number TBD1. The The SessionTicket extension has been assigned the number TBD1. The
format of the SessionTicket extension is given below. format of the SessionTicket extension is given at the end of this
section.
struct { struct {
opaque ticket<0..2^16-1>; opaque ticket<0..2^16-1>;
} SessionTicket; } SessionTicket;
3.3 SessionTicket handshake message 3.3 NewSessionTicket handshake message
This message is sent by the server during the TLS handshake before This message is sent by the server during the TLS handshake before
the ChangeCipherSpec message. This message MUST be sent if the the ChangeCipherSpec message. This message MUST be sent if the
server included a SessionTicket extension in the ServerHello. This server included a SessionTicket extension in the ServerHello. This
message MUST NOT be sent if the server did not include a message MUST NOT be sent if the server did not include a
SessionTicket extension in the ServerHello. In the case of a full SessionTicket extension in the ServerHello. In the case of a full
handshake, the server MUST verify the client's Finished message handshake, the server MUST verify the client's Finished message
before sending the ticket. The client MUST NOT treat the ticket as before sending the ticket. The client MUST NOT treat the ticket as
valid until it has verified the server's Finished message. If the 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 server determines that it does not want to include a ticket after it
has included the SessionTicket extension in the ServerHello then it has included the SessionTicket extension in the ServerHello then it
MAY send a zero length ticket in the SessionTicket handshake message. sends a zero length ticket in the NewSessionTicket handshake message.
If the server successfully verifies the client's ticket then it MAY If the server successfully verifies the client's ticket then it MAY
renew the ticket by including a SessionTicket handshake message after renew the ticket by including a NewSessionTicket handshake message
the ServerHello in the abbreviated handshake. The client should after the ServerHello in the abbreviated handshake. The client
start using the new ticket as soon as possible after it verifies the should start using the new ticket as soon as possible after it
Server's finished message for new connections. Note that since the verifies the Server's finished message for new connections. Note
updated ticket is issued before the handshake completes it is that since the updated ticket is issued before the handshake
possible that the client may not put the new ticket into use before completes it is possible that the client may not put the new ticket
it initiates new connections. The server MUST NOT assume the client into use before it initiates new connections. The server MUST NOT
actually received the updated ticket until it successfully verifies assume the client actually received the updated ticket until it
the client's Finished message. successfully verifies the client's Finished message.
The SessionTicket handshake message has been assigned the number The NewSessionTicket handshake message has been assigned the number
TBD2. The definition of the SessionTicket handshake message is given TBD2 and its definition is given at the end of this section. The
below. ticket_lifetime_hint field contains a hint from the server about how
long the ticket should be stored. The value indicates the lifetime
in seconds as a 32 bit unsigned integer in network byte order. A
value of zero is reserved to indicate that the lifetime of the ticket
is unspecified. A client SHOULD delete the ticket and associated
state when the time expires. It MAY delete the ticket earlier based
on local policy. A server MAY treat a ticket as valid for a shorter
or longer period of time than what is stated in the
ticket_lifetime_hint.
struct { struct {
HandshakeType msg_type; HandshakeType msg_type;
uint24 length; uint24 length;
select (HandshakeType) { select (HandshakeType) {
case hello_request: HelloRequest; case hello_request: HelloRequest;
case client_hello: ClientHello; case client_hello: ClientHello;
case server_hello: ServerHello; case server_hello: ServerHello;
case certificate: Certificate; case certificate: Certificate;
case server_key_exchange: ServerKeyExchange; case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest; case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone; case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify; case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange; case client_key_exchange: ClientKeyExchange;
case finished: Finished; case finished: Finished;
case session_ticket: SessionTicket; /* NEW */ case session_ticket: NewSessionTicket; /* NEW */
} body; } body;
} Handshake; } Handshake;
struct { struct {
uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>; opaque ticket<0..2^16-1>;
} SessionTicket; } NewSessionTicket;
3.4 Interaction with TLS session ID 3.4 Interaction with TLS session ID
If a server is planning on issuing a SessionTicket to a client that 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 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 ServerHello. If the server includes a non-empty session ID then it
is indicating intent to use stateful session resume. If the client is indicating intent to use stateful session resume. If the client
receives a SessionTicket from the server then it discards any Session receives a SessionTicket from the server then it discards any Session
ID that was sent in the ServerHello. ID that was sent in the ServerHello.
skipping to change at page 8, line 22 skipping to change at page 8, line 22
Clients MUST NOT examine the ticket under the assumption that it Clients MUST NOT examine the ticket under the assumption that it
complies with this document. complies with this document.
The server uses two different keys, one 128-bit key for AES [AES] in 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] CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
[SHA1]. [SHA1].
The ticket is structured as follows: The ticket is structured as follows:
struct { struct {
uint32 key_version; opaque key_name[16];
opaque iv[16] opaque iv[16];
opaque encrypted_state<0..2^16-1>; opaque encrypted_state<0..2^16-1>;
opaque mac[20]; opaque mac[20];
} Ticket; } ticket;
Here key_version identifies a particular set of keys. One Here key_name serves to identify a particular set of keys used to
possibility is to generate new random keys every time the server is protect the ticket. It enables the server to easily recognize
started, and use the timestamp as the key version. The same tickets it has issued. The key_name should be randomly generated to
mechanisms known from a number of other protocols can be reused for avoid collisions between servers. One possibility is to generate new
this purpose. random keys and key_name every time the server is started.
The actual state information in encrypted_state is encrypted using The actual state information in encrypted_state is encrypted using
128-bit AES in CBC mode with the given IV. The MAC is calculated 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), using HMAC-SHA1 over key_name (16 octets)and IV (16 octets), followed
followed by the length of the encrypted_state field (2 octets) and by the length of the encrypted_state field (2 octets) and its
its contents (variable length). contents (variable length).
struct { struct {
ProtocolVersion protocol_version; ProtocolVersion protocol_version;
CipherSuite cipher_suite; CipherSuite cipher_suite;
CompressionMethod compression_method; CompressionMethod compression_method;
opaque master_secret[48]; opaque master_secret[48];
ExampleClientIdentity client_identity; ClientIdentity client_identity;
uint32 timestamp; uint32 timestamp;
} StatePlaintext; } StatePlaintext;
enum { enum {
anonymous(0), anonymous(0),
certificate_based(1), certificate_based(1),
psk(2) psk(2)
} ClientAuthenticationType; } ClientAuthenticationType;
struct { struct {
skipping to change at page 9, line 43 skipping to change at page 9, line 43
the master_secret. The timestamp within this structure allows the the master_secret. The timestamp within this structure allows the
TLS server to expire tickets. To cover the authentication and key TLS server to expire tickets. To cover the authentication and key
exchange protocols provided by TLS the ClientIdentity structure exchange protocols provided by TLS the ClientIdentity structure
contains the authentication type of the client used in the initial contains the authentication type of the client used in the initial
exchange (see ClientAuthenticationType). To offer the TLS server exchange (see ClientAuthenticationType). To offer the TLS server
with the same capabilities for authentication and authorization a with the same capabilities for authentication and authorization a
certificate list is included in case of public key based certificate list is included in case of public key based
authentication. The TLS server is therefore able to inspect a number authentication. The TLS server is therefore able to inspect a number
of different attributes within these certificates. A specific of different attributes within these certificates. A specific
implementation might choose to store a subset of this information or implementation might choose to store a subset of this information or
additional information. Other authentication mechanism such as additional information. Other authentication mechanisms, such as
Kerberos [RFC2712] would require different client identity data. Kerberos [RFC2712], would require different client identity data.
5. Security Considerations 5. Security Considerations
This section addresses security issues related to the usage of a This section addresses security issues related to the usage of a
ticket. Tickets must be sufficiently authenticated and encrypted to ticket. Tickets must be sufficiently authenticated and encrypted to
prevent modification or eavesdropping by an attacker. Several prevent modification or eavesdropping by an attacker. Several
attacks described below will be possible if this is not carefully attacks described below will be possible if this is not carefully
done. done.
Implementations should take care to ensure that the processing of Implementations should take care to ensure that the processing of
skipping to change at page 10, line 42 skipping to change at page 10, line 42
5.3 Forged Tickets 5.3 Forged Tickets
A malicious user could forge or alter a ticket in order to resume a 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 session, to extend its lifetime, to impersonate as another user or
gain additional privileges. This attack is not possible if the gain additional privileges. This attack is not possible if the
ticket is protected using a strong integrity protection algorithm ticket is protected using a strong integrity protection algorithm
such as a keyed HMAC-SHA1. such as a keyed HMAC-SHA1.
5.4 Denial of Service Attacks 5.4 Denial of Service Attacks
An adversary could store or forge a large number of tickets to send The key_name field defined in the recommended ticket format helps the
server efficiently reject tickets that it did not issue. However, an
adversary could store or generate a large number of tickets to send
to the TLS server for verification. To minimize the possibility of a to the TLS server for verification. To minimize the possibility of a
denial of service, the verification of the ticket should be denial of service, the verification of the ticket should be
lightweight (e.g., using efficient symmetric key cryptographic lightweight (e.g., using efficient symmetric key cryptographic
algorithms). algorithms).
5.5 Ticket Protection Key Lifetime 5.5 Ticket Protection Key Management
The management of the keys used to protect the ticket is beyond the A full description of the management of the keys used to protect the
scope of this document. It is advisable to limit the lifetime of ticket is beyond the scope of this document. A list of RECOMMENDED
these keys to ensure they are not overused. practices is given below.
5.6 Alternate Ticket Formats and Distribution Schemes o The key should be generated securely following the randomness
recommendations in [RFC4086]
o The key and cryptographic protection algorithms should be at least
128 bits in strength
o The key should not be used for any other purpose than generating
and verifying tickets
o The key should be changed regularly
o The key should be changed if the ticket format or cryptographic
protection algorithms change
If a different ticket format or distribution scheme than the ones 5.6 Ticket Lifetime
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 The TLS server controls the lifetime of the ticket. Servers
transferred to the client it MUST be done using secure communication determine the acceptable lifetime based on the operational and
so as to prevent attackers from obtaining or modifying the key. Also security requirements of the environments in which they are deployed.
the ticket MUST have its integrity and privacy protected with strong The ticket lifetime may be longer than the 24 hour lifetime
cryptographic techniques to prevent a breach in the security of the recommended in [RFC2246]. TLS clients may be given a hint of the
system. lifetime of the ticket. Since the lifetime of a ticket may be
unspecified a client has its own local policy which determines when
it discards tickets.
5.7 Alternate Ticket Formats and Distribution Schemes
If the ticket format or distribution scheme defined in this document
is not used then great care must be taken in analyzing the security
of the solution. In particular if a confidential information, such
as a secret key, 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.
5.8 Identity Privacy, Anonymity and Unlinkability
This document mandates that the content of the ticket is
confidentiality protected in order to avoid leakage of its content,
such as user relevant information. As such, it prevents disclosure
of potentially sensitive information carried within the ticket.
The initial handshake exchange, which was used to obtain the ticket,
might not provide identity confidentiality of the client based on the
properties of TLS. Another relevant security threat is the ability
for an on-path adversary to observe multiple TLS handshakes where the
same ticket is used and to therefore conclude that they belong to the
same communication endpoints. Application designers that use the
ticket mechanism described in this document should consider that
unlinkability [ANON] is not necessarily provided.
While a full discussion of these topics is beyond the scope of this
document, it should be noted that it is possible to issue a ticket
using a TLS renegotiation handshake that occurs after a secure tunnel
has been established by a previous handshake. This may help address
some privacy and unlinkability issues in some environments.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank the following people for their help The authors would like to thank the following people for their help
with preparing and reviewing this document: Eric Rescorla, Mohamad with preparing and reviewing this document: Eric Rescorla, Mohamad
Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew, Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
Rob Dugal and members of the TLS working group. Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba and members of
the TLS working group.
[CSSC] describes a solution that is very similar to the one described [CSSC] describes a solution that is very similar to the one described
in this document and gives a detailed analysis of the security in this document and gives a detailed analysis of the security
considerations involved. [RFC2712] describes a mechanism for using considerations involved. [RFC2712] describes a mechanism for using
Kerberos ([RFC4120]) in TLS ciphersuites, which helped inspire the Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use
use of tickets to avoid server state. [I-D.cam-winget-eap-fast] of tickets to avoid server state. [I-D.cam-winget-eap-fast] makes
makes use of a similar mechanism to avoid maintaining server state use of a similar mechanism to avoid maintaining server state for the
for the cryptographic tunnel. [SC97] also investigates the concept cryptographic tunnel. [SC97] also investigates the concept of
of stateless sessions. stateless sessions.
7. IANA considerations 7. IANA considerations
IANA has assigned a TLS extension number of TBD1 (the value 35 is IANA has assigned a TLS extension number of TBD1 (the value 35 is
suggested) to the SessionTicket TLS extension from the TLS registry suggested) to the SessionTicket TLS extension from the TLS registry
of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis]. of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
IANA has assigned a TLS HandshakeType number TBD2 to the IANA has assigned a TLS HandshakeType number TBD2 to the
SessionTicket handshake type from the TLS registry of HandshakeType NewSessionTicket handshake type from the TLS registry of
values defined in [I-D.ietf-tls-rfc2246-bis]. HandshakeType values defined in [I-D.ietf-tls-rfc2246-bis].
8. References 8. References
8.1 Normative References 8.1 Normative References
[I-D.ietf-tls-rfc2246-bis] [I-D.ietf-tls-rfc2246-bis]
Dierks, T. and E. Rescorla, "The TLS Protocol Version Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress), 1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
June 2005. June 2005.
skipping to change at page 12, line 20 skipping to change at page 13, line 19
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
8.2 Informative References 8.2 Informative References
[AES] National Institute of Standards and Technology, "Advanced [AES] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information Encryption Standard (AES)", Federal Information
Processing Standards (FIPS) Publication 197, Processing Standards (FIPS) Publication 197,
November 2001. November 2001.
[ANON] Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
Unobservability, Pseudonymity, and Identity Management - A
Consolidated Proposal for Terminology", http://
dud.inf.tu-dresden.de/literatur/
Anon_Terminology_v0.26-1.pdf Draft 0.26, December 2005.
[CBC] National Institute of Standards and Technology, [CBC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation - "Recommendation for Block Cipher Modes of Operation -
Methods and Techniques", NIST Special Publication 800-38A, Methods and Techniques", NIST Special Publication 800-38A,
December 2001. December 2001.
[CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
caching for TLS", Transactions on Information and caching for TLS", Transactions on Information and
System Security (TISSEC) , Volume 7, Issue 4, System Security (TISSEC) , Volume 7, Issue 4,
November 2004. November 2004.
skipping to change at page 12, line 44 skipping to change at page 13, line 49
April 2005. April 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712, Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999. October 1999.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, for Transport Layer Security (TLS)", RFC 4279,
December 2005. December 2005.
[SC97] Aura, T. and P. Nikander, "Stateless Connections", [SC97] Aura, T. and P. Nikander, "Stateless Connections",
Proceedings of the First International Conference on Proceedings of the First International Conference on
skipping to change at page 14, line 41 skipping to change at page 16, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 41 change blocks. 
109 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/