TLS Working Group Hovav Shacham, Stanford INTERNET-DRAFT Dan Boneh, Stanford September 9, 2001 Expires March 9, 2002 TLS Fast-Track Session Establishment Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines a new, "fast-track" handshake mechanism for TLS. A fast-track client caches a server's public parameters and negotiated parameters in the course of an initial, enabling handshake; these need not be resent on subsequent ones. The new mechanism reduces both network traffic and flows, and requires no additional server state. A rollback mechanism is included to allow a server gracefully to revert to an ordinary TLS handshake. Moreover, care is taken that fast-track clients not confuse servers unaware of fast-track. Shacham and Boneh Expires: March 2002 [Page 1] INTERNET DRAFT TLS Fast-Track September 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 2. New Extensions . . . . . . . . . . . . . . . . . . . . . . 3 2.1. The fasttrack_capable Extension . . . . . . . . . . . . . 4 2.2. The fasttrack_hash Extension . . . . . . . . . . . . . . . 4 3. New Message Types . . . . . . . . . . . . . . . . . . . . 4 4. Determination of Fast-Track Capability . . . . . . . . . . 5 4.1. Determining Parameters . . . . . . . . . . . . . . . . . . 5 5. The Fast-Track Handshake . . . . . . . . . . . . . . . . . 7 5.1. The Client Fast-Track Hello . . . . . . . . . . . . . . . 8 5.2. The Client Certificate . . . . . . . . . . . . . . . . . . 9 5.3. Client Key Exchange . . . . . . . . . . . . . . . . . . . 9 5.4. Server Response . . . . . . . . . . . . . . . . . . . . . 9 5.4.1. Fast-track Accept . . . . . . . . . . . . . . . . . . . 10 5.4.2. Fast-track Deny . . . . . . . . . . . . . . . . . . . . 10 5.4.3. Session Resume with Fast-track Deny . . . . . . . . . . 10 5.5 Server Key Exchange . . . . . . . . . . . . . . . . . . 10 5.6 Server Finished . . . . . . . . . . . . . . . . . . . . 11 5.7 Client Certificate Verify . . . . . . . . . . . . . . . 11 5.8 Client Finished . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . 12 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . 13 1. Introduction The TLS protocol [TLS] incorporates a mechanism for session resumption. Compared to an ordinary handshake, this mechanism significantly reduces handshake network traffic and computation on both ends. Unfortunately, session resumption relies on a server session cache; heavily-loaded servers cannot store cached sessions indefinitely. By contrast, clients rarely connect to numerous TLS servers, and could cache information about servers for a longer time. Fast-track session establishment is a new handshake mechanism for TLS that exploits this situation. Some server public parameters change infrequently and may be cached. These include: * the server certificate chain; * the server's Diffie-Hellman group (if any) for EDH key exchange; and Shacham and Boneh Expires: March 2002 [Page 2] INTERNET DRAFT TLS Fast-Track September 2001 * whether the server requests client authentication; if so, what client certificate types and certificate authorities the server is willing to accept; Moreover, some parameters depend on both the client and server configuration, are negotiated between the two, but change infrequently. These include: * preferred client-server cipher suite; and * preferred client-server compression method. All these items are cached by the client, and need not be retransmitted in a fast-track handshake. The server Certificate, CertificateRequest, and HelloDone messages are omitted from the handshake, saving bandwidth. Moreover, the handshake messages are rearranged, reducing the total number of flows. The savings can be significant, especially for wireless, bandwidth-limited devices. Through the use of TLS extensions [Ext], a client and server can, in an ordinary TLS handshake, negotiate the future use of fast-track. A subsequent fast-track connection uses an extension to allow the client and server to ascertain their both using the same unsent, client-cached parameters. A rollback mechanism is included to allow a server gracefully to revert to an ordinary TLS handshake. Finally, care is taken that fast-track clients not confuse servers unaware of fast-track. 1.1. Specification of Requirements 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 RFC 2119 [WORDS]. 2. New Extensions This document suggests the use of two additional extension types, per the TLS Extensions document [Ext]. One, fasttrack_capable, is for negotiating future use of FT; the other, fasttrack_hash, is for initiating an actual handshake. The ExtensionType type ([Ext], Sect. 2.3) is modified accordingly: enum { dns_name(0), max_record_size(1), client_certificate_url(2), trusted_ca_keys(3), truncated_hmac(4), status_request(5), fasttrack_capable(6), fasttrack_hash(7), (65535) } ExtensionType; Shacham and Boneh Expires: March 2002 [Page 3] INTERNET DRAFT TLS Fast-Track September 2001 2.1. The fasttrack_capable Extension The extension_data field of the fasttrack_capable extension shall be empty. 2.2. The fasttrack_hash Extension The extension_data field of the fasttrack_hash extension, when sent by a client, shall contain a SHA-1 hash [SHA] of the fast-track determining parameters (Sect. 4.1). opaque sha_hash[20] SHA(FTDetParams); Only ClientHelloFT messages may include the fasttrack_hash extension. 3. New Message Types This document suggests the use of two new handshake message types, ClientHelloFT and ServerHelloFT. These shall have the same body as ClientHello and ServerHello, respectively. The HandshakeType and Handshake definitions of the TLS Extensions document ([Ext], Sect. 2.4) are further amended: enum { hello_request(0), client_hello(1), server_hello(2), client_hello_ft(3), server_hello_ft(4), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), certificate_url(21), ocsp_response(22), (255) } HandshakeType; struct { HandshakeType msg_type; /* handshake type */ uint24 length; /* bytes in message */ select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case client_hello_ft: ClientHello; case server_hello_ft: 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 certificate_url: CertificateURL; Shacham and Boneh Expires: March 2002 [Page 4] INTERNET DRAFT TLS Fast-Track September 2001 case ocsp_response: CertificateAndOCSPResponse; } body; } Handshake; 4. Determination of Fast-Track Capability Fast-track session establishment requires that the client obtain and store server parameters and negotiated parameters. Moreover, fast-track session establishment should not be attempted with servers unaware of or unwilling to participate in the same. Accordingly, fast-track proposes a determination mechanism, by which an ordinary TLS handshake allows the client and server to negotiate the (future) use of fast-track, and the client to collect the information it will requre for that future use. In establishing a session with a server, a client MAY include the fasttrack_capable extension in the ClientHello (or ClientHelloFT) message. The server MAY then include the fasttrack_capable extension in the ServerHello (or ServerHelloFT) message assenting to the use of fast-track in future handshakes with that client. An enabling handshake for fast-track is a successful TLS handshake in which the both the ClientHello (or ClientHelloFT) and the ServerHello (or ServerHelloFT) messages include the fasttrack_capable extension. Any other handshake is non-enabling. Note that extensions are ignored in session-resume handshakes, so these are implicitly enabling whenever the resumed connection's handshake was. The determining parameters for a fast-track handshake are those of the most recent enabling handshake between the two parties. A client MUST NOT attempt a fast-track handshake with a server unless the most recent hanshake between the two had been an enabling one. The most recent enabling handshake is thus the determining handshake for any fast-track connection. The RSA_EXPORT key-exchange algorithm with a server public key longer than 512 bits is explicitly not supported by fast-track. If it includes the fasttrack_capable extension in its hello message, a client MUST NOT include any suite employing RSA_EXPORT in the cipher_suites field. 4.1. Determining Parameters A client participating in an enabling handshake should note the fast-track determining parameters: struct { opaque dh_p<1..2^16-1>; opaque dh_g<1..2^16-1>; } ServerLongLivedDHParams; Shacham and Boneh Expires: March 2002 [Page 5] INTERNET DRAFT TLS Fast-Track September 2001 dh_p The prime modulus used for the Diffie-Hellman operation. dh_g The generator used for the Diffie-Hellman operation. Note: Fast-track authentication assumes that the server changes its Diffie-Hellman group infrequently. struct { CipherSuite cipher_suite; CompressionMethod compression_method; Certificate server_certs; select (KeyExchangeAlgorithm) { case diffie_hellman: ServerLongLivedDHParams llparams; case rsa: struct { }; }; ClientCertificateType certificate_types<0..2^8-1>; DistinguishedName certificate_authorities<0..2^16-1>; } FTDetParams; cipher_suite The cipher suite on which the client and server agree ([TLS], Sect. 7.4.1.3). compression_method The compression method on which the client and server agree ([TLS], Sect. 7.4.1.3). server_certs The server's certificate chain ([TLS], Sect. 7.4.2). llparams The server's long-lived Diffie-Hellman parameters, if Diffie-Hellman key exchange is employed ([TLS], Sect. 7.4.3). certificate_types The certificate types the server requests or empty if the server does not request a client certificate ([TLS], Sect. 7.4.4) certificate_authorities The distinguished names of certificate authorities acceptable to the server, or empty if the server does not request a client certificate ([TLS], Sect. 7.4.4) A hash of this information is submitted to the server in a fast-track handshake, using the fasttrack_hash extension (Sect. 2.2). Shacham and Boneh Expires: March 2002 [Page 6] INTERNET DRAFT TLS Fast-Track September 2001 In an attempted fast-track handshake with a server, a client MUST employ the determining parameters from the determining handshake: its most recent enabling handshake with that server. 5. The Fast-Track Handshake In a fast-track handshake, a client assumes that its handshake with a server will reuse the fast-track determining parameters negotiated in an earlier, enabling (Sect. 4). It sends a ClientHelloFT message (Sect. 5.1) with a fasttrack_hash extension, Note: In a fast-track handshake, clients send messages in an order different from that in a normal handshake. The ClientHelloFT message type is intended to allow servers not supporting fast-track to notify the client of this fact more expeditiously. The server may accept the fast-track handshake attempt by replying with a ServerHelloFT message, or it may refuse by replying with a ServerHello message. The message flow for a successful fast-track handshake is summarized in Figure 1, below, using the same notational conventions as in the TLS specification ([TLS], Sect. 7.3). Client Server ClientHelloFT Certificate* ClientKeyExchange --------> ServerHelloFT ServerKeyExchange* [ChangeCipherSpec] <-------- Finished CertificateVerify* [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data Fig. 1 - Message flow for a fast-track handshake When a server chooses to deny a fast-track handshake, it replies with a ServerHello message; the exchange reverts to a standard TLS handshake. The message flow is summarized in Figure 2, below. In this and the next figure, tildes indicate those messages not included in authenticating hashes. Client Server ClientHelloFT Certificate*~ ClientKeyExchange~ --------> Shacham and Boneh Expires: March 2002 [Page 7] INTERNET DRAFT TLS Fast-Track September 2001 ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Fig. 2 - Message flow for a denied fast-track handshake A server may resume a previous session, if it wishes, by denying the fast-track handshake, sending a ServerHello with the same session ID as in the ClientHelloFT message; the exchange reverts to a standard TLS session-resume handshake. The message flow is summarize in Figure 3, below. Client Server ClientHelloFT Certificate*~ ClientKeyExchange~ --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data Fig. 3 - Message flow for a fast-track handshake resume 5.1. The Client Fast-Track Hello A client initiates a fast-track handshake by sending a ClientHelloFT message. This message has the same structure as a ClientHello message, but a different message type. The cipher_suites and compression_methods fields SHOULD be the same as those in the ClientHello (or ClientHelloFT) message of the client's determining handshake with the server. The client SHOULD include the fasttrack_capable extension in its ClientHelloFT message. The handshake is a determining handshake if the server also includes the fasttrack_capable extension in its ServerHello or ServerHelloFT message, and non-determining otherwise (Sect. 4). Shacham and Boneh Expires: March 2002 [Page 8] INTERNET DRAFT TLS Fast-Track September 2001 The client MUST include the fasttrack_hash extension in its ClientHelloFT message. The extension_data field of this message must include the SHA-1 hash of the FTDetParams structure containing the parameters being assumed by the client for this fast-track handshake attempt (Sect. 2.2). The server should use the contents of the ClientHelloFT message, along with its own configuration, to find the fast-track determining parameters for the connection. It should then check the SHA-1 hash of these values (in an FTDetParams structure) against the hash in the ClientHelloFT message's fasttrack_hash extension. If it encounters a mismatch, the server may, at its option, either abort the connection with an alert, or, in its response (Sect. 5.4), deny fast-track and proceed to a standard TLS handshake. 5.2. The Client Certificate This message is the same as the ClientCertificate message in standard TLS handshakes ([TLS], Sect. 7.4.6). This message is sent if and only if, in the determining handshake, the server required client authentication (i.e., if and only if the certificate_types and certificate_authorities fields of FTDetParams are both non-empty). If it is required, the ClientCertificate message must be sent immediately after the ClientHelloFT message. 5.3. Client Key Exchange This message is the same as the ClientCertificate message in standard TLS handshakes ([TLS], Sect. 7.4.6). It must always be sent immediately after the ClientCertificate message, if it is sent, or the ClientHelloFT message otherwise. The server should interpret the contents of this message using the connection's determining parameters. 5.4. Server Response The server responds with a server hello message after the ClientKeyExchange message. It may respond with a ServerHelloFT message, accepting the fast-track connection, or with a ServerHello message, denying the fast-track and reverting to an ordinary TLS handshake. It MUST NOT accept the fast-track connection, however, if the FTDetParams hash check (Sect. 5.1) has failed. Shacham and Boneh Expires: March 2002 [Page 9] INTERNET DRAFT TLS Fast-Track September 2001 5.4.1. Fast-track Accept A server accepts the fast-track handshake by replying, after the ClientKeyExchange message, with a ServerHelloFT message. The cipher_suite and compression_method fields of this message MUST be the same as in the determining parameters of the fast-track connection. 5.4.2. Fast-track Deny A server chooses to deny the fast-track handshake by replying, after the ClientKeyExchange message, with a ServerHello message. The server should respond as it would have had the client initiated the handshake with a ClientHello message containing containing the same parameters as its actual ClientHelloFT message, without the fasttrack_hash extension. The client and server then proceed with a standard TLS handshake ([TLS], Sect. 7.4), rather than the fast-track handshake. Both the client Certificate (if sent) and ClientKeyExchange messages sent before the server's denying ServerHello MUST be omitted from any handshake digests that follow; in particular, the digests in the client and server done messages, and the the client certificate verify message. 5.4.3. Session Resume with Fast-Track Deny If the ClientHelloFT.session_id is non-empty, and the server wishes to resume the session so named, it may deny the fast-track handshake by replying with a ServerHello message, whose session_id field equals that of the ClientHelloFT message. The client and server then proceed with a standard TLS session resume ([TLS], Sect. 7.4), rather than the fast-track handshake. Again, both the client Certificate (if sent) and the ClientKeyExchange messages sent before the ServerHello MUST be omitted from any handshake digests that follow. 5.5 Server Key Exchange This message is the same as the ClientCertificate message in standard TLS handshakes ([TLS], Sect. 7.4.6). It must be sent under the same conditions that require a ServerKeyExchange message to be sent in a standard TLS handshake ([TLS], Sect. 7.4.3). If it the ServerKeyExchange message is sent, it must be sent immediately after the ServerHelloFT message. Shacham and Boneh Expires: March 2002 [Page 10] INTERNET DRAFT TLS Fast-Track September 2001 5.6 Server Finished The ServerKeyExchange message, if sent, or the ServerHelloFT message otherwise, must be followed by a ChangeCipherSpec message. The ChangeCipherSpec message must then be followed by a ServerFinished message, whose contents are the same as in a standard TLS handshake ([TLS], Sect. 7.4.9). 5.7 Client Certificate Verify The CertificateVerify message is sent only when a client certificate with signing capability was sent earlier in the exchange. If sent, the message must immediately follow the ServerFinished message The CertificateVerify message's contents are the same as in a standard TLS handshake ([TLS], Sect. 7.4.8); but the handshake_messages digest must include all handshake-layer messages exchanged up to, but not including, the ServerFinished message. 5.8 Client Finished The client CertificateVerify message, if sent, or the ServerFinished message otherwise, must be followed by a client ChangeCipherSpec message. The ChangeCipherSpec message must then be followed by a ClientFinished message, whose contents are the same as in a standard TLS handshake ([TLS], Sect. 7.4.9). 6. IANA Considerations This document defines two new TLS extension types and two new TLS handshake message types. Per the IANA Considerations document [IANA], these assignments will require IANA review. However, the TLS specification [TLS] does not define a IANA policy for TLS namespaces. 7. Security Considerations The security considerations discussed below are in addition to those addressed in the TLS specification [TLS] and the TLS Extensions document [Ext]. The negotiation of fast-track capability using the fasttrack_capable extension in the course of an ordinary TLS handshake is protected by the handshake hashes; no additional security impact is believed to exist. Shacham and Boneh Expires: March 2002 [Page 11] INTERNET DRAFT TLS Fast-Track September 2001 A SHA-1 hash alone is used for determining parameter verification (Sect. 2.2). This is believed to be sufficient for the same reasons that the Extensions document gives in discussing security of the client_certificate_url hash ([Ext], Sect. 6.3): the client and server can both detect misunderstandings, so collision-resistance is all that is required. All the same information exchanged in a standard handshake is exchanged in a fast-track handshake, except for the determining parameters, for which a cryptographic hash is exchanged. The handshake hashes in the finished messages should thus provide the same security as in ordinary TLS. The server Finished message precedes the client Finished message, but this is the order in ordinary session-resumptions. The server response message (ServerHello or ServerHelloFT) is included in the final hashes regardless of whether fast-track is denied, so rollback attacks should be impossible. The only message not verified by both the client and server finished-message hashes is the client CertificateVerify message. It is included in the client finished-message hash, so the server should be able to detect its having been modified and abort the connection. In any case, the client certificate itself is included in both finished-message hashes, and is presumably no more open to tampering than in an ordinary TLS handshake. The client CertificateVerify message contains only a signature with the certificate's key, so opportunities for mischief through its modification are limited. For a detailed analysis, see the paper by Boneh and Shacham [Paper]. 8. References [Ext] Blake-Wilson, S., et al., "TLS Extensions", Internet-Draft: draft-ietf-tls-extensions-00.txt, June 2001. [IANA] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [Paper] Boneh, D. and H. Shacham, "A Fast-Track Session Establishment Mechanism for TLS", submitted. [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, Work in Progress, May 31, 1994. Shacham and Boneh Expires: March 2002 [Page 12] INTERNET DRAFT TLS Fast-Track September 2001 [TLS] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999. [WORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", IETF RFC 2119, March 1997. 9. Authors' Addresses Hovav Shacham Stanford University Department of Computer Science Stanford, CA 94305, USA hovav@cs.stanford.edu Dan Boneh Stanford University Department of Computer Science Stanford, CA 94305, USA dabo@cs.stanford.edu Shacham and Boneh Expires: March 2002 [Page 13]