idnits 2.17.1 draft-chudov-cryptopro-tlsprfneg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 291. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 283), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([TLS], [TLSEXT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 25, 2005) is 6912 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT') (Obsoleted by RFC 4366) -- Possible downref: Non-RFC (?) normative reference: ref. 'PSK' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Grigorij Chudov 3 Internet Draft CRYPTO-PRO 4 Expires November 25, 2005 May 25, 2005 5 Intended Category: Standards Track 7 Hash/PRF negotiation in TLS using TLS extensions. 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire in November 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 This document presents a method of negotiating some of the 46 algorithms, used by Transport Layer Security Protocol [TLS], which 47 are not chosen by cipher suite. Those algorithms are hash function 48 used for Finished message, and PRF function. 50 This is done using TLS Extensions [TLSEXT] mechanism. 52 Table of Contents 54 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 55 2 Extension Type. . . . . . . . . . . . . . . . . . . . . . 2 56 3 Changes to the Message Contents . . . . . . . . . . . . . 3 57 3.1 Client Hello. . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2 Server Hello. . . . . . . . . . . . . . . . . . . . . . . 4 59 4 Cryptographic computations affected . . . . . . . . . . . 4 60 4.1 Finished message verify_data calculation. . . . . . . . . 5 61 4.2 Key calculation . . . . . . . . . . . . . . . . . . . . . 5 62 4.3 Computing the master secret . . . . . . . . . . . . . . . 5 63 5 Security Considerations . . . . . . . . . . . . . . . . . 5 64 6 References. . . . . . . . . . . . . . . . . . . . . . . . 5 65 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . 6 67 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 6 69 1 Introduction 71 [TLS] Handshake Protocol negotiates a cipher suite, that is used to 72 provide connection security. A cipher suite specifies key agreement 73 mechanism, symmetric encryption and MAC calculation, however it does 74 not affect the hash algorithm and PRF, which are used during 75 handshake. 77 However, some applications require different PRF or hash function. 78 For example, [PSK] (Pre-Shared Key Ciphersuites) have the following 79 problem with PRF, used by [TLS]: PRF assumes a long random secret, 80 which can be split in two independent parts, which usually not the 81 case for PSK. The second example are [GOST] algorithms, which require 82 a different hash-function. 84 This document is intended to register a new TLS extension, using 85 mechanism, defined in [TLSEXT]. The purpose of this extension is to 86 allow hash and PRF algorithm negotiation. 88 This document uses the same notation used in the [TLS] Protocol 89 specification. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 92 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 93 this document are to be interpreted as described in [RFC 2119]. 95 2 Extension Type 97 A new value, "prf_alg(9)", is added to the enumerated ExtensionType, 98 defined in [TLSEXT]. This value is used as the extension number for 99 the extensions in both the client hello message and the server hello 100 message. This new extension type will be used for hash and PRF 101 algorithm negotiation. 103 The client enumerates supported algorithm combinations by including 104 the appropriate extension in its ClientHello message. By echoing 105 that extension in its ServerHello, the server selects one of them for 106 this TLS connection. Section 3 describes the structure of this 107 extension in further details. 109 3 Changes to the Message Contents 111 This section describes the changes to the TLS handshake message 112 contents when prf_alg extension is present. 114 3.1 Client Hello 116 In order to indicate the support of alternative hash and PRF 117 algorithms clients will include an extension of type "prf_alg" in the 118 extended client hello message. The general extension mechanism is 119 described in [TLSEXT]. 121 This extension carries a list of hash/PRF algorithm pairs client can 122 use. The opaque extension_data field contains DER-encoding of the 123 TLSExtensionPRFSelectClient sequence. Each TLSExtensionPRFSelect 124 sequence contains one supported algorithm combination. 126 TLSExtensionPRFSelect :: SEQUENCE { 127 hashAlgorithm AlgorithmIdentifier OPTIONAL, 128 prfAlgorithm AlgorithmIdentifier OPTIONAL 129 } 131 TLSExtensionPRFSelectClient :: SEQUENCE OF TLSExtensionPRFSelect 133 This extension MUST be omitted if the client only supports standard 134 [TLS] algorithms. 136 A client that wishes to indicate the support of standard [TLS] 137 algorithms along with alternative ones MUST include the empty 138 TLSExtensionPRFSelect sequence with both hashAlgorithm and 139 prfAlgorithm fields omitted, indicating use of default algorithms 140 (PRF and MD5+SHA1). 142 Actions of the receiver: 144 A server that receives a ClientHello containing this extension MUST 145 use one of the proposed algorithm combinations. If a server is unable 146 to perform handshake using any of the proposed algorithm sets, it 147 MUST issue a fatal handshake_failure alert message. 149 3.2 Server Hello 151 In reply to an extended Client Hello message containing an extension 152 of type "prf_alg" server MUST send an extended Server Hello message, 153 containing the same extension. This extension indicates the server's 154 agreement to use during handshake one of the algorithm combinations 155 sent by the client. 157 When used in Server Hello, this extension carries a single hash/PRF 158 algorithm combination. The opaque extension_data field contains DER- 159 encoding of the TLSExtensionPRFSelectServer sequence. 161 TLSExtensionPRFSelectServer :: TLSExtensionPRFSelect 163 Actions of the receiver: 165 A client that receives a ServerHello with this extension makes sure 166 that server selected one of the algorithm sets, specified in the 167 corresponding ClientHello extension, and proceeds with a handshake 168 using the algorithms specified in it. 170 A client that receives a ServerHello without this extension MUST act 171 as if the standard [TLS] algorithms combination was specified by the 172 server. 174 If server specified combination which is not supported or allowed by 175 a client, it MUST issue a fatal handshake_failure alert message. 177 SecurityParameters structure from [TLS] is extended to hold a field 178 PRFSelect of type TLSExtensionPRFSelect. 179 SecurityParameters.PRFSelect is equal to the prf_alg extension from 180 Server Hello message. 182 Further in this document, PRF_EX stands for function, corresponding 183 to SecurityParameters.PRFSelect.prfAlgorithm, and HASH_EX stands for 184 function, corresponding to 185 SecurityParameters.PRFSelect.hashAlgorithm. 187 If prfAlgorithm field is omitted from SecurityParameters.PRFSelect, 188 then PRF_EX equals PRF. If hashAlgorithm is omitted, HASH_EX(data) 189 equals MD5(data)+SHA1(data). 191 4. Cryptographic computations affected 193 This extension affects calculation of the following values: 194 Finished.verify_data, key_block and master_secret. 196 It does not affect calculations in Certificate Verify and 197 ServerKeyExchange messages. Hash that is used for signature in those 198 messages depends only on SignatureAlgorithm. 200 4.1 Finished message verify_data calculation 202 When prf_alg extension is present, PRF_EX is used instead of PRF, and 203 HASH_EX is used instead of MD5+SHA1. 205 Finished.verify_data = PRF_EX (master_secret, finished_label, 206 HASH_EX (handshake_messages)) 207 [0..11]; 209 4.2 Key calculation 211 When prf_alg extension is present, PRF_EX is used instead of PRF. 213 key_block = PRF_EX(SecurityParameters.master_secret, 214 "key expansion", 215 SecurityParameters.server_random + 216 SecurityParameters.client_random); 218 4.3 Computing the master secret 220 When prf_alg extension is present, PRF_EX is used instead of PRF. 222 master_secret = PRF_EX(pre_master_secret, "master secret", 223 ClientHello.random + ServerHello.random) 224 [0..47]; 226 5 Security Considerations 228 Avoiding man-in-the-middle algorithm rollback: 230 When the server allows several hash/PRF algorithms, a man-in-the- 231 middle algorithm rollback becomes possible. That is, the attacker can 232 force the client and the server to use a weaker hash/PRF for 233 handshake, than that which they would normally choose. 235 The server SHOULD only allow one hash/PRF pair to be used, to avoid 236 this attack. 238 6 References 240 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, March 1997. 243 [TLS] The TLS Protocol Version 1.0. T. Dierks, C. Allen. 244 January 1999, RFC 2246. 246 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. 247 and T. Wright, "Transport Layer Security (TLS) Exten- 248 sions", RFC 3546, June 2003. 250 [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 251 encoding rules: Specification of Basic Encoding Rules 252 (BER), Canonical Encoding Rules (CER) and Distinguished 253 Encoding Rules (DER), 1997. 255 [PSK] P. Eronen, H. Tschofenig "Pre-Shared Key Ciphersuites for 256 Transport Layer Security", , 257 work in progress. 259 [GOST] G. Chudov, S. Leontiev "GOST Ciphersuites for Transport 260 Layer Security", IETF draft, , work in progress. 263 Acknowledgments 265 The authors wish to thank: 267 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 268 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, 269 creating this document. 271 Author's Addresses 273 Grigorij Chudov 274 CRYPTO-PRO 275 38, Obraztsova, 276 Moscow, 127018, Russian Federation 277 EMail: chudov@cryptopro.ru 279 Full Copyright Statement 281 Copyright (C) The Internet Society (2005). This document is subject 282 to the rights, licenses and restrictions contained in BCP 78, and 283 except as set forth therein, the authors retain all their rights. 285 This document and the information contained herein are provided on an 286 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 287 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 288 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 289 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 290 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 291 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.