TLS Working Group Grigorij Chudov Internet Draft CRYPTO-PRO Expires November 25, 2005 May 25, 2005 Intended Category: Standards Track Hash/PRF negotiation in TLS using TLS extensions. Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 in November 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document presents a method of negotiating some of the algorithms, used by Transport Layer Security Protocol [TLS], which are not chosen by cipher suite. Those algorithms are hash function used for Finished message, and PRF function. Chudov Informational [Page 1] Internet-Draft Hash/PRF negotiation in TLS May 2005 This is done using TLS Extensions [TLSEXT] mechanism. Table of Contents 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 2 Extension Type. . . . . . . . . . . . . . . . . . . . . . 2 3 Changes to the Message Contents . . . . . . . . . . . . . 3 3.1 Client Hello. . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Server Hello. . . . . . . . . . . . . . . . . . . . . . . 4 4 Cryptographic computations affected . . . . . . . . . . . 4 4.1 Finished message verify_data calculation. . . . . . . . . 5 4.2 Key calculation . . . . . . . . . . . . . . . . . . . . . 5 4.3 Computing the master secret . . . . . . . . . . . . . . . 5 5 Security Considerations . . . . . . . . . . . . . . . . . 5 6 References. . . . . . . . . . . . . . . . . . . . . . . . 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 6 1 Introduction [TLS] Handshake Protocol negotiates a cipher suite, that is used to provide connection security. A cipher suite specifies key agreement mechanism, symmetric encryption and MAC calculation, however it does not affect the hash algorithm and PRF, which are used during handshake. However, some applications require different PRF or hash function. For example, [PSK] (Pre-Shared Key Ciphersuites) have the following problem with PRF, used by [TLS]: PRF assumes a long random secret, which can be split in two independent parts, which usually not the case for PSK. The second example are [GOST] algorithms, which require a different hash-function. This document is intended to register a new TLS extension, using mechanism, defined in [TLSEXT]. The purpose of this extension is to allow hash and PRF algorithm negotiation. This document uses the same notation used in the [TLS] Protocol specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in Chudov Informational [Page 2] Internet-Draft Hash/PRF negotiation in TLS May 2005 this document are to be interpreted as described in [RFC 2119]. 2 Extension Type A new value, "prf_alg(9)", is added to the enumerated ExtensionType, defined in [TLSEXT]. This value is used as the extension number for the extensions in both the client hello message and the server hello message. This new extension type will be used for hash and PRF algorithm negotiation. The client enumerates supported algorithm combinations by including the appropriate extension in its ClientHello message. By echoing that extension in its ServerHello, the server selects one of them for this TLS connection. Section 3 describes the structure of this extension in further details. 3 Changes to the Message Contents This section describes the changes to the TLS handshake message contents when prf_alg extension is present. 3.1 Client Hello In order to indicate the support of alternative hash and PRF algorithms clients will include an extension of type "prf_alg" in the extended client hello message. The general extension mechanism is described in [TLSEXT]. This extension carries a list of hash/PRF algorithm pairs client can use. The opaque extension_data field contains DER-encoding of the TLSExtensionPRFSelectClient sequence. Each TLSExtensionPRFSelect sequence contains one supported algorithm combination. TLSExtensionPRFSelect :: SEQUENCE { hashAlgorithm AlgorithmIdentifier OPTIONAL, prfAlgorithm AlgorithmIdentifier OPTIONAL } TLSExtensionPRFSelectClient :: SEQUENCE OF TLSExtensionPRFSelect This extension MUST be omitted if the client only supports standard [TLS] algorithms. A client that wishes to indicate the support of standard [TLS] algorithms along with alternative ones MUST include the empty TLSExtensionPRFSelect sequence with both hashAlgorithm and Chudov Informational [Page 3] Internet-Draft Hash/PRF negotiation in TLS May 2005 prfAlgorithm fields omitted, indicating use of default algorithms (PRF and MD5+SHA1). Actions of the receiver: A server that receives a ClientHello containing this extension MUST use one of the proposed algorithm combinations. If a server is unable to perform handshake using any of the proposed algorithm sets, it MUST issue a fatal handshake_failure alert message. 3.2 Server Hello In reply to an extended Client Hello message containing an extension of type "prf_alg" server MUST send an extended Server Hello message, containing the same extension. This extension indicates the server's agreement to use during handshake one of the algorithm combinations sent by the client. When used in Server Hello, this extension carries a single hash/PRF algorithm combination. The opaque extension_data field contains DER- encoding of the TLSExtensionPRFSelectServer sequence. TLSExtensionPRFSelectServer :: TLSExtensionPRFSelect Actions of the receiver: A client that receives a ServerHello with this extension makes sure that server selected one of the algorithm sets, specified in the corresponding ClientHello extension, and proceeds with a handshake using the algorithms specified in it. A client that receives a ServerHello without this extension MUST act as if the standard [TLS] algorithms combination was specified by the server. If server specified combination which is not supported or allowed by a client, it MUST issue a fatal handshake_failure alert message. SecurityParameters structure from [TLS] is extended to hold a field PRFSelect of type TLSExtensionPRFSelect. SecurityParameters.PRFSelect is equal to the prf_alg extension from Server Hello message. Further in this document, PRF_EX stands for function, corresponding to SecurityParameters.PRFSelect.prfAlgorithm, and HASH_EX stands for function, corresponding to SecurityParameters.PRFSelect.hashAlgorithm. Chudov Informational [Page 4] Internet-Draft Hash/PRF negotiation in TLS May 2005 If prfAlgorithm field is omitted from SecurityParameters.PRFSelect, then PRF_EX equals PRF. If hashAlgorithm is omitted, HASH_EX(data) equals MD5(data)+SHA1(data). 4. Cryptographic computations affected This extension affects calculation of the following values: Finished.verify_data, key_block and master_secret. It does not affect calculations in Certificate Verify and ServerKeyExchange messages. Hash that is used for signature in those messages depends only on SignatureAlgorithm. 4.1 Finished message verify_data calculation When prf_alg extension is present, PRF_EX is used instead of PRF, and HASH_EX is used instead of MD5+SHA1. Finished.verify_data = PRF_EX (master_secret, finished_label, HASH_EX (handshake_messages)) [0..11]; 4.2 Key calculation When prf_alg extension is present, PRF_EX is used instead of PRF. key_block = PRF_EX(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random); 4.3 Computing the master secret When prf_alg extension is present, PRF_EX is used instead of PRF. master_secret = PRF_EX(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; 5 Security Considerations Avoiding man-in-the-middle algorithm rollback: When the server allows several hash/PRF algorithms, a man-in-the- middle algorithm rollback becomes possible. That is, the attacker can force the client and the server to use a weaker hash/PRF for handshake, than that which they would normally choose. Chudov Informational [Page 5] Internet-Draft Hash/PRF negotiation in TLS May 2005 The server SHOULD only allow one hash/PRF pair to be used, to avoid this attack. 6 References [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TLS] The TLS Protocol Version 1.0. T. Dierks, C. Allen. January 1999, RFC 2246. [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Exten- sions", RFC 3546, June 2003. [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997. [PSK] P. Eronen, H. Tschofenig "Pre-Shared Key Ciphersuites for Transport Layer Security", , work in progress. [GOST] G. Chudov, S. Leontiev "GOST Ciphersuites for Transport Layer Security", IETF draft, , work in progress. Acknowledgments The authors wish to thank: Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, creating this document. Author's Addresses Grigorij Chudov CRYPTO-PRO 38, Obraztsova, Chudov Informational [Page 6] Internet-Draft Hash/PRF negotiation in TLS May 2005 Moscow, 127018, Russian Federation EMail: chudov@cryptopro.ru Full 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. 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. Chudov Informational [Page 7]