idnits 2.17.1 draft-smyshlyaev-tls12-gost-suites-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2018) is 2128 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 287, but not defined -- Looks like a reference, but probably isn't: '0' on line 559 == Outdated reference: A later version (-17) exists of draft-irtf-cfrg-re-keying-12 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Smyshlyaev, Ed. 3 Internet-Draft CryptoPro 4 Intended status: Informational D. Belyavsky 5 Expires: December 31, 2018 Cryptocom 6 M. Saarinen 7 Independent Consultant 8 June 29, 2018 10 GOST Cipher Suites for TLS 1.2 11 draft-smyshlyaev-tls12-gost-suites-01 13 Abstract 15 This document specifies a set of cipher suites for the Transport 16 Layer Security (TLS) protocol Version 1.2 to support the Russian 17 cryptographic standard algorithms. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 31, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 3 56 4. Cipher Suite Definitions . . . . . . . . . . . . . . . . . . 4 57 4.1. Record Payload Protection . . . . . . . . . . . . . . . . 4 58 4.1.1. CTR_OMAC . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1.2. CNT_IMIT . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Key Exchange and Authentication . . . . . . . . . . . . . 6 61 4.2.1. Hello Messages . . . . . . . . . . . . . . . . . . . 8 62 4.2.1.1. Signature Algorithms Extension . . . . . . . . . 9 63 4.2.2. CertificateRequest . . . . . . . . . . . . . . . . . 9 64 4.2.3. ClientKeyExchange . . . . . . . . . . . . . . . . . . 10 65 4.2.3.1. CTR_OMAC . . . . . . . . . . . . . . . . . . . . 11 66 4.2.3.2. CNT_IMIT . . . . . . . . . . . . . . . . . . . . 12 67 4.2.4. CertificateVerify . . . . . . . . . . . . . . . . . . 14 68 4.3. Cryptographic Algorithms . . . . . . . . . . . . . . . . 14 69 4.3.1. Block Cipher . . . . . . . . . . . . . . . . . . . . 14 70 4.3.2. MAC . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.3.3. Encryption Algorithm . . . . . . . . . . . . . . . . 15 72 4.3.4. SNMAX . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.3.5. PRF and HASH . . . . . . . . . . . . . . . . . . . . 15 74 5. Additional Algorithms . . . . . . . . . . . . . . . . . . . . 16 75 5.1. TLSTREE . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 5.1.1. Key Tree Parameters . . . . . . . . . . . . . . . . . 16 77 5.2. KExp15 and KImp15 Algorithms . . . . . . . . . . . . . . 17 78 5.3. KEG Algorithm . . . . . . . . . . . . . . . . . . . . . . 18 79 5.4. gostIMIT28147 . . . . . . . . . . . . . . . . . . . . . . 19 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 8.2. Informative References . . . . . . . . . . . . . . . . . 21 85 Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 22 86 A.1. Test Examples for CTR_OMAC cipher suites . . . . . . . . 22 87 A.2. Test Examples for CNT_IMIT cipher suites . . . . . . . . 22 88 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 22 89 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 92 1. Introduction 94 This document specifies three new cipher suites for the Transport 95 Layer Security (TLS) Protocol Version 1.2 [RFC5246] to support the 96 set of Russian cryptographic standard algorithms (called GOST 97 algorithms). All of them use the GOST R 34.11-2012 [GOST3411-2012] 98 hash algorithm (the English version can be found in [RFC6986]) and 99 the GOST R 34.10-2012 [GOST3410-2012] signature algorithm (the 100 English version can be found in [RFC7091]) but use different 101 encryption algorithms, so they are divided into two types: the 102 CTR_OMAC cipher suites and the CNT_IMIT cipher suite. 104 The CTR_OMAC cipher suites use the GOST R 34.12-2015 [GOST3412-2015] 105 block ciphers (the English version can be found in [RFC7801]): 107 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xXX, 0xXX}; 108 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xXX, 0xXX}. 110 The CNT_IMIT cipher suites use the GOST 28147-89 [GOST28147-89] block 111 cipher (the English version can be found in [RFC5830]): 113 TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xXX, 0xXX}. 115 2. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Basic Terms and Definitions 123 This document uses the following terms and definitions for the sets 124 and operations on the elements of these sets: 126 B* the set of all byte strings of a finite length (hereinafter 127 referred to as strings), including the empty string; 129 B_s The set of byte vectors of size s, s >= 0, for s = 0 the B_s 130 set consists of a single empty element of size 0. If W is an 131 element of B_s, then W = (w^1, w^2, ..., w^s), where w^1, 132 w^2, ..., w^s are in {0, ... , 255}; 134 b[i..j] the string b[i..j] = (b_i, b_{i+1}, ... , b_j) in B_{j-i+1} 135 where 1<=i<=j<=s and b = (b_1, ... , b_s) in B_s 137 |X| the byte length of the byte string X; 138 A | C concatenation of strings A and C both belonging to B*, i.e., 139 a string in B_{|A|+|C|}, where the left substring in B_|A| is 140 equal to A, and the right substring in B_|C| is equal to C; 142 Int_s the transformation that maps a string a = (a_s, ... , a_1) in 143 B_s into the integer Int_s(a) = 256^{s-1} * a_s + ... + 256 * 144 a_2 + a_1 (the interpretation of the binary string as an 145 integer); 147 Vec_s the transformation inverse to the mapping Int_s (the 148 interpretation of an integer as a binary string); 150 Str_s the transformation that maps an integer i = 256^{s-1} * i_s + 151 ... + 2 * i_2 + i_1 into the string Str_s(i) = (i_1, ... , 152 i_s) in B_s; 154 k the byte-length of the block cipher key; 156 n the block size of the block cipher (in bytes); 158 Q_C the public key stored in the client's certificate; 160 k_C the private key that corresponds to Q_C key; 162 Q_S the server's public key; 164 k_C the server's private key; 166 r_C the random string that corresponds to ClientHello.random 167 field from [RFC5246]; 169 r_S the random string that corresponds to ServerHello.random 170 field from [RFC5246]. 172 4. Cipher Suite Definitions 174 4.1. Record Payload Protection 176 All of the cipher suites described in this document MUST use the 177 stream cipher (see Section 4.3.3) to protect records. The 178 TLSCiphertext structure for the CTR_OMAC and CNT_IMIT cipher suits is 179 specified in accordance with the GenericStreamCipher case (see 180 Section 6.2.3.1 of [RFC5246]): 182 struct { 183 ContentType type; 184 ProtocolVersion version; 185 uint16 length; 186 GenericStreamCipher fragment; 187 } TLSCiphertext; 189 Here TLSCiphertext.fragment is generated as described in 190 Section 4.1.1 and Section 4.1.2. 192 The connection key material consists of the sender_write_key (either 193 the client_write_key or the server_write_key), the 194 sender_write_MAC_key (either the client_write_MAC_key or the 195 server_write_MAC_key) and the sender_write_IV (either the 196 client_write_IV or the server_write_IV) parameters that are generated 197 according to section 6.3 of [RFC5246]. 199 4.1.1. CTR_OMAC 201 In case of the CTR_OMAC cipher_suites there is a certain key material 202 which is used by the peer to protect a record that corresponds to the 203 seqnum sequence number (in the following simply record key material) 204 and consist of K_ENC_seqnum, K_MAC_seqnum and IV_seqnum values that 205 are calculated using the TLSTREE function defined in Section 5.1 and 206 the connection key material: 208 K_ENC_seqnum = TLSTREE(sender_write_key, seqnum); 210 K_MAC_seqnum = TLSTREE(sender_write_MAC_key, seqnum); 212 IV_seqnum = Vec_{n/2}((Int_{n/2}(sender_write_IV) + seqnum) mod 213 2^{n*8/2}). 215 The TLSCiphertext.fragment that corresponds to the seqnum sequence 216 number is equal to the ENCValue_seqnum value that is calculated as 217 follows: 219 1. The MAC value (MACValue_seqnum) is generated by the MAC algorithm 220 (see Section 4.3.2) similar to Section 6.2.3.1 of [RFC5246] except 221 the used MAC key: the sender_write_MAC_key is replaced by the 222 K^seqnum_MAC key: 224 MACData_seqnum = Str_8(seqnum) | type_seqnum | version_seqnum | 225 length_seqnum | fragment_seqnum; 227 MACValue_seqnum = MAC(K_MAC_seqnum, MACData_seqnum), 229 where type_seqnum, version_seqnum, length_seqnum, fragment_seqnum are 230 the TLSCompressed.type, the TLSCompressed.version, the 231 TLSCompressed.length and the TLSCompressed.fragment values of the 232 record with the seqnum sequence number. 234 2. The stream cipher ENC (see Section 4.3.3) encrypts the entire 235 data with the MACValue as follows: 237 ENCData_seqnum = fragment_seqnum | MACValue_seqnum; 239 ENCValue_seqnum = ENC( K_ENC_seqnum, IV_seqnum, ENCData_seqnum). 241 4.1.2. CNT_IMIT 243 In case of the CNT_IMIT cipher_suites the TLSCiphertext.fragment that 244 corresponds to the seqnum sequence number is equal to the 245 ENCValue_seqnum value that is calculated as follows: 247 1. The MAC value (MACValue_seqnum) is generated by the MAC algorithm 248 (see Section 4.3.2) as follows: 250 MACData_i = Str_8(i) | type_i | version_i | length_i | fragment_i, 251 i in {0, ... , seqnum}; 253 MACValue_seqnum = MAC(sender_write_MAC_key, MACData_0 | ... | 254 MACData_seqnum), 256 where type_i, version_i, length_i, fragment_i are the 257 TLSCompressed.type, the TLSCompressed.version, the 258 TLSCompressed.length and the TLSCompressed.fragment values of the 259 record with the i sequence number. 261 2. The stream cipher ENC (see Section 4.3.3) encrypts the entire 262 data ENCData_i with the MACValue_i that correspond to the record 263 sequence number i with the MACValue as follows: 265 ENCData_i = fragment_i | MACValue_i, i in {0, ... , seqnum}; 267 ENCValue_0 | ... | ENCValue_seqnum = ENC(sender_write_key, 268 sender_write_IV, ENCData_0 | ... |ENCData_seqnum). 270 4.2. Key Exchange and Authentication 272 All of the cipher suites described in this document use ECDH to 273 compute the TLS premaster secret. 275 Client Server 277 ClientHello --------> 278 ServerHello 279 Certificate 280 CertificateRequest* 281 <-------- ServerHelloDone 282 Certificate* 283 ClientKeyExchange 284 CertificateVerify* 285 [ChangeCipherSpec] 286 Finished --------> 287 [ChangeCipherSpec] 288 <-------- Finished 289 Application Data <-------> Application Data 291 * message is not sent unless client authentication is desired 293 Figure 1 shows all messages involved in the TLS key establishment 294 protocol (aka full handshake). A ServerKeyExchange MUST NOT be sent 295 (the server's certificate contains all the necessary keying 296 information required by the client to arrive at the premaster 297 secret). 299 The key exchange process consists of the following steps: 301 1. The client generates ECDHE key pair (Q_eph, k_eph), Q_eph is on 302 the same curve as the server's long-term public key Q_S. 304 2. The client generates the premaster secret value PS. The PS value 305 is chosen by random from B_32. 307 3. Using k_eph, server long-term public key and some generated nonce 308 value the client generates the encryption key for key-wrap 309 algorithm and then sends the PS value wrapped with particular 310 key-wrap algorithm. 312 4. The client sends its ephemeral public key Q_eph and the wrapped 313 PS value in the ClientKeyExchange message. 315 5. The server extract the premaster secret value PS using its long- 316 term secret key k_S in accordance with the key wrap algorithm. 318 The server side of the channel is always authenticated; the client 319 side is optionally authenticated. The server is authenticated using 320 it's long term private key from the certificate and proving that it 321 knows a shared secret. The client is authenticated when the server 322 is checking its signature. 324 The proposed cipher suites has direct impact only on the ClientHello, 325 the ServerHello, the CertificateRequest, the ClientKeyExchange and 326 the CertificateVerify handshake messages, that are described bellow 327 in greater detail in terms of the content and processing of these 328 messages. 330 4.2.1. Hello Messages 332 The ClientHello message must meet the following requirements: 334 o The ClientHello.compression_methods field MUST contain exactly one 335 byte, set to zero, which corresponds to the "null" compression 336 method. 338 o While using cipher CTR_OMAC cipher suites the 339 ClientHello.extensions field MUST contain the following three 340 extensions: signature_algorithms (see Section 4.2.1.1), 341 extended_master_secret (see [RFC7627]), renegotiation_info (see 342 [RFC5746]). 344 o While using the CNT_IMIT cipher suite the ClientHello.extensions 345 field MUST contain the signature_algorithms (see Section 4.2.1.1) 346 extension. And it is RECOMMENDED to contain the following two 347 extensions: extended_master_secret (see [RFC7627]), 348 renegotiation_info (see [RFC5746]). 350 The ServerHello message must meet the following requirements: 352 o The ServerHello.compression_method field MUST contain exactly one 353 byte, set to zero, which corresponds to the "null" compression 354 method. 356 o While using the CTR_OMAC cipher suites the ServerHello.extensions 357 field MUST contain the following two extensions: 358 extended_master_secret (see [RFC7627]), renegotiation_info (see 359 [RFC5746]). 361 o While using the CNT_IMIT cipher suite it is RECOMMENDED for the 362 ServerHello.extensions field to contain the following two 363 extensions: extended_master_secret (see [RFC7627]), 364 renegotiation_info (see [RFC5746]). 366 Note: If the extended_master_secret extension is agreed, then the 367 master secret value MUST be calculated in accordance with [RFC7627]. 369 4.2.1.1. Signature Algorithms Extension 371 The signature_algorithms extension is described in Section 7.4.1.4.1 372 of (see [RFC5246]) and is specified as follows. 374 SignatureAndHashAlgorithm 375 supported_signature_algorithms<2..2^16-2>; 377 struct { 378 HashAlgorithm hash; 379 SignatureAlgorithm signature; 380 } SignatureAndHashAlgorithm; 382 The set of supported hash algorithms is specified as follows: 384 enum { 385 gostr34112012_256(238), 386 gostr34112012_512(239), (255) 387 } HashAlgorithm; 389 where gostr34112012_256 and gostr34112012_512 values correspond to 390 the GOST R 34.11-2012 [GOST3411-2012] hash algorithm with 32-byte 391 (256-bit) and 64-byte (512-bit) hash code respectively. 393 The set of supported signature algorithms is specified as follows: 395 enum { 396 gostr34102012_256(238), 397 gostr34102012_512(239), (255) 398 } SignatureAlgorithm; 400 where gostr34102012_256 and gostr34102012_512 values correspond to 401 the GOST R 34.10-2012 [GOST3410-2012] signature algorithm with 402 32-byte (256-bit) and 64-byte (512-bit) key length respectively. 404 4.2.2. CertificateRequest 406 When this message is sent: this message is sent when requesting 407 client authentication. 409 Meaning of this message: the server uses this message to suggest 410 acceptable certificates. 412 The TLS CertificateRequest message is extended as follows. 414 struct { 415 ClientCertificateType certificate_types<1..2^8-1>; 416 SignatureAndHashAlgorithm 417 supported_signature_algorithms<2..2^16-2>; 418 DistinguishedName certificate_authorities<0..2^16-1>; 419 } CertificateRequest; 421 where the SignatureAndHashAlgorithm structure is specified in 422 Section 4.2.1.1, the ClientCertificateType and the DistinguishedName 423 structures are specified as follows. 425 enum { 426 gostr34102012_256(238), 427 gostr34102012_512(239), (255) 428 } ClientCertificateType; 430 opaque DistinguishedName<1..2^16-1>; 432 4.2.3. ClientKeyExchange 434 The ClientKeyExchange structure is defined as follows. 436 enum { vko_kdf_gost, vko_gost } KeyExchangeAlgorithm; 438 struct { 439 select (KeyExchangeAlgorithm) { 440 case vko_kdf_gost: PSKeyTransport; 441 case vko_gost: TLSGostKeyTransportBlob; 442 } exchange_keys; 443 } ClientKeyExchange; 445 The PSKeyTransport structure corresponds to the CTR_OMAC cipher 446 suites and is described in Section 4.2.3.1 and the 447 TLSGostKeyTransportBlob corresponds to CNT_IMIT cipher suite and is 448 described in Section 4.2.3.2. 450 4.2.3.1. CTR_OMAC 452 The CTR_OMAC cipher suites use the KExp15 and the KImp15 algorithms 453 defined in Section 5.2 for key wrapping. 455 The export representation of the PS value is calculated as follows. 457 1. The client generates the keys K^EXP_MAC and K^EXP_ENC using the 458 KEG function described in Section 5.3: 460 H = HASH(r_C | r_S); 462 K^EXP_MAC | K^EXP_ENC = KEG(k_eph, Q_S, H). 464 2. The client generates export representation of the premaster 465 secret value PS: 467 IV = H[25..24 + n / 2]; 469 PSExp = KExp15(PS, K^EXP_MAC, K^EXP_ENC, IV). 471 3. The client creates the PSKeyTransport structure that is defined 472 as follows: 474 PSKeyTransport ::= SEQUENCE { 475 PSEXP OCTET STRING, 476 ephemeralPublicKey SubjectPublicKeyInfo 477 } 478 SubjectPublicKeyInfo ::= SEQUENCE { 479 algorithm AlgorithmIdentifier, 480 subjectPublicKey BITSTRING 481 } 482 AlgorithmIdentifier ::= SEQUENCE { 483 algorithm OBJECT IDENTIFIER, 484 parameters ANY OPTIONAL 485 } 487 Here the PSEXP field contains the PSExp value and the 488 ephemeralPublicKey field contains the Q_eph value. 490 After receiving the ClientKeyExchange message the server process it 491 as follows. 493 1. Checks the next three conditions fulfilling and terminates the 494 connection with fatal error if not. 496 o Q_eph is on the same curve as server public key; 498 o Q_eph is not equal to zero point; 500 o q * Q_eph is not equal to zero point. 502 2. Generates the keys K^EXP_MAC and K^EXP_ENC using the KEG function 503 described in Section 5.3: 505 H = HASH(r_C | r_S); 507 K^EXP_MAC | K^EXP_ENC = KEG(k_S, Q_eph, H). 509 3. Extracts the common secret PS from the export representation 510 PSExp: 512 IV = H[25..24+n/2]; 514 PS = KImp15(PSExp, K^EXP_MAC, K^EXP_ENC, IV). 516 4.2.3.2. CNT_IMIT 518 The client generates the key KEK using the VKO function. VKO is one 519 of the functions VKO_GOSTR3410_2012_256 or VKO_GOSTR3410_2012_512 520 described in [RFC7836]. The particular function depends on the 521 elliptic curve used in the server certificate. The KEK calculation 522 is made as follow 524 UKM = HASH(r_C | r_S) 526 KEK = VKO(k_eph, Q_S, UKM) 528 Generates the diversified key KEK(UKM) using the function CryptoPro 529 KEK Diversification Algorithm defined in [RFC4357] 531 Generates export representation of the common secret PS: 533 Compute a 4-byte MAC value, gost28147IMIT (UKM, KEK(UKM), CEK) as 534 described in Section 5.4. Call the result CEK_MAC. 536 Encrypt CEK in ECB mode using KEK(UKM). Call the ciphertext 537 CEK_ENC. 539 The wrapped key is the string UKM | CEK_ENC | CEK_MAC in B_44. 541 The TLSGostKeyTransportBlob is defined as 543 TLSGostKeyTransportBlob ::= SEQUENCE { 544 keyBlob GostR3410-KeyTransport, 545 } 546 GostR3410-KeyTransport ::= 547 SEQUENCE { 548 sessionEncryptedKey Gost28147-89-EncryptedKey, 549 transportParameters [0] IMPLICIT GostR3410-TransportParameters 550 } 551 Gost28147-89-EncryptedKey ::= 552 SEQUENCE { 553 encryptedKey Gost28147-89-Key, 554 macKey Gost28147-89-MAC 555 } 556 GostR3410-TransportParameters ::= 557 SEQUENCE { 558 encryptionParamSet OBJECT IDENTIFIER, 559 ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo, 560 ukm OCTET STRING 561 } 563 The Gost28147-89-EncryptedKey.encryptedKey value contais CEK_ENC 564 value, the Gost28147-89-EncryptedKey.macKey contains CEK_MAC, and 565 GostR3410-TransportParameters.ukm contains the UKM value. 567 There MUST be a keyBlob.transportParameters.ephemeralPublicKey field 568 containing the client ephemeral public key Q_eph. 570 After receiving ClientKeyExchange message server process it as 571 follows 573 o Checks the next four conditions fulfilling and terminates the 574 connection with fatal error if not. 576 1. Q_eph is on the same curve as server public key; 578 2. Q_eph is not equal to zero point; 580 3. q * Q_eph is not equal to zero point; 582 4. Checks if UKM = HASH(r_C | r_S). 584 o Generates the key KEK using the VKO function. 586 KEK = VKO(k_S, Q_eph, UKM). 588 o Generates the diversified key KEK(UKM) using the function 589 CryptoPro KEK Diversification Algorithm defined in [RFC4357] 591 o Extracts the common secret PS from the export representation: 593 Decrypt CEK_ENC in ECB mode using KEK(UKM). Call the result 594 CEK. 596 Compute a 4-byte MAC value, gost28147IMIT (UKM, KEK(UKM), CEK). 597 If the result is not equal to CEK_MAC return a fault value. 599 4.2.4. CertificateVerify 601 The TLS CertificateVerify message is extended as follows. 603 struct { 604 SignatureAndHashAlgorithm algorithm; 605 opaque signature<0..2^16-1>; 606 } CertificateVerify; 608 where SignatureAndHashAlgorithm structure is specified in 609 Section 4.2.1.1. 611 The CertificateVerify.signature field is specified as follows. 613 CertificateVerify.signature = SIGN_{k_C}(handshake_messages) = Str_l(r) | Str_l(s) 615 where SIGN_{k_C} is the GOST R 34.10-2012 [GOST3410-2012] signature 616 algorithm, k_C is a client long-term private key that corresponds to 617 the client long-term public key Q_C from the client's certificate, l 618 = 32 for gostr34102012_256 signature algorithm and l = 64 for 619 gostr34102012_512 signature algorithm. 621 4.3. Cryptographic Algorithms 623 4.3.1. Block Cipher 625 The cipher suite TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC MUST 626 use Kuznyechik [RFC7801] as a base block cipher for the encryption 627 and MAC algorithm. The block length for this suite is 16 bytes and 628 the key length is 32 bytes. The cipher suite 629 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC MUST use Magma 630 [GOST3412-2015] as a base block cipher for the encryption and MAC 631 algorithm. The block length for this suite is 8 bytes and the key 632 length is 32 bytes. 634 The cipher suite TLS_GOSTR341112_256_WITH_28147_CNT_IMIT MUST use 635 GOST 28147-89 as a base block cipher [RFC5830] with the set of 636 parameters id-tc26-gost-28147-param-Z defined in [RFC7836]. The 637 block length for this suite is 8 bytes and the key length is 32 638 bytes. 640 4.3.2. MAC 642 The CTR_OMAC cipher suites use the OMAC message authentication code 643 construction defined in [GOST3413-2015], which can be considered as 644 the CMAC mode defined in [RFC4493] where Kuznyechik or Magma block 645 cipher (see Section 4.3.1) are used instead of AES block cipher (see 646 [IK2003] for more detail) as the MAC function. 648 The CNT_IMIT cipher suite uses the message authentication code 649 function gostIMIT28147 defined in Section 5.4 with the initialization 650 vector IV = IV0, where IV0 in B_8 is a string of all zeros, with the 651 CryptoPro Key Meshing algorithm defined in [RFC4357]. 653 4.3.3. Encryption Algorithm 655 The CTR_OMAC cipher suites use the block cipher in CTR-ACPKM 656 encryption mode defined in [DraftRekeying] as the ENC encryption 657 algorithm. The section size N is 4 KB for 658 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite and 1 KB 659 for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cipher suite. The 660 initial counter nonce is defined as in Section 4.1. 662 The CNT_IMIT cipher suite uses use the block cipher in counter 663 encryption mode (CNT) defined in Section 6 of [RFC5830] with the 664 CryptoPro Key Meshing algorithm defined in [RFC4357] as the ENC 665 encryption algorithm. 667 4.3.4. SNMAX 669 The SNMAX parameter defines the maximal amount of messages that can 670 be send during one TLS 1.2 connection. For 671 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite this amount 672 is 2^64 - 1 messages and for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC 673 is 2^32 - 1 messages. 675 4.3.5. PRF and HASH 677 The pseudorandom function (PRF) for all the cipher suites defined in 678 this document is the PRF_TLS_GOSTR3411_2012_256 function described in 679 [RFC7836]. 681 The hash function Hash for all the cipher suites defined in this 682 document is the GOST R 34.11-2012 [GOST3411-2012] hash algorithm with 683 32-byte (256-bit) hash code. 685 5. Additional Algorithms 687 5.1. TLSTREE 689 The TLSTREE function is defined as follows: 691 TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, Vec(i & C_1)), 692 Vec(i & C_2)), Vec(i & C_2)), 694 where 696 o K_root in B_32; 698 o i in {0, 1, ... , 2^64 - 1}; 700 o C_1, C_2, C_3 are constants defined by the particular cipher suite 701 (see Section 5.1.1); 703 o KDF_j(K, D), j = 1, 2, 3, K in B_32, D in B_8, is the key 704 derivation functions based on the KDF_GOSTR3411_2012_256 function 705 defined in [RFC7836]: 707 KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D); 708 KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D); 709 KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D). 711 5.1.1. Key Tree Parameters 713 The CTR_OMAC cipher suites use the TLSTREE function for the re-keying 714 approach. The constants for it are defined as in the table below. 716 Key tree constants 718 +------------------------------------------+------------------------+ 719 | CipherSuites | C_1, C_2, C_3 | 720 +------------------------------------------+------------------------+ 721 | TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_ | C_1=0xFFFFFFFF00000000 | 722 | OMAC | , C_2=0xFFFFFFFFFFF800 | 723 | | 00, | 724 | | C_3=0xFFFFFFFFFFFFFFC0 | 725 | | | 726 | TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC | C_1=0xFFFFFFC000000000 | 727 | | , C_2=0xFFFFFFFFFE0000 | 728 | | 00, | 729 | | C_3=0xFFFFFFFFFFFFF000 | 730 +------------------------------------------+------------------------+ 732 5.2. KExp15 and KImp15 Algorithms 734 Algorithms KExp15 and KImp15 are keywrap algorithms those provide 735 confidentiality and integrity of keys. These algorithms use the 736 block cipher defined by the particular cipher suite. 738 The inputs of Kexp15 key export algorithm are 740 o key K in V*; 742 o MAC key K^Exp_MAC in B_k; 744 o encryption key K^Exp_ENC in B_k; 746 o IV value in B_{n/2}. 748 The keys K^Exp_MAC and K^Exp_ENC MUST be independent. The export 749 representation of the key K is computed as follows 751 o Compute the MAC value of n byte length: 752 KEYMAC = OMAC(K^Exp_MAC, IV | K), 753 where OMAC(K, M) is a MAC function defined in Section 4.3.2. 755 o Compute the KEXP value: 756 KEXP = encKey | encKeyMac = CTR(K^Exp_ENC, IV, KEYMAC), 757 where |encKey| = |K|, |encKeyMAC| = |KEYMAC|, CTR(K, IV, M) is the 758 counter encryption mode CTR defined in [GOST3413-2015] where s = n 759 which can be considered as the CTR mode defined in [MODES]. 761 o The export representation of key K is the result of the Kexp15 762 algorithm and is defined as 763 KExp15(K, K^Exp_MAC, K^Exp_ENC, IV) = KEXP. 765 The import of key K via KImp15 algorithm is restoring the key K from 766 export representation KEXP with keys K^Exp_MAC and K^Exp_ENC from B_k 767 and value IV from B_{n/2}. This is performed as follows 769 o The string KEXP is decrypted on the key K^Exp_ENC with counter 770 encryption mode CTR. The result of this operation is the string 771 K|KEYMAC. 773 o Compute the MAC value of n byte length: 774 KEYMAC' = OMAC(K^Exp_MAC, IV | K). 776 o If KEYMAC is not equal to KEYMAC' return a fault value. 778 o Otherwise the result of the KImp15 algorithm is defined as 779 KImp15(KEXP, K^KExp_MAC, K^KExp_ENC, IV) and is equal to string K. 781 During the use of one keypair (K^Exp_ENC, K^Exp_MAC) the IV values 782 MUST be unique. For the import of key K with the KImp15 algorithm 783 every IV value MUST be sent with the export key representation or be 784 a preshared value. 786 5.3. KEG Algorithm 788 The KEG algorithm of export key elaboration takes on input private 789 key d, public key Q and string h from B_32. Then it returns the 790 string from B_64. 792 The KEG algorithm is defined by two distinct ways depending on the 793 private key length. 795 If the length of private key d is 64 bytes the KEG algorithm is 796 defined as follows: 798 KEG(d, Q, h) = VKO_512(d, Q, UKM), 800 where VKO_512 is the VKO_GOSTR3410_2012_512 function defined in 801 [RFC7836] and the UKM parameter is equal to r = Int_32(h[1..16]) if r 802 is not equal to 0 and is equal to 1 otherwise. 804 If the length of private key d is 32 bytes the KEG algorithm is 805 defined as follows: 807 KEG(d, Q, h) = KDFTREE_256(K_EXP, "kdf tree", seed, 1), 809 where KDFTREE_256 is the KDF_TREE_GOSTR3411_2012_256 function defined 810 in [RFC7836] and the parameters K_EXP and seed are defined as 812 K_EXP = VKO_256(d, Q, UKM); 813 UKM is equal to r if r is not equal to 0 and is equal to 1 814 otherwise; 816 r = Int_32(h[1..16]); 818 seed = h[17..24], 820 where VKO_256 is the function VKO_GOSTR3410_2012_256 defined in 821 [RFC7836]. 823 5.4. gostIMIT28147 825 gost28147IMIT (IV, K, M) IV in B_8, K in B_32, M in B* is a MAC 826 computation algorithm with 4 bytes output that proceed as follow 828 1. Divide M into 8 byte blocks: M = M_0 | M_1 | ... | M_r. 830 2. Let M' = M_0 (xor) IV | M_1 | M_2 | ... | M_r. 832 3. Compute MAC value with 4 byte length with algorithm described in 833 [RFC5830] using K as key and M' as input. 835 4. The result of MAC computation is the result of gost28147IMIT (IV, 836 K, M) algorithm. 838 6. IANA Considerations 840 IANA has added the following entries in the TLS Cipher Suite 841 Registry: TODO 843 7. Security Considerations 845 8. References 847 8.1. Normative References 849 [DraftRekeying] 850 Smyshlyaev, S., "Re-keying Mechanisms for Symmetric Keys", 851 2018, . 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, 856 DOI 10.17487/RFC2119, March 1997, 857 . 859 [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 860 Cryptographic Algorithms for Use with GOST 28147-89, GOST 861 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 862 Algorithms", RFC 4357, DOI 10.17487/RFC4357, January 2006, 863 . 865 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 866 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 867 2006, . 869 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 870 (TLS) Protocol Version 1.2", RFC 5246, 871 DOI 10.17487/RFC5246, August 2008, 872 . 874 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 875 "Transport Layer Security (TLS) Renegotiation Indication 876 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 877 . 879 [RFC5830] Dolmatov, V., Ed., "GOST 28147-89: Encryption, Decryption, 880 and Message Authentication Code (MAC) Algorithms", 881 RFC 5830, DOI 10.17487/RFC5830, March 2010, 882 . 884 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 885 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 886 2013, . 888 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: 889 Digital Signature Algorithm", RFC 7091, 890 DOI 10.17487/RFC7091, December 2013, 891 . 893 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 894 Langley, A., and M. Ray, "Transport Layer Security (TLS) 895 Session Hash and Extended Master Secret Extension", 896 RFC 7627, DOI 10.17487/RFC7627, September 2015, 897 . 899 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 900 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 901 . 903 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 904 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 905 on the Cryptographic Algorithms to Accompany the Usage of 906 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 907 RFC 7836, DOI 10.17487/RFC7836, March 2016, 908 . 910 8.2. Informative References 912 [GOST28147-89] 913 Government Committee of the USSR for Standards, 914 "Cryptographic Protection for Data Processing System, 915 Gosudarstvennyi Standard of USSR (In Russian)", 916 GOST 28147-89, 1989. 918 [GOST3410-2012] 919 Federal Agency on Technical Regulating and Metrology, 920 "Information technology. Cryptographic data security. 921 Signature and verification processes of [electronic] 922 digital signature", GOST R 34.10-2012, 2012. 924 [GOST3411-2012] 925 Federal Agency on Technical Regulating and Metrology, 926 "Information technology. Cryptographic Data Security. 927 Hashing function", GOST R 34.11-2012, 2012. 929 [GOST3412-2015] 930 Federal Agency on Technical Regulating and Metrology, 931 "Information technology. Cryptographic data security. 932 Block ciphers", GOST R 34.12-2015, 2015. 934 [GOST3413-2015] 935 Federal Agency on Technical Regulating and Metrology, 936 "Information technology. Cryptographic data security. 937 Modes of operation for block ciphers", GOST R 34.13-2015, 938 2015. 940 [IK2003] Iwata T., Kurosawa K. (2003), "OMAC: One-Key CBC MAC.", 941 FSE 2003. Lecture Notes in Computer Science, vol 2887. 942 Springer, Berlin, Heidelberg, 2003. 944 [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of 945 Operation: Methods and Techniques", NIST Special 946 Publication 800-38A, December 2001. 948 Appendix A. Test Examples 950 A.1. Test Examples for CTR_OMAC cipher suites 952 A.2. Test Examples for CNT_IMIT cipher suites 954 Appendix B. Contributors 956 o Evgeny Alekseev 957 CryptoPro 958 alekseev@cryptopro.ru 960 o Ekaterina Smyshlyaeva 961 CryptoPro 962 ess@cryptopro.ru 964 o Grigory Sedov 965 CryptoPro 966 sedovgk@cryptopro.ru 968 o Dmitry Eremin-Solenikov 969 Auriga 970 dbaryshkov@gmail.com 972 Appendix C. Acknowledgments 974 Authors' Addresses 976 Stanislav Smyshlyaev (editor) 977 CryptoPro 978 18, Suschevsky val 979 Moscow 127018 980 Russian Federation 982 Phone: +7 (495) 995-48-20 983 Email: svs@cryptopro.ru 985 Dmitry Belyavsky 986 Cryptocom 987 14/2 Kedrova st 988 Moscow 117218 989 Russian Federation 991 Email: beldmit@gmail.com 992 Markku-Juhani O. Saarinen 993 Independent Consultant 995 Email: mjos@iki.fi