Network Working Group J. Salowey Internet-Draft H. Zhou Expires: January 16, 2006 Cisco Systems P. Eronen Nokia H. Tschofenig Siemens July 15, 2005 Transport Layer Security Session Resumption without Server-Side State draft-salowey-tls-ticket-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a mechanism which enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently Salowey, et al. Expires January 16, 2006 [Page 1] Internet-Draft Stateless TLS Session Resumption July 2005 resume a session using the obtained ticket. This mechanism makes use of new TLS handshake messages and TLS hello extensions. 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 . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.1 Invalidating Sessions . . . . . . . . . . . . . . . . . . 8 5.2 Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 8 5.4 Denial of Service Attacks . . . . . . . . . . . . . . . . 8 5.5 Ticket Protection Key Lifetime . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . 12 Salowey, et al. Expires January 16, 2006 [Page 2] Internet-Draft Stateless TLS Session Resumption July 2005 1. Introduction This document defines a way to resume a Transport Layer Security (TLS) [RFC2246]session without requiring session-specific state at the TLS server. This mechanism may be used with any TLS ciphersuite. The mechanism makes use of TLS extensions defined in [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 cryptographically protected data structure which is created by the server and consumed by the server to rebuild session specific state. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Protocol 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. The ticket is distributed to the client using the NewSessionTicket TLS handshake message. This message is sent during the TLS handshake before the ChangeCipherSpec message after the server has verified the client's Finished message. Salowey, et al. Expires January 16, 2006 [Page 3] Internet-Draft Stateless TLS Session Resumption July 2005 Client Server ClientHello --------> (empty SessionTicket extension) ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> NewSessionTicket [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data The client caches this ticket along with the master secret, session ID and other parameters associated with the current session. When the client wishes to resume the session, it includes a SessionTicket TLS extension in the SessionTicket extension within ClientHello message. The server then verifies that the ticket has not been tampered with, decrypts the contents, and retrieves the session state from the contents of the ticket and uses this state to resume the session. Since separate fields in the request are used for the session ID and the ticket standard stateful session resume can co- exist with the ticket based session resume described in this specification. ClientHello (SessionTicket extension) --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data Since the ticket is typically interpreted by the same server or group of servers 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. Salowey, et al. Expires January 16, 2006 [Page 4] Internet-Draft Stateless TLS Session Resumption July 2005 It is possible that the session ticket 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. 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 is sent during the TLS handshake before the ChangeCipherSpec message after the server has verified the client's Finished message. 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; Salowey, et al. Expires January 16, 2006 [Page 5] Internet-Draft Stateless TLS Session Resumption July 2005 4. Sample ticket construction This section describes one possibility how the ticket could be constructed, other implementations are possible. 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). Salowey, et al. Expires January 16, 2006 [Page 6] Internet-Draft Stateless TLS Session Resumption July 2005 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), psk(2) } ExampleClientAuthenticationType; struct { ExampleClientAuthenticationType client_authentication_type; select (ExampleClientAuthenticationType) { case anonymous: struct {}; case certificate_based: ASN.1Cert certificate_list<0..2^24-1>; case psk: opaque psk_identity<0..2^16-1>; } } ExampleClientIdentity; The structure ExampleStatePlaintext stores the TLS session state including the SessionID and 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 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 choose to store a subset of this information. Other authentication mechanism such as Kerberos [RFC2712] or pre-shared keys [I-D.ietf-tls-psk] 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 Salowey, et al. Expires January 16, 2006 [Page 7] Internet-Draft Stateless TLS Session Resumption July 2005 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 Invalidating Sessions The TLS specification requires that TLS sessions be invalidated when errors occur. [CSSC] discusses the security implications of this in detail. In the analysis in this paper, failure to invalidate sessions does not pose a security risk. This is because the TLS handshake uses a non-reversible function to derive keys for a session so information about one session does not provide an advantage to attack the master secret or a different session. If a session invalidation scheme is used the implementation should verify the integrity of the ticket before using the contents to invalidate a session to ensure an attacker cannot invalidate a chosen session. 5.2 Stolen Tickets An eavesdropper or man-in-the-middle may obtain the ticket and attempt to use the ticket to establish a session with the server, however since the ticket is encrypted and the attacker does not know the secret key a stolen key does not help an attacker resume a session. A TLS server MUST use strong encryption and integrity protection for the ticket to prevent an attacker from using a brute force mechanism to obtain the tickets contents. 5.3 Forged Tickets A malicious user could forge or alter a ticket in order to resume a session, to extend its lifetime, to impersonate as another user or gain additional privileges. This attack is not possible if the ticket is protected using a strong integrity protection algorithm such as a keyed HMAC. 5.4 Denial of Service Attacks An adversary could store or forge a large number of tickets to send to the TLS server for verification. To minimize the possibility of a denial of service the verification of the ticket should be lightweight (e.g., using efficient symmetric key cryptographic algorithms). Salowey, et al. Expires January 16, 2006 [Page 8] Internet-Draft Stateless TLS Session Resumption July 2005 5.5 Ticket Protection Key Lifetime The management of the keys used to protect the ticket is beyond the scope of this document. It is advisable to limit the lifetime of these keys to ensure they are not overused. 6. Acknowledgments The authors would like to thank the following people for their help with this document: Eric Rescorla, Mohamad Badra, 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. [I-D.cam-winget-eap-fast] makes use of a similar mechanism to avoid maintaining 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. 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", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. 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 Salowey, et al. Expires January 16, 2006 [Page 9] Internet-Draft Stateless TLS Session Resumption July 2005 Caching for TLS", URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf, 2002. [I-D.cam-winget-eap-fast] Salowey, J., "EAP Flexible Authentication via Secure Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-02 (work in progress), April 2005. [I-D.ietf-tls-psk] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", draft-ietf-tls-psk-09 (work in progress), June 2005. [RFC1510] Kohl, J. and B. 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. 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 Salowey, et al. Expires January 16, 2006 [Page 10] Internet-Draft Stateless TLS Session Resumption July 2005 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 January 16, 2006 [Page 11] Internet-Draft Stateless TLS Session Resumption July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Salowey, et al. Expires January 16, 2006 [Page 12]