idnits 2.17.1 draft-chudov-cryptopro-cptls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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. ** The abstract seems to contain references ([TLS]), 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 (June 15, 2003) is 7622 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GOSTR3411' is mentioned on line 79, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 99, but not defined -- Looks like a reference, but probably isn't: '32' on line 248 == Unused Reference: 'Schneier95' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC 3280' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC 3279' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC 2219' is defined on line 321, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Grigorij Chudov, CRYPTO-PRO 3 INTERNET-DRAFT Serguei Leontiev, CRYPTO-PRO 4 Expires December 15, 2003 June 15, 2003 5 Intended Category: Informational 7 Addition of GOST Ciphersuites to Transport Layer Security (TLS) 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or made obsolete by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document is intended to register new cipher suites for the 35 Transport Layer Security (TLS) protocol, according to the procedure 36 specified in section A.5 of [TLS]. Those cipher suites are based on 37 Russian national cryptographic standards - key establishment 38 algorithms based on GOST R 3410-94 and GOST R 3410-2001 public keys, 39 GOST 28147-89 encryption algorithm and GOST R 34.11-94 digest 40 algorithm. 42 Table of Contents 44 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 45 2 Proposed Ciphersuites . . . . . . . . . . . . . . . . . . 3 46 3 CipherSuite Definitions . . . . . . . . . . . . . . . . . 3 47 3.1 Key Exchange. . . . . . . . . . . . . . . . . . . . . . . 3 48 3.2 PRF, Signature and Hash . . . . . . . . . . . . . . . . . 3 49 3.3 Cipher and MAC. . . . . . . . . . . . . . . . . . . . . . 3 50 4 Data Structures and Computations. . . . . . . . . . . . . 4 51 4.1 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 4 52 4.2 Keys Calculation. . . . . . . . . . . . . . . . . . . . . 4 53 4.3 Server Certificate. . . . . . . . . . . . . . . . . . . . 4 54 4.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 4 55 4.5 Certificate Request . . . . . . . . . . . . . . . . . . . 4 56 4.6 Client Key Exchange Message . . . . . . . . . . . . . . . 5 57 4.7 Certificate Verify. . . . . . . . . . . . . . . . . . . . 5 58 4.8 Finished. . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5 Security Considerations . . . . . . . . . . . . . . . . . 6 60 6 References. . . . . . . . . . . . . . . . . . . . . . . . 6 61 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 62 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . 9 63 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 10 65 1 Introduction 67 This document only describes algorithm identifiers, data formats and 68 protocol messages used in TLS (Transport Layer Security) protocol 69 cipher suites, based on GOST R 34.10-94/2001 key exchange, GOST R 70 34.11-94 hash and GOST 28147-89 encryption algorithms. It does not 71 describe those cryptographic algorithms. The cipher suites defined 72 here were proposed by CRYPTO-PRO Company for "Russian Cryptographic 73 Software Compatibility Agreement" community. 75 Algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST 28147-89 and GOST 76 R 34.11-94 have been developed by Russian Federal Agency of 77 Governmental Communication and Information (FAGCI) and "All-Russian 78 Scientific and Research Institute of Standardization". They are 79 described in [GOSTR341094], [GOSTR34102001], [GOSTR3411] and 80 [GOST28147]. GOST-based key agreement algorithm and PRF are described 81 in [CPALGS]. 83 This document defines two configurations: 84 anonymous client - authenticated server (only server provides a 85 certificate); 86 authenticated client - authenticated server (client and server 87 exchange certificates). 89 The presentation language used here is the same as in [TLS]. Since 90 this specification extends TLS, these descriptions should be merged 91 with those in the TLS specification and any others that extend TLS. 92 This means, that enum types may not specify all possible values and 93 structures with multiple formats chosen with a select() clause may 94 not indicate all possible cases. 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 97 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 98 this document are to be interpreted as described in [RFC 2119]. 100 2 Proposed CipherSuites 102 The new cipher suites proposed here have the following definitions: 104 CipherSuite TLS_GOST341094_WITH_GOST28147_CFB_GOST3411 = {0x00,0x80} 105 CipherSuite TLS_GOST34102001_WITH_GOST28147_CFB_GOST3411 = {0x00,0x81} 106 CipherSuite TLS_GOST341094_WITH_NULL_GOSTR3411 = {0x00,0x82} 107 CipherSuite TLS_GOST34102001_WITH_NULL_GOSTR3411 = {0x00,0x83} 109 Note: The above numeric definitions for CipherSuites have not yet been 110 registered. 112 3 CipherSuite Definitions 114 3.1 Key exchange 116 The cipher suites defined here use the following key exchange 117 algorithms: 119 CipherSuite Key Exchange Algorithm 120 TLS_GOST341094_WITH_GOST28147_CFB_GOST3411 GOST R 3410-94 121 TLS_GOST34102001_WITH_GOST28147_CFB_GOST3411 GOST R 3410-2001 122 TLS_GOST341094_WITH_NULL_GOSTR3411 GOST R 3410-94 123 TLS_GOST34102001_WITH_NULL_GOSTR3411 GOST R 3410-2001 125 Key establishment algorithms based on GOST R 3410-94 and GOST R 126 3410-2001 public keys are described in [CPALGS]. 128 3.2 PRF, Signature and Hash 130 For a PRF, described in section 5 of [TLS], the cipher suites described 131 here use GOSTR3411_PRF (refer to section 4.1) 133 GOST R 3410-94/2001 signature is used for CertificateVerify message. 135 GOST R 34.11 digest algorithm ([GOSTR341194]) is used for 136 CertificateVerify.signature.gostR3411_hash and Finished.verify_data 137 (see sections 7.4.8 and 7.4.9 of [TLS]) 139 3.3 Cipher and MAC 141 The following cipher algorithm and MAC functions are used (for details 142 refer to section 4.1): 144 CipherSuite Cipher MAC 145 TLS_GOST341094_WITH_GOST28147_CFB_GOST3411 GOST28147 GOST28147_IMIT 146 TLS_GOST34102001_WITH_GOST28147_CFB_GOST3411 GOST28147 GOST28147_IMIT 147 TLS_GOST341094_WITH_NULL_GOSTR3411 - GOSTR3411_HMAC 148 TLS_GOST34102001_WITH_NULL_GOSTR3411 - GOSTR3411_HMAC 150 4 Data Structures and Computations 152 4.1 Algorithms 154 GOST28147 is a stream cipher GOST 28147-89 [GOST28147] in CFB mode, it 155 uses 256-bit key size and 8-byte IV. Algorithm parameters are taken 156 from the server certificate. 158 GOST28147_IMIT is GOST 28147-89 [GOST28147] in "IMITOVSTAVKA" mode (4 159 bytes) 161 GOSTR3411_HMAC(secret, data) is based on GOST R 34.11 digest and 162 described in [CPCMS]. 164 GOSTR3411_PRF(secret, label, seed) is based on GOSTR3411_HMAC and 165 described in [CPALGS]. 167 4.2 Key Calculation 169 Key calculation is done according to section 6.3 of [TLS], with 170 GOSTR3411_PRF function used instead of PRF. The parameters are as 171 follows: 172 SecurityParameters.hash_size = 32 173 SecurityParameters.key_material_length = 32 174 SecurityParameters.IV_size = 8 175 Length of necessary key material is 144 bytes. 177 4.3 Server Certificate 179 For these cipher suites this message is required and it MUST contain 180 a certificate, with a public key algorithm matching 181 ServerHello.cipher_suite. 183 4.4 Server Key Exchange 185 This message MUST NOT be used in these cipher suites, because all the 186 parameters necessary are present in server certificate (see [CPPK]). 188 4.5 Certificate Request 190 This message is used as described in section 7.4.4 of [TLS], and 191 extended as follows: 193 enum { 194 gost341094(21), gost34102001(22),(255) 195 } ClientCertificateType; 197 gost341094 and gost34102001 certificate types identify that the 198 server accepts GOST R 34.10-94 and GOST R 34.10-2001 public key 199 certificates. 201 4.6 Client Key Exchange Message 203 This message is required and it MUST contain client ephemeral public 204 key if server didn't request client certificate or client has no 205 certificate with matching algorithm and parameters. 207 The TLS ClientKeyExchange message is extended as follows: 209 struct 210 { 211 G28147_ENCRYPTION_BLOB keyBlob; 212 STACK_OF(TLS1_PROXY_KEY_BLOB) proxyKeyBlobs; 213 } ClientKeyExchange; 215 ASN.1 syntax for G28147_ENCRYPTION_BLOB is defined in [CPCMS] as 216 GostR3410-94-KeyTransportEncryptedKeyOctetString/ 217 GostR3410-2001-KeyTransportEncryptedKeyOctetString. 219 struct 220 { 221 G28147_ENCRYPTION_BLOB keyBlob; 222 ASN1_OCTET_STRING cert; 223 } TLS1_PROXY_KEY_BLOB; 225 proxyKeyBlobs - (optional) contains key exchange for multiple 226 recipients (for example, when using firewall). cert - contains 227 recipient's certificate if several recipients are used. 229 4.7 Certificate Verify 231 This message is used as described in section 7.4.8 of [TLS]. If the 232 client have sent both a client certificate and an ephemeral public 233 key, it MUST send a certificate verify message, as a proof of 234 possession of the private key for provided certificate. 236 The TLS structures are extended as follows: 238 enum { gost341094, gost34102001 } 239 SignatureAlgorithm; 241 select (SignatureAlgorithm) { 242 case gost341094: 243 digitally-signed struct { 244 opaque gost341194_hash[32]; 245 }; 246 case gost34102001: 247 digitally-signed struct { 248 opaque gost341194_hash[32]; 249 }; 250 } Signature; 252 CertificateVerify.signature.gostR3411_hash = 253 GOSTR3411(handshake_messages) 255 4.8 Finished 257 This message is used as described in section 7.4.9 of [TLS]. 259 Finished.verify_data = GOSTR3411_PRF(master_secret, finished_label + 260 GOSTR3411(handshake_messages)) [0..11] 262 5 Security Considerations 264 Parameter values for using cryptographic algorithms affect rigidity 265 of information protection system. It is RECCOMENDED, that software 266 applications verify signature values, subject public keys and 267 algorithm parameters to conform to [GOSTR34102001], [GOSTR341094] 268 standards prior to their use. 270 The cipher suites TLS_GOST341094_WITH_GOST28147_CFB_GOST3411 and 271 TLS_GOST34102001_WITH_GOST28147_CFB_GOST3411 proposed hereby, have 272 been analyzed by special certification laboratory of Scientific and 273 Technical Centre "ATLAS" in appropriate levels of 274 target_of_evaluation (TOE). 276 It is RECCOMENDED to perform an examination of cipher suites 277 implementations by authorized agency with approved methods of 278 cryptographic analysis. 280 6 References 282 [GOST28147] "Cryptographic Protection for Data Processing Sys- 283 tem", GOST 28147-89, Gosudarstvennyi Standard of 284 USSR, Government Committee of the USSR for Standards, 285 1989. (In Russian); 287 [GOSTR341094] "Information technology. Cryptographic Data Security. 288 Produce and check procedures of Electronic Digital 289 Signatures based on Asymmetric Cryptographic Algo- 290 rithm.", GOST R 34.10-94, Gosudarstvennyi Standard of 291 Russian Federation, Government Committee of the Rus- 292 sia for Standards, 1994. (In Russian); 294 [GOSTR34102001] "Information technology. Cryptographic Data Secu- 295 rity.Signature and verification processes of [elec- 296 tronic] digital signature.", GOST R 34.10-2001, Gosu- 297 darstvennyi Standard of Russian Federation, Govern- 298 ment Committee of the Russia for Standards, 2001. (In 299 Russian); 301 [GOSTR341194] "Information technology. Cryptographic Data Security. 302 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 303 Standard of Russian Federation, Government Committee 304 of the Russia for Standards, 1994. (In Russian); 306 [CPALGS] "CryptoPro CSP" Cryptographic Algorithms; 308 [Schneier95] B. Schneier, Applied cryptography, second edition, 309 John Wiley & Sons, Inc., 1995; 311 [RFC 3280] Housley, R., Polk, W., Ford, W. and D. Solo, 312 "Internet X.509 Public Key Infrastructure Certificate 313 and Certificate Revocation List (CRL) Profile", RFC 314 3280, April 2002. 316 [RFC 3279] Algorithms and Identifiers for the Internet X.509 317 Public Key Infrastructure Certificate and Certificate 318 Revocation List (CRL) Profile. L. Bassham, W. 319 Polk, R. Housley. April 2002. 321 [RFC 2219] Bradner, S., "Key Words for Use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [TLS] The TLS Protocol Version 1.0. T. Dierks, C. Allen. 325 January 1999, RFC 2246. 327 [X.660] ITU-T Recommendation X.660 Information Technology - 328 ASN.1 encoding rules: Specification of Basic Encoding 329 Rules (BER), Canonical Encoding Rules (CER) and Dis- 330 tinguished Encoding Rules (DER), 1997. 332 [CPPK] "Algorithms and Identifiers for the Internet X.509 333 Public Key Infrastructure Certificates and Certifi- 334 cate Revocation List (CRL), corresponding to the 335 algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 336 34.11-94", IETF draft, , 337 ... 339 [CPCMS] "Cryptographic Message Syntax (CMS) algorithms for 340 GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, 341 GOST R 34.11-94", IETF draft, , work in progress 344 Acknowledgments 346 This document was created in accordance with "Russian Cryptographic 347 Software Compatibility Agreement", signed by FGUE STC "Atlas", 348 CRYPTO-PRO, Factor-TC, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 349 Cryptocom, R-Alpha. The aim of this agreement is to achieve mutual 350 compatibility of the products and solutions. 352 The authors wish to thank: 354 Microsoft Corporation Russia for provided information about company 355 products and solutions, and also for technical consulting in PKI. 357 RSA Security Russia and Demos Co Ltd for active colaboration and 358 critical help in creation of this document. 360 NIP Informzachita for compatibility testing of the proposed data 361 formats while incorporating them into company products. 363 Citrix Inc for help in compatibility testing Citrix products for 364 Microsoft Windows. 366 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and Vasilij 367 Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, creating this 368 document. 370 This document is based on a contribution of CRYPTO-PRO company. Any 371 substantial use of the text from this document must acknowledge 372 CRYPTO-PRO. CRYPTO-PRO requests that all material mentioning or 373 referencing this document identify this as "CRYPTO-PRO CPTLS". 375 Author's Addresses 377 Serguei Leontiev 378 CRYPTO-PRO 379 38, Obraztsova, 380 Moscow, 127018, Russian Federation 381 EMail: lse@CryptoPro.ru 383 Grigorij Chudov 384 CRYPTO-PRO 385 38, Obraztsova, 386 Moscow, 127018, Russian Federation 387 EMail: chudov@CryptoPro.ru 389 Alexandr Afanasiev 390 Factor-TC 391 office 711, 14, Presnenskij val, 392 Moscow, 123557, Russian Federation 393 EMail: aaaf@factor-ts.ru 395 Nikolaj Nikishin 396 Infotecs GmbH 397 p/b 35, 80-5, Leningradskij prospekt, 398 Moscow, 125315, Russian Federation 399 EMail: nikishin@infotecs.ru 401 Boleslav Izotov 402 FGUE STC "Atlas" 403 38, Obraztsova, 404 Moscow, 127018, Russian Federation 405 EMail: izotov@stcnet.ru 407 Elena Minaeva 408 MD PREI 409 build 3, 6A, Vtoroj Troitskij per., 410 Moscow, Russian Federation 411 EMail: evminaeva@mo.msk.ru 413 Serguei Murugov 414 R-Alpha 415 4/1, Raspletina, 416 Moscow, 123060, Russian Federation 417 EMail: msm@office.ru 419 Igori Ustinov 420 Cryptocom 421 office 239, 51, Leninskij prospekt, 422 Moscow, 119991, Russian Federation 423 EMail: igus@cryptocom.ru 425 Anatolij Erkin 426 SPRCIS (SPbRCZI) 427 1, Obrucheva, 428 St.Petersburg, 195220, Russian Federation 429 EMail: erkin@nevsky.net 431 Full Copyright Statement 433 Copyright (C) The Internet Society (2003). All Rights Reserved. 435 This document and translations of it may be copied and furnished to 436 others, and derivative works that comment on or otherwise explain it 437 or assist in its implementation may be prepared, copied, published 438 and distributed, in whole or in part, without restriction of any 439 kind, provided that the above copyright notice and this paragraph are 440 included on all such copies and derivative works. However, this 441 document itself may not be modified in any way, such as by removing 442 the copyright notice or references to the Internet Society or other 443 Internet organizations, except as needed for the purpose of 444 developing Internet standards in which case the procedures for 445 copyrights defined in the Internet Standards process must be 446 followed, or as required to translate it into languages other than 447 English. 449 The limited permissions granted above are perpetual and will not be 450 revoked by the Internet Society or its successors or assigns. 452 This document and the information contained herein is provided on an 453 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 454 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 455 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 456 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 457 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.