summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5077.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5077.txt')
-rw-r--r--doc/rfc/rfc5077.txt1123
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc5077.txt b/doc/rfc/rfc5077.txt
new file mode 100644
index 0000000..13e7abe
--- /dev/null
+++ b/doc/rfc/rfc5077.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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
+ document are to be interpreted as described in [RFC2119].
+
+3. Protocol
+
+ This specification describes a mechanism to distribute encrypted
+ session-state information to the client in the form of a ticket and a
+ mechanism to present the ticket back to the server. 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 session
+ tickets, perhaps specifying alternative means for distribution or
+ selection. For example, a separate specification may describe an
+
+
+
+Salowey, et al. Standards Track [Page 3]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ 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 server sends an empty SessionTicket
+ extension to indicate that it will send a new session ticket using
+ the NewSessionTicket handshake message. The extension is described
+ in Section 3.2.
+
+ 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 NewSessionTicket
+ 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 -------->
+ NewSessionTicket
+ [ChangeCipherSpec]
+ <-------- Finished
+ Application Data <-------> Application Data
+
+ Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 4]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ 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 the ClientHello message. Appendix A
+ provides a detailed description of the encoding of the extension and
+ changes from RFC 4507. The server then decrypts the received ticket,
+ verifies the ticket's validity, 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 NewSessionTicket handshake message
+ after the ServerHello.
+
+ Client Server
+ ClientHello
+ (SessionTicket extension) -------->
+ ServerHello
+ (empty SessionTicket extension)
+ NewSessionTicket
+ [ChangeCipherSpec]
+ <-------- Finished
+ [ChangeCipherSpec]
+ Finished -------->
+ Application Data <-------> Application Data
+
+ Figure 2: Message Flow for Abbreviated Handshake Using New Session
+ Ticket
+
+ 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.
+
+ In the case that the server does not wish to issue a new ticket at
+ this time, it just completes the handshake without including a
+ SessionTicket extension or NewSessionTicket handshake message. This
+ is shown below (this flow is identical to Figure 1 in RFC 4346,
+ except for the SessionTicket extension in the first message):
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 5]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ Client Server
+
+ ClientHello
+ (SessionTicket extension) -------->
+ ServerHello
+ Certificate*
+ ServerKeyExchange*
+ CertificateRequest*
+ <-------- ServerHelloDone
+ Certificate*
+ ClientKeyExchange
+ CertificateVerify*
+ [ChangeCipherSpec]
+ Finished -------->
+ [ChangeCipherSpec]
+ <-------- Finished
+ Application Data <-------> Application Data
+
+ Figure 3: Message Flow for Server Completing Full Handshake Without
+ Issuing New Session Ticket
+
+ It is also permissible to have an exchange similar to Figure 3 using
+ the abbreviated handshake defined in Figure 2 of RFC 4346, where the
+ client uses the SessionTicket extension to resume the session, but
+ the server does not wish to issue a new ticket, and therefore does
+ not send a SessionTicket extension.
+
+ If the server rejects the ticket, it may still wish to issue a new
+ ticket after performing the full handshake as shown below (this flow
+ is identical to Figure 1, except the SessionTicket extension in the
+ ClientHello is not empty):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 6]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ Client Server
+
+ ClientHello
+ (SessionTicket extension) -------->
+ ServerHello
+ (empty SessionTicket extension)
+ Certificate*
+ ServerKeyExchange*
+ CertificateRequest*
+ <-------- ServerHelloDone
+ Certificate*
+ ClientKeyExchange
+ CertificateVerify*
+ [ChangeCipherSpec]
+ Finished -------->
+ NewSessionTicket
+ [ChangeCipherSpec]
+ <-------- Finished
+ Application Data <-------> Application Data
+
+ Figure 4: Message Flow for Server Rejecting Ticket, Performing Full
+ Handshake, and Issuing New Session Ticket
+
+3.2. SessionTicket TLS Extension
+
+ The SessionTicket TLS extension is based on [RFC4366]. 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 the ticket in the SessionTicket extension
+ in the ClientHello. If the client does not have a ticket and is
+ prepared to receive one in the NewSessionTicket 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
+ NewSessionTicket 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 a zero-length SessionTicket extension to indicate to
+ the client that it will send a new session ticket using the
+ NewSessionTicket handshake message described in Section 3.3. The
+ server MUST send this extension in the ServerHello if it wishes to
+ issue a new ticket to the client using the NewSessionTicket handshake
+ message. The server MUST NOT send this extension if it does not
+ receive one in the ClientHello.
+
+
+
+
+Salowey, et al. Standards Track [Page 7]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ 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 35. The
+ extension_data field of SessionTicket extension contains the ticket.
+
+3.3. NewSessionTicket 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. This message is included
+ in the hash used to create and verify the Finished message. 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 sends a zero-length ticket in the
+ NewSessionTicket handshake message.
+
+ If the server successfully verifies the client's ticket, then it MAY
+ renew the ticket by including a NewSessionTicket 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 that the client actually received the updated ticket until it
+ successfully verifies the client's Finished message.
+
+ The NewSessionTicket handshake message has been assigned the number 4
+ and its definition is given at the end of this section. The
+ 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
+ relative to when the ticket is received. 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.
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 8]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ 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: NewSessionTicket; /* NEW */
+ } body;
+ } Handshake;
+
+
+ struct {
+ uint32 ticket_lifetime_hint;
+ opaque ticket<0..2^16-1>;
+ } NewSessionTicket;
+
+3.4. Interaction with TLS Session ID
+
+ If a server is planning on issuing a session ticket to a client that
+ does not present one, it SHOULD include an empty Session ID in the
+ ServerHello. If the server rejects the ticket and falls back to the
+ full handshake then it may include a non-empty Session ID to indicate
+ its support for stateful session resumption. If the client receives
+ a session ticket 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 from when
+ it is 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 resumption.
+ 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. Standards Track [Page 9]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+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, and
+ 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 Advanced
+ Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode
+ [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634].
+
+ The ticket is structured as follows:
+
+ struct {
+ opaque key_name[16];
+ opaque iv[16];
+ opaque encrypted_state<0..2^16-1>;
+ opaque mac[32];
+ } ticket;
+
+ Here, key_name serves to identify a particular set of keys used to
+ protect the ticket. It enables the server to easily recognize
+ tickets it has issued. The key_name should be randomly generated to
+ avoid collisions between servers. One possibility is to generate new
+ random keys and key_name every time the server is started.
+
+ The actual state information in encrypted_state is encrypted using
+ 128-bit AES in CBC mode with the given IV. The Message
+ Authentication Code (MAC) is calculated using HMAC-SHA-256 over
+ key_name (16 octets) and IV (16 octets), followed by the length of
+ the encrypted_state field (2 octets) and its contents (variable
+ length).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 10]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ struct {
+ ProtocolVersion protocol_version;
+ CipherSuite cipher_suite;
+ CompressionMethod compression_method;
+ opaque master_secret[48];
+ ClientIdentity 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>; /* from [RFC4279] */
+ };
+ } 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 mechanisms, such as
+ Kerberos [RFC2712], would require different client identity data.
+ Other TLS extensions may require the inclusion of additional data in
+ the StatePlaintext structure.
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 11]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+5. Security Considerations
+
+ This section addresses security issues related to the usage of a
+ ticket. Tickets must be 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 service 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 within 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 that 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 it 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 ticket's 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 another user, or to
+ gain additional privileges. This attack is not possible if the
+ ticket is protected using a strong integrity protection algorithm
+ such as a keyed HMAC-SHA-256.
+
+5.4. Denial of Service Attacks
+
+ 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
+
+
+
+Salowey, et al. Standards Track [Page 12]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ 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 Management
+
+ A full description of the management of the keys used to protect the
+ ticket is beyond the scope of this document. A list of RECOMMENDED
+ practices is given below.
+
+ o The keys should be generated securely following the randomness
+ recommendations in [RFC4086].
+
+ o The keys and cryptographic protection algorithms should be at
+ least 128 bits in strength. Some ciphersuites and applications
+ may require cryptographic protection greater than 128 bits in
+ strength.
+
+ o The keys should not be used for any purpose other than generating
+ and verifying tickets.
+
+ o The keys should be changed regularly.
+
+ o The keys should be changed if the ticket format or cryptographic
+ protection algorithms change.
+
+5.6. Ticket Lifetime
+
+ The TLS server controls the lifetime of the ticket. Servers
+ determine the acceptable lifetime based on the operational and
+ security requirements of the environments in which they are deployed.
+ The ticket lifetime may be longer than the 24-hour lifetime
+ recommended in [RFC4346]. TLS clients may be given a hint of the
+ lifetime of the ticket. Since the lifetime of a ticket may be
+ unspecified, a client has its own local policy that 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 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
+ confidentiality protected with strong cryptographic techniques to
+ prevent a breach in the security of the system.
+
+
+
+Salowey, et al. Standards Track [Page 13]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+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, therefore concluding 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. Acknowledgements
+
+ 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, 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
+ 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. [RFC4851] makes use of a similar
+ mechanism to avoid maintaining server state for the cryptographic
+ tunnel. [SC97] also investigates the concept of stateless sessions.
+
+ The authors would also like to thank Jan Nordqvist, who found the
+ encoding error in RFC 4507, corrected by this document. In addition
+ Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico provided
+ useful feedback during the review of this document.
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 14]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+7. IANA Considerations
+
+ IANA has assigned a TLS extension number of 35 to the SessionTicket
+ TLS extension from the TLS registry of ExtensionType values defined
+ in [RFC4366].
+
+ IANA has assigned a TLS HandshakeType number 4 to the
+ NewSessionTicket handshake type from the TLS registry of
+ HandshakeType values defined in [RFC4346].
+
+ This document does not require any actions or assignments from IANA.
+
+8. References
+
+8.1. Normative References
+
+ [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.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+ [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+ and T. Wright, "Transport Layer Security (TLS)
+ Extensions", RFC 4366, April 2006.
+
+ [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+ "Transport Layer Security (TLS) Session Resumption without
+ Server-Side State", RFC 4507, May 2006.
+
+8.2. Informative References
+
+ [AES] National Institute of Standards and Technology, "Advanced
+ Encryption Standard (AES)", Federal Information Processing
+ Standards (FIPS) Publication 197, 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 Version 0.26, December 2005.
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 15]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ [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.
+
+ [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
+ Suites to Transport Layer Security (TLS)", RFC 2712,
+ 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
+ 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.
+
+ [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
+ (SHA and HMAC-SHA)", RFC 4634, July 2006.
+
+ [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
+ Flexible Authentication via Secure Tunneling Extensible
+ Authentication Protocol Method (EAP-FAST)", RFC 4851,
+ May 2007.
+
+ [SC97] Aura, T. and P. Nikander, "Stateless Connections",
+ Proceedings of the First International Conference on
+ Information and Communication Security (ICICS '97) , 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 16]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+Appendix A. Discussion of Changes to RFC 4507
+
+ RFC 4507 [RFC4507] defines a mechanism to resume a TLS session
+ without maintaining server side state by specifying an encrypted
+ ticket that is maintained on the client. The client presents this
+ ticket to the server in a SessionTicket hello extension. The
+ encoding in RFC 4507 used the XDR style encoding specified in TLS
+ [RFC4346].
+
+ An error in the encoding 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 these currently
+ deployed implementations.
+
+ Erroneous encoding in RFC 4507 resulted in two length fields; one for
+ the extension contents and one for the ticket itself. Hence, for a
+ ticket that is 256 bytes long and begins with the hex value FF FF,
+ the encoding of the extension would be as follows according to RFC
+ 4507:
+
+ 00 23 Ticket Extension type 35
+ 01 02 Length of extension contents
+ 01 00 Length of ticket
+ FF FF .. .. Actual ticket
+
+ The update proposed in this document reflects what implementations
+ actually encode, namely it removes the redundant length field. So,
+ for a ticket that is 256 bytes long and begins with the hex value FF
+ FF, the encoding of the extension would be as follows according to
+ this update:
+
+ 00 23 Extension type 35
+ 01 00 Length of extension contents (ticket)
+ FF FF .. .. Actual ticket
+
+ A server implemented according to RFC 4507 receiving a ticket
+ extension from a client conforming to this document would interpret
+ the first two bytes of the ticket as the length of this ticket. This
+ will result in either an inconsistent length field or in the
+ processing of a ticket missing the first two bytes. In the first
+ case, the server should reject the request based on a malformed
+ length. In the second case, the server should reject the ticket
+ based on a malformed ticket, incorrect key version, or failed
+ decryption. A server implementation based on this update receiving
+ an RFC 4507 extension would interpret the first length field as the
+
+
+
+
+
+Salowey, et al. Standards Track [Page 17]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+ length of the ticket and include the second two length bytes as the
+ first bytes in the ticket, resulting in the ticket being rejected
+ based on a malformed ticket, incorrect key version, or failed
+ decryption.
+
+ Note that the encoding of an empty SessionTicket extension was
+ ambiguous in RFC 4507. An RFC 4507 implementation may have encoded
+ it as:
+
+ 00 23 Extension type 35
+ 00 02 Length of extension contents
+ 00 00 Length of ticket
+
+ or it may have encoded it the same way as this update:
+
+ 00 23 Extension type 35
+ 00 00 Length of extension contents
+
+ A server wishing to support RFC 4507 clients should respond to an
+ empty SessionTicket extension encoded the same way as it received it.
+
+ A server implementation can construct tickets such that it can detect
+ an RFC 4507 implementation, if one existed, by including a cookie at
+ the beginning of the tickets that can be differentiated from a valid
+ length. For example, if an implementation constructed tickets to
+ start with the hex values FF FF, then it could determine where the
+ ticket begins and determine the length correctly from the type of
+ length fields present.
+
+ This document makes a few additional changes to RFC 4507 listed
+ below.
+
+ o Clarifying that the server can allow session resumption using a
+ ticket without issuing a new ticket in Section 3.1.
+
+ o Clarifying that the lifetime is relative to when the ticket is
+ received in section 3.3.
+
+ o Clarifying that the NewSessionTicket handshake message is included
+ in the hash generated for the Finished messages in Section 3.3.
+
+ o Clarifying the interaction with TLS Session ID in Section 3.4.
+
+ o Recommending the use of SHA-256 for the integrity protection of
+ the ticket in Section 4.
+
+ o Clarifying that additional data can be included in the
+ StatePlaintext structure in Section 4.
+
+
+
+Salowey, et al. Standards Track [Page 18]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+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
+ Nokia Siemens Networks
+ Otto-Hahn-Ring 6
+ Munich, Bayern 81739
+ Germany
+
+ EMail: Hannes.Tschofenig@nsn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 19]
+
+RFC 5077 Stateless TLS Session Resumption January 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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.
+
+ 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, THE IETF TRUST 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.
+
+Intellectual Property
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Standards Track [Page 20]
+