--- /dev/null
+
+
+
+Network Working Group J. Salowey
+Internet-Draft H. Zhou
+Expires: February 2, 2006 Cisco Systems
+ P. Eronen
+ Nokia
+ H. Tschofenig
+ Siemens
+ August 2005
+
+
+ Transport Layer Security Session Resumption without Server-Side State
+ draft-salowey-tls-ticket-04.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 February 2, 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 February 2, 2006 [Page 1]
+\f
+Internet-Draft Stateless TLS Session Resumption August 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 . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
+ Intellectual Property and Copyright Statements . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Expires February 2, 2006 [Page 2]
+\f
+Internet-Draft Stateless TLS Session Resumption August 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 [I-D.ietf-tls-
+ rfc3546bis] and defines a new TLS message type.
+
+ This mechanism is useful in the following types of situations
+ (1) servers that handle a large number of transactions from
+ different users
+ (2) servers that desire to cache sessions for a long time
+ (3) ability to load balance requests across servers
+ (4) embedded servers with little memory
+
+2. Terminology
+
+ Within this document the term 'ticket' refers to a cryptographically
+ protected data structure which is created by the server and consumed
+ by the server to rebuild session specific state.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Protocol
+
+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.
+
+ 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 February 2, 2006 [Page 3]
+\f
+Internet-Draft Stateless TLS Session Resumption August 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 February 2, 2006 [Page 4]
+\f
+Internet-Draft Stateless TLS Session Resumption August 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;
+
+ The SessionTicket extension has been assigned the number TBD1.
+
+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;
+
+ The NewSessionTicket handshake message has been assigned the number
+
+
+
+Salowey, et al. Expires February 2, 2006 [Page 5]
+\f
+Internet-Draft Stateless TLS Session Resumption August 2005
+
+
+ TBD2.
+
+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 February 2, 2006 [Page 6]
+\f
+Internet-Draft Stateless TLS Session Resumption August 2005
+
+
+ struct {
+ ProtocolVersion protocol_version;
+ SessionID session_id;
+ CipherSuite cipher_suite;
+ CompressionMethod compression_method;
+ opaque master_secret[48];
+ ExampleClientIdentity 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 February 2, 2006 [Page 7]
+\f
+Internet-Draft Stateless TLS Session Resumption August 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 February 2, 2006 [Page 8]
+\f
+Internet-Draft Stateless TLS Session Resumption August 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
+
+ IANA has assigned a TLS extension number of TBD1 (the value 35 is
+ suggested) to the SessionTicket TLS extension from the TLS registry
+ of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
+
+ IANA has assigned a TLS HandshakeType number TBD2 to the
+ NewSessionTicket handshake type from the TLS registry of
+ HandshakeType values defined in [I-D.ietf-tls-rfc2246-bis].
+
+8. References
+
+8.1 Normative References
+
+ [I-D.ietf-tls-rfc2246-bis]
+ Dierks, T. and E. Rescorla, "The TLS Protocol Version
+ 1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
+ June 2005.
+
+ [I-D.ietf-tls-rfc3546bis]
+ Blake-Wilson, S., "Transport Layer Security (TLS)
+ Extensions", draft-ietf-tls-rfc3546bis-01 (work in
+ progress), May 2005.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Salowey, et al. Expires February 2, 2006 [Page 9]
+\f
+Internet-Draft Stateless TLS Session Resumption August 2005
+
+
+ [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+8.2 Informative References
+
+ [AURA97] Aura, T. and P. Nikander, "Stateless Connections",
+ Proceedings of the First International Conference on
+ Information and Communication Security (ICICS '97) , 1997.
+
+ [CSSC] Shacham, H., Boneh, D., and E. Rescorla, "Client Side
+ Caching for TLS",
+ URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf.
+
+ [I-D.cam-winget-eap-fast]
+ Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP
+ Flexible Authentication via Secure Tunneling (EAP-FAST)",
+ draft-cam-winget-eap-fast-02 (work in progress),
+ April 2005.
+
+ [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
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Expires February 2, 2006 [Page 10]
+\f
+Internet-Draft Stateless TLS Session Resumption August 2005
+
+
+ Hao Zhou
+ Cisco Systems
+ 4125 Highlander Parkway
+ Richfield, OH 44286
+ US
+
+ Email: hzhou@cisco.com
+
+
+ Pasi Eronen
+ Nokia Research Center
+ P.O. Box 407
+ FIN-00045 Nokia Group
+ Finland
+
+ Email: pasi.eronen@nokia.com
+
+
+ Hannes Tschofenig
+ Siemens
+ Otto-Hahn-Ring 6
+ Munich, Bayern 81739
+ Germany
+
+ Email: Hannes.Tschofenig@siemens.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Salowey, et al. Expires February 2, 2006 [Page 11]
+\f
+Internet-Draft Stateless TLS Session Resumption August 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 February 2, 2006 [Page 12]
+\f
projects / thirdparty / gnutls.git / commitdiff
