idnits 2.17.1 draft-smyshlyaev-tls12-gost-suites-00.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 are 2 instances of too long lines in the document, the longest one being 11 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 9, 2018) is 2147 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 240, but not defined -- Looks like a reference, but probably isn't: '0' on line 522 == 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 E. Alekseev 4 Intended status: Informational E. Smyshlyaeva 5 Expires: December 11, 2018 G. Sedov 6 CryptoPro 7 June 9, 2018 9 GOST Cipher Suites for TLS 1.2 10 draft-smyshlyaev-tls12-gost-suites-00 12 Abstract 14 This document specifies a set of cipher suites for the Transport 15 Layer Security (TLS) protocol Version 1.2 to support the Russian 16 cryptographic standard algorithms. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 11, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 54 3. Basic Terms and Definitions . . . . . . . . . . . . . . . . . 3 55 4. Cipher Suite Definitions . . . . . . . . . . . . . . . . . . 4 56 4.1. Record Payload Protection . . . . . . . . . . . . . . . . 4 57 4.2. Key Exchange and Authentication . . . . . . . . . . . . . 5 58 4.2.1. Hello Messages . . . . . . . . . . . . . . . . . . . 7 59 4.2.1.1. Signature Algorithms Extension . . . . . . . . . 8 60 4.2.2. CertificateRequest . . . . . . . . . . . . . . . . . 8 61 4.2.3. ClientKeyExchange . . . . . . . . . . . . . . . . . . 9 62 4.2.3.1. CTR_OMAC . . . . . . . . . . . . . . . . . . . . 10 63 4.2.3.2. CNT_IMIT . . . . . . . . . . . . . . . . . . . . 11 64 4.2.4. CertificateVerify . . . . . . . . . . . . . . . . . . 13 65 4.3. Cryptographic Algorithms . . . . . . . . . . . . . . . . 14 66 4.3.1. Block Cipher . . . . . . . . . . . . . . . . . . . . 14 67 4.3.2. MAC . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 4.3.3. Encryption Algorithm . . . . . . . . . . . . . . . . 15 69 4.3.4. SNMAX . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.3.5. Key Tree Parameters . . . . . . . . . . . . . . . . . 15 71 4.3.6. PRF and HASH . . . . . . . . . . . . . . . . . . . . 16 72 5. Additional Algorithms . . . . . . . . . . . . . . . . . . . . 16 73 5.1. TLSTREE . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 5.2. KExp15 and KImp15 Algorithms . . . . . . . . . . . . . . 16 75 5.3. KEG Algorithm . . . . . . . . . . . . . . . . . . . . . . 18 76 5.4. gostIMIT28147 . . . . . . . . . . . . . . . . . . . . . . 18 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 81 8.2. Informative References . . . . . . . . . . . . . . . . . 20 82 Appendix A. Test Examples . . . . . . . . . . . . . . . . . . . 21 83 A.1. Test Examples for TODO . . . . . . . . . . . . . . . . . 21 84 A.2. Test Examples for TODO . . . . . . . . . . . . . . . . . 21 85 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 21 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 This document specifies three new cipher suites for the Transport 91 Layer Security (TLS) Protocol Version 1.2 [RFC5246] to support the 92 set of Russian cryptographic standard algorithms (called GOST 93 algorithms). All of them use the GOST R 34.11-2012 [GOST3411-2012] 94 hash algorithm (the English version can be found in [RFC6986]) and 95 the GOST R 34.10-2012 [GOST3410-2012] signature algorithm (the 96 English version can be found in [RFC7091]) but use different 97 encryption algorithms, so they are divided into two types: the 98 CTR_OMAC cipher suites and the CNT_IMIT cipher suite. 100 The CTR_OMAC cipher suites use the GOST R 34.12-2015 [GOST3412-2015] 101 block ciphers (the English version can be found in [RFC7801]). 103 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xXX, 0xXX}; 104 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xXX, 0xXX}; 106 The CNT_IMIT cipher suites use the GOST 28147-89 [GOST28147-89] block 107 cipher (the English version can be found in [RFC5830]). 109 TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xXX, 0xXX}; 111 2. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Basic Terms and Definitions 119 This document uses the following terms and definitions for the sets 120 and operations on the elements of these sets: 122 B* the set of all byte strings of a finite length (hereinafter 123 referred to as strings), including the empty string; 125 B_s The set of byte vectors of size s, s >= 0, for s = 0 the B_s 126 set consists of a single empty element of size 0. If W is an 127 element of B_s, then W = (w^1, w^2, ..., w^s), where w^1, 128 w^2, ..., w^s are in {0, ... , 255}; 130 b[i..j] the string b[i..j] = (b_i, b_{i+1}, ... , b_j) in B_{j-i+1} 131 where 1<=i<=j<=s and b = (b_1, ... , b_s) in B_s 133 |X| the byte length of the byte string X; 135 A | C concatenation of strings A and C both belonging to B*, i.e., 136 a string in B_{|A|+|C|}, where the left substring in B_|A| is 137 equal to A, and the right substring in B_|C| is equal to C; 139 Int_s the transformation that maps a string a = (a_s, ... , a_1) in 140 B_s into the integer Int_s(a) = 256^{s-1} * a_s + ... + 256 * 141 a_2 + a_1 (the interpretation of the binary string as an 142 integer); 144 Vec_s the transformation inverse to the mapping Int_s (the 145 interpretation of an integer as a binary string); 147 Str_s the transformation that maps an integer i = 256^{s-1} * i_s + 148 ... + 2 * i_2 + i_1 into the string Str_s(i) = (i_1, ... , 149 i_s) in B_s; 151 k the byte-length of the block cipher key; 153 n the block size of the block cipher (in bytes); 155 Q_C the public key stored in the client's certificate; 157 k_C the private key that corresponds to Q_C key; 159 Q_S the server's public key; 161 k_C the server's private key; 163 r_C the random string that corresponds to ClientHello.random 164 field from [RFC5246]; 166 r_S the random string that corresponds to ServerHello.random 167 field from [RFC5246]; 169 4. Cipher Suite Definitions 171 4.1. Record Payload Protection 173 All of the cipher suites described in this document MUST use the 174 stream cipher (see Section 4.3.3) to protect records. 176 The general description of the TLSPlaintext, the TLSCompressed and 177 the TLSCiphertext structures can be found in Sections 6.2.1, 6.2.2 178 и 6.2.3 of [RFC5246]. The TLSCiphertext structure for the 179 CTR_OMAC and CNT_IMIT cipher suits is specified as follows. 181 struct { 182 ContentType type; 183 ProtocolVersion version; 184 uint16 length; 185 opaque fragment[TLSCiphertext.length]; 186 } TLSCiphertext; 188 The TLSCiphertext.fragment that corresponds to the seq_num record 189 sequence number is formed as follows. 191 1. Generate the key material for the current record using the 192 TLSTREE function defined in Section 5.1 and the session key 193 material: sender_write_key (either the client_write_key or the 194 server_write_key), sender_write_MAC_key (either the 195 client_write_MAC_key or the server_write_MAC_key) and 196 sender_write_IV (either the client_write_IV or the 197 server_write_IV): 199 K^{seq_num}_ENC = TLSTREE(sender_write_key, seq_num); 201 K^{seq_num}_MAC = TLSTREE(sender_write_MAC_key, seq_num); 203 IV_{seq_num} = Vec_{n/2}((Int_{n/2}(sender_write_IV) + 204 seq_num) mod 2^{n*8/2}). 206 2. The MAC value (MACValue) is generated by the MAC algorithm (see 207 Section 4.3.2) similar to Section 6.2.3.1 of [RFC5246] except the 208 used MAC key: the sender_write_MAC_key is replaced by the 209 K^{seq_num}_MAC key: 211 MACData = Str_8(seq_num)│TLSCompressed.type | 212 TLSCompressed.version | TLSCompressed.length | 213 TLSCompressed.fragment; 215 MACValue = MAC(K^{seq_num}_MAC, MACData). 217 3. The stream cipher ENC (see Section 4.3.3) encrypts the entire 218 data with the MACValue as follows: 220 TLSCiphertext.fragment = ENC(K^{seq_num}_ENC, IV_{seq_num}, 221 TLSCompressed.fragment | MACValue). 223 4.2. Key Exchange and Authentication 225 All of the cipher suites described in this document use ECDH to 226 compute the TLS premaster secret. 228 Client Server 230 ClientHello --------> 231 ServerHello 232 Certificate 233 CertificateRequest* 234 <-------- ServerHelloDone 235 Certificate* 236 ClientKeyExchange 237 CertificateVerify* 238 [ChangeCipherSpec] 239 Finished --------> 240 [ChangeCipherSpec] 241 <-------- Finished 242 Application Data <-------> Application Data 244 * message is not sent unless client authentication is desired 246 Figure 1 shows all messages involved in the TLS key establishment 247 protocol (aka full handshake). A ServerKeyExchange MUST NOT be sent 248 (the server's certificate contains all the necessary keying 249 information required by the client to arrive at the premaster 250 secret). 252 The key exchange process consists of the following steps: 254 1. The client generates ECDHE key pair (Q_eph, k_eph), Q_eph is on 255 the same curve as the server's long-term public key Q_S. 257 2. The client generates the premaster secret value PS. The PS value 258 is chosen by random from B_32. 260 3. Using k_eph and server long-term public key the client generates 261 the encryption key for key-wrap algorithm and then sends the PS 262 value wrapped with particular key-wrap algorithm. 264 4. The client sends its ephemeral public key Q_eph and the wrapped 265 PS value in the ClientKeyExchange message. 267 5. The server extract the premaster secret value PS using its long- 268 term secret key k_S in accordance with the key wrap algorithm. 270 The server side of the channel is always authenticated; the client 271 side is optionally authenticated. The server is authenticated using 272 it's long term private key from the certificate and proving that it 273 knows a shared secret. The client is authenticated when the server 274 is checking its signature. 276 The proposed cipher suites has direct impact only on the ClientHello, 277 the ServerHello, the CertificateRequest, the ClientKeyExchange and 278 the CertificateVerify handshake messages, that are described bellow 279 in greater detail in terms of the content and processing of these 280 messages. 282 4.2.1. Hello Messages 284 The ClientHello message must meet the following requirements: 286 o The ClientHello.compression_methods field MUST contain exactly one 287 byte, set to zero, which corresponds to the "null" compression 288 method. 290 o While using cipher CTR_OMAC cipher suites the 291 ClientHello.extensions field MUST contain the following three 292 extensions: signature_algorithms (see Section 4.2.1.1), 293 extended_master_secret (see [RFC7627]), renegotiation_info (see 294 [RFC5746]). 296 o While using the CNT_IMIT cipher suite the ClientHello.extensions 297 field MUST contain the signature_algorithms (see Section 4.2.1.1) 298 extension. And it is RECOMMENDED to contain the following two 299 extensions: extended_master_secret (see [RFC7627]), 300 renegotiation_info (see [RFC5746]). 302 The ServerHello message must meet the following requirements: 304 o The ServerHello.compression_method field MUST contain exactly one 305 byte, set to zero, which corresponds to the "null" compression 306 method. 308 o While using the CTR_OMAC cipher suites the ServerHello.extensions 309 field MUST contain the following two extensions: 310 extended_master_secret (see [RFC7627]), renegotiation_info (see 311 [RFC5746]). 313 o While using the CNT_IMIT cipher suite it is RECOMMENDED for the 314 ServerHello.extensions field to contain the following two 315 extensions: extended_master_secret (see [RFC7627]), 316 renegotiation_info (see [RFC5746]). 318 Note: If the extended_master_secret extension is agreed, then the 319 master secret value MUST be calculated in accordance with [RFC7627]. 321 4.2.1.1. Signature Algorithms Extension 323 The signature_algorithms extension is described in Section 7.4.1.4.1 324 of (see [RFC5246]) and is specified as follows. 326 SignatureAndHashAlgorithm 327 supported_signature_algorithms<2..2^16-2>; 329 struct { 330 HashAlgorithm hash; 331 SignatureAlgorithm signature; 332 } SignatureAndHashAlgorithm; 334 The set of supported hash algorithms is specified as follows: 336 enum { 337 gostr34102012_256(238), 338 gostr34102012_512(239), (255) 339 } SignatureAlgorithm; 341 where gostr34112012_256 and gostr34112012_512 values correspond to 342 the GOST R 34.11-2012 [GOST3411-2012] hash algorithm with 32-byte 343 (256-bit) and 64-byte (512-bit) hash code respectively. 345 The set of supported signature algorithms is specified as follows: 347 enum { 348 gostr34102012_256(238), 349 gostr34102012_512(239), (255) 350 } SignatureAlgorithm; 352 where gostr34102012_256 and gostr34102012_512 values correspond to 353 the GOST R 34.10-2012 [GOST3410-2012] signature algorithm with 354 32-byte (256-bit) and 64-byte (512-bit) key length respectively. 356 4.2.2. CertificateRequest 358 When this message is sent: this message is sent when requesting 359 client authentication. 361 Meaning of this message: the server uses this message to suggest 362 acceptable certificates. 364 The TLS CertificateRequest message is extended as follows. 366 struct { 367 ClientCertificateType certificate_types<1..2^8-1>; 368 SignatureAndHashAlgorithm 369 supported_signature_algorithms<2..2^16-2>; 370 DistinguishedName certificate_authorities<0..2^16-1>; 371 } CertificateRequest; 373 where the SignatureAndHashAlgorithm structure is specified in 374 Section 4.2.1.1, the ClientCertificateType and the DistinguishedName 375 structures are specified as follows. 377 enum { 378 gostr34102012_256(238), 379 gostr34102012_512(239), (255) 380 } ClientCertificateType; 382 opaque DistinguishedName<1..2^16-1>; 384 4.2.3. ClientKeyExchange 386 Client performs the following actions to create the ClientKeyExchange 387 message: 389 o Generates ECDHE key pair (Q_eph, k_eph), Q_eph is on the same 390 curve as the server's long-term public key Q_S. 392 o Chooses randomly a premaster secret value PS from B_32; 394 o Creates the export representation of the PS value using some key 395 wrap function. 397 The ClientKeyExchange structure is defined as follows. 399 enum { VKO_KDF_GOST, vko_gost } KeyExchangeAlgorithm; 401 struct { 402 select (KeyExchangeAlgorithm) { 403 case VKO_KDF_GOST: PSKeyTransport; 404 case vko_gost: TLSGostKeyTransportBlob; 405 } exchange_keys; 406 } ClientKeyExchange; 408 The PSKeyTransport structure corresponds to the CTR_OMAC cipher 409 suites and is described in Section 4.2.3.1 and the 410 TLSGostKeyTransportBlob corresponds to CNT_IMIT cipher suite and is 411 described in Section 4.2.3.2. 413 4.2.3.1. CTR_OMAC 415 The CTR_OMAC cipher suites use the KExp15 and the KImp15 algorithms 416 defined in Section 5.2 for key wrapping. 418 The export representation of the PS value is calculated as follows. 420 1. The client generates the keys K^EXP_MAC and K^EXP_ENC using the 421 KEG function described in Section 5.3: 423 H = HASH(r_C | r_S); 425 K^EXP_MAC | K^EXP_ENC = KEG(k_eph, Q_S, H). 427 2. The client generates export representation of the premaster 428 secret value PS: 430 IV = H[25..24 + n / 2]; 432 PSExp = KExp15(PS, K^EXP_MAC, K^EXP_ENC, IV). 434 3. The client creates the PSKeyTransport structure that is defined 435 as follows: 437 PSKeyTransport ::= SEQUENCE { 438 PSEXP OCTET STRING, 439 ephemeralPublicKey SubjectPublicKeyInfo 440 } 441 SubjectPublicKeyInfo ::= SEQUENCE { 442 algorithm AlgorithmIdentifier, 443 subjectPublicKey BITSTRING 444 } 445 AlgorithmIdentifier ::= SEQUENCE { 446 algorithm OBJECT IDENTIFIER, 447 parameters ANY OPTIONAL 448 } 450 Here the PSEXP field contains the PSExp value and the 451 ephemeralPublicKey field contains the Q_eph value. 453 After receiving the ClientKeyExchange message the server process it 454 as follows. 456 1. Checks the next three conditions fulfilling and terminates the 457 connection with fatal error if not. 459 o Q_eph is on the same curve as server public key; 461 o Q_eph is not equal to zero point; 463 o q * Q_eph is not equal to zero point. 465 2. Generates the keys K^EXP_MAC and K^EXP_ENC using the KEG function 466 described in Section 5.3: 468 H = HASH(r_C | r_S); 470 K^EXP_MAC | K^EXP_ENC = KEG(k_S, Q_eph, H). 472 3. Extracts the common secret PS from the export representation 473 PSExp: 475 IV = H[25..24+n/2]; 477 PS = KImp15(PSExp, K^EXP_MAC, K^EXP_ENC, IV). 479 4.2.3.2. CNT_IMIT 481 The client generates the key KEK using the VKO function. VKO is one 482 of the functions VKO_GOSTR3410_2012_256 or VKO_GOSTR3410_2012_512 483 described in [RFC7836]. The particular function depends on the 484 elliptic curve used in the server certificate. The KEK calculation 485 is made as follow 487 UKM = HASH(r_C | r_S) 489 KEK = VKO(k_eph, Q_S, UKM) 491 Generates the diversified key KEK(UKM) using the function CryptoPro 492 KEK Diversification Algorithm defined in [RFC4357] 494 Generates export representation of the common secret PS: 496 Compute a 4-byte MAC value, gost28147IMIT (UKM, KEK(UKM), CEK) as 497 described in Section 5.4. Call the result CEK_MAC. 499 Encrypt CEK in ECB mode using KEK(UKM). Call the ciphertext 500 CEK_ENC. 502 The wrapped key is the string UKM | CEK_ENC | CEK_MAC in B_44. 504 The TLSGostKeyTransportBlob is defined as 506 TLSGostKeyTransportBlob ::= SEQUENCE { 507 keyBlob GostR3410-KeyTransport, 508 } 509 GostR3410-KeyTransport ::= 510 SEQUENCE { 511 sessionEncryptedKey Gost28147-89-EncryptedKey, 512 transportParameters [0] IMPLICIT GostR3410-TransportParameters OPTIONAL 513 } 514 Gost28147-89-EncryptedKey ::= 515 SEQUENCE { 516 encryptedKey Gost28147-89-Key, 517 macKey Gost28147-89-MAC 518 } 519 GostR3410-TransportParameters ::= 520 SEQUENCE { 521 encryptionParamSet OBJECT IDENTIFIER, 522 ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, 523 ukm OCTET STRING 524 } 526 The Gost28147-89-EncryptedKey.encryptedKey value contais CEK_ENC 527 value, the Gost28147-89-EncryptedKey.macKey contains CEK_MAC, and 528 GostR3410-TransportParameters.ukm contains the UKM value. 530 There MUST be a keyBlob.transportParameters.ephemeralPublicKey field 531 containing the client ephemeral public key Q_eph. 533 After receiving ClientKeyExchange message server process it as 534 follows 536 o Checks the next four conditions fulfilling and terminates the 537 connection with fatal error if not. 539 1. Q_eph is on the same curve as server public key; 541 2. Q_eph is not equal to zero point; 543 3. q * Q_eph is not equal to zero point. 545 4. Checks if UKM = HASH(r_C | r_S) 547 o Generates the key KEK using the VKO function. 549 KEK = VKO(k_S, Q_eph, UKM) 551 o Generates the diversified key KEK(UKM) using the function 552 CryptoPro KEK Diversification Algorithm defined in [RFC4357] 554 o Extracts the common secret PS from the export representation: 556 Decrypt CEK_ENC in ECB mode using KEK(UKM). Call the result 557 CEK. 559 Compute a 4-byte MAC value, gost28147IMIT (UKM, KEK(UKM), CEK). 560 If the result is not equal to CEK_MAC return a fault value. 562 4.2.4. CertificateVerify 564 The TLS CertificateVerify message is extended as follows. 566 struct { 567 SignatureAndHashAlgorithm algorithm; 568 opaque signature<0..2^16-1>; 569 } CertificateVerify; 571 where SignatureAndHashAlgorithm structure is specified in 572 Section 4.2.1.1. 574 The CertificateVerify.signature field is specified as follows. 576 CertificateVerify.signature = SIGN_{k_C}(handshake_messages) = Str_l(r) || Str_l(s) 578 where SIGN_{k_C} is the GOST R 34.10-2012 [GOST3410-2012] signature 579 algorithm, k_C is a client long-term private key that corresponds to 580 the client long-term public key Q_C from the client's certificate, l 581 = 32 for gostr34102012_256 signature algorithm and l = 64 for 582 gostr34102012_512 signature algorithm. 584 4.3. Cryptographic Algorithms 586 4.3.1. Block Cipher 588 The cipher suite TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC MUST 589 use Kuznyechik [RFC7801] as a base block cipher for the encryption 590 and MAC algorithm. The block length for this suite is 16 bytes and 591 the key length is 32 bytes. The cipher suite 592 TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC MUST use Magma 593 [GOST3412-2015] as a base block cipher for the encryption and MAC 594 algorithm. The block length for this suite is 8 bytes and the key 595 length is 32 bytes. 597 The cipher suite TLS_GOSTR341112_256_WITH_28147_CNT_IMIT MUST use 598 GOST 28147-89 as a base block cipher [RFC5830] with the set of 599 parameters id-tc26-gost-28147-param-Z defined in [RFC7836]. The 600 block length for this suite is 8 bytes and the key length is 32 601 bytes. 603 4.3.2. MAC 605 Both CTR_OMAC cipher suites use the MAC construction as defined in 606 [GOST3413-2015]. 608 The CNT_IMIT cipher suite uses the MAC construction defined in 609 [RFC5830] with CryptoPro Key Meshing algorithm defined in [RFC4357] 610 as follows. The MAC value MAC(K, M_t) for the message M_t is 611 calculated with accordance to the next formula 613 MAC(K, M_t) = gostIMIT28147_MESH(IV0, K, M_0 | M_1 | ... | M_t) 615 Here gostIMIT28147_MESH(IV, K, M) is the gostIMIT28147(IV, K, M) 616 function defined in Section 5.4 with CryptoPro Key Meshing algorithm 617 defined in [RFC4357] and IV0 in B_8 is a string of all zeroes 619 4.3.3. Encryption Algorithm 621 Both CTR_OMAC cipher suites use the block cipher in CTR-ACPKM mode 622 defined in [DraftRekeying]. The section size is 4 KB for 623 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite and 1 KB 624 for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cipher suite. The 625 initial counter nonce is defined as in Section 4.1. 627 The CNT_IMIT cipher suite uses the counter mode construction defined 628 in [RFC5830] with CryptoPro Key Meshing algorithm defined in 629 [RFC4357]. The encryption of the record M_t is performed with 630 accordance to the next formula 632 ENC(M_0) | ENC(M_1) | ... | ENC(M_t) = CNT_MESH(M_0 | M_1 | ... | 633 M_t) 635 Here ENC(M_i) denotes the encryption of Record with number i and 636 CNT_MESH denotes counter mode defined in [RFC5830] with CryptoPro Key 637 Meshing algorithm defined in [RFC4357]. 639 4.3.4. SNMAX 641 The SNMAX parameter defines the maximal amount of messages that can 642 be send during one TLS 1.2 connection. For 643 TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite this amount 644 is 2^64 - 1 messages and for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC 645 is 2^32 - 1 messages. 647 4.3.5. Key Tree Parameters 649 The CTR_OMAC cipher suites use the TLSTREE function for the re-keying 650 approach. The constants for it are defined as in the table below. 652 Key tree constants 654 +------------------------------------------+------------------------+ 655 | CipherSuites | C_1, C_2, C_3 | 656 +------------------------------------------+------------------------+ 657 | TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_ | C_1=0xFFFFFFFF00000000 | 658 | OMAC | , C_2=0xFFFFFFFFFFF800 | 659 | | 00, | 660 | | C_3=0xFFFFFFFFFFFFFFC0 | 661 | | | 662 | TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC | C_1=0xFFFFFFC000000000 | 663 | | , C_2=0xFFFFFFFFFE0000 | 664 | | 00, | 665 | | C_3=0xFFFFFFFFFFFFF000 | 666 +------------------------------------------+------------------------+ 668 4.3.6. PRF and HASH 670 The pseudorandom function (PRF) for all the cipher suites defined in 671 this document is the PRF_TLS_GOSTR3411_2012_256 function described in 672 [RFC7836]. 674 The hash function Hash for all the cipher suites defined in this 675 document is the GOST R 34.11-2012 [GOST3411-2012] hash algorithm with 676 32-byte (256-bit) hash code. 678 5. Additional Algorithms 680 5.1. TLSTREE 682 The TLSTREE function is defined as follows: 684 TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, Vec(i & C_1)), 685 Vec(i & C_2)), Vec(i & C_2)) 687 where 689 o K_root in B_32; 691 o i in {0, 1, ... , 2^64 - 1}; 693 o C_1, C_2, C_3 are constants defined by the particular cipher suite 694 (see Section 4.3.5); 696 o KDF_j(K, D), j = 1, 2, 3, K in B_32, D in B_8, is the key 697 derivation functions based on the KDF_GOSTR3411_2012_256 function 698 defined in [RFC7836]: 700 KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D); 701 KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D); 702 KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D). 704 5.2. KExp15 and KImp15 Algorithms 706 Algorithms KExp15 and KImp15 are keywrap algorithms those provide 707 confidentiality and integrity of keys. These algorithms use the 708 block cipher defined by the particular cipher suite. 710 The inputs of Kexp15 key export algorithm are 712 o Key K in V* 714 o MAC key K^Exp_MAC in B_k 715 o Encryption key K^Exp_ENC in B_k 717 o IV value in B_{n/2} 719 The keys K^Exp_MAC and K^Exp_ENC MUST be independent. The export 720 representation of the key K is computed as follows 722 o Compute the MAC value of n byte length 724 KEYMAC = OMAC(K^Exp_MAC, IV | K) 726 where OMAC(K, M) is a MAC function defined in [GOST3413-2015]. 728 o Compute the KEXP value 730 KEXP = encKey | encKeyMac = CTR(K^Exp_ENC, IV, KEYMAC) 732 where |encKey| = |K|, |encKeyMAC| = |KEYMAC|, CTR(K, IV, M) is the 733 counter encryption mode defined in [GOST3413-2015] where s = n. 735 o The export representation of key K is the result of algorithm 736 Kexp15 and is defined as 738 KExp15(K, K^Exp_MAC, K^Exp_ENC, IV) = KEXP. 740 The import of key K via KImp15 algorithm is restoring the key K from 741 export representation KEXP with keys K^Exp_MAC and K^Exp_ENC from B_k 742 and value IV from B_{n/2}. This is performed as follows 744 o The string KEXP is decrypted on the key K^Exp_ENC with counter 745 encryption mode defined in [GOST3413-2015] where s = n. The 746 result of this operation is the string K|KEYMAC. 748 o Compute the MAC value of n byte length 750 KEYMAC' = OMAC(K^Exp_MAC, IV | K). 752 o If KEYMAC is not equal to KEYMAC' return a fault value. 754 o Otherwise the result of the KImp15 algorithm is defined as 755 KImp15(KEXP, K^KExp_MAC, K^KExp_ENC, IV) and is equal to string K. 757 During the use of one keypair (K^Exp_ENC, K^Exp_MAC) the IV values 758 MUST be unique. For the import of key K with the KImp15 algorithm 759 every IV value MUST be sent with the export key representation or be 760 a preshared value. 762 5.3. KEG Algorithm 764 The KEG algorithm of export key elaboration takes on input private 765 key d, public key Q and string h from B_32. Then it returns the 766 string from B_64. 768 The KEG algorithm is defined by two distinct ways depending on the 769 private key length. 771 If the length of private key d is 64 bytes the KEG algorithm is 772 defined as 774 KEG(d, Q, h) = VKO_512(d, Q, UKM) 776 where VKO_512 is the function VKO_GOSTR3410_2012_512 defined in 777 [RFC7836] and the UKM parameter is equal to r = Int_32(h[1..16]) if r 778 is not equal to 0 and is equal to 1 otherwise. 780 If the length of private key d is 32 bytes the KEG algorithm is 781 defined as 783 KEG(d, Q, h) = KDFTREE_256(K_EXP, "kdf tree", seed, 1) 785 where KDFTREE_256 is the function KDF_TREE_GOSTR3411_2012_256 defined 786 in [RFC7836] and the parameters K_EXP and seed are defined as 788 K_EXP = VKO_256(d, Q, UKM) 790 UKM is equal to r if r is not equal to 0 and is equal to 1 791 otherwise 793 r = Int_32(h[1..16]) 795 seed = h[17..24] 797 where VKO_256 is the function VKO_GOSTR3410_2012_256 defined in 798 [RFC7836] . 800 5.4. gostIMIT28147 802 gost28147IMIT (IV, K, M) IV in B_8, K in B_32, M in B* is a MAC 803 computation algorithm with 4 bytes output that proceed as follow 804 1. Divide M into 8 byte blocks: M = M_0 | M_1 | ... | M_r 806 2. Let M' = M_0 (xor) IV | M_1 | M_2 | ... | M_r 808 3. Compute MAC value with 4 byte length with algorithm described in 809 [RFC5830] using K as key and M' as input. 811 4. The result of MAC computation is the result of gost28147IMIT (IV, 812 K, M) algorithm. 814 6. IANA Considerations 816 IANA has added the following entries in the TLS Cipher Suite 817 Registry: TODO 819 7. Security Considerations 821 TODO 823 8. References 825 8.1. Normative References 827 [DraftRekeying] 828 Smyshlyaev, S., "Re-keying Mechanisms for Symmetric Keys", 829 2018, . 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, 834 DOI 10.17487/RFC2119, March 1997, 835 . 837 [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 838 Cryptographic Algorithms for Use with GOST 28147-89, GOST 839 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 840 Algorithms", RFC 4357, DOI 10.17487/RFC4357, January 2006, 841 . 843 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 844 (TLS) Protocol Version 1.2", RFC 5246, 845 DOI 10.17487/RFC5246, August 2008, 846 . 848 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 849 "Transport Layer Security (TLS) Renegotiation Indication 850 Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, 851 . 853 [RFC5830] Dolmatov, V., Ed., "GOST 28147-89: Encryption, Decryption, 854 and Message Authentication Code (MAC) Algorithms", 855 RFC 5830, DOI 10.17487/RFC5830, March 2010, 856 . 858 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 859 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 860 2013, . 862 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: 863 Digital Signature Algorithm", RFC 7091, 864 DOI 10.17487/RFC7091, December 2013, 865 . 867 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 868 Langley, A., and M. Ray, "Transport Layer Security (TLS) 869 Session Hash and Extended Master Secret Extension", 870 RFC 7627, DOI 10.17487/RFC7627, September 2015, 871 . 873 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 874 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 875 . 877 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 878 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 879 on the Cryptographic Algorithms to Accompany the Usage of 880 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 881 RFC 7836, DOI 10.17487/RFC7836, March 2016, 882 . 884 8.2. Informative References 886 [GOST28147-89] 887 Government Committee of the USSR for Standards, 888 "Cryptographic Protection for Data Processing System, 889 Gosudarstvennyi Standard of USSR (In Russian)", 890 GOST 28147-89, 1989. 892 [GOST3410-2012] 893 Federal Agency on Technical Regulating and Metrology, 894 "Information technology. Cryptographic data security. 895 Signature and verification processes of [electronic] 896 digital signature", GOST R 34.10-2012, 2012. 898 [GOST3411-2012] 899 Federal Agency on Technical Regulating and Metrology, 900 "Information technology. Cryptographic Data Security. 901 Hashing function", GOST R 34.11-2012, 2012. 903 [GOST3412-2015] 904 Federal Agency on Technical Regulating and Metrology, 905 "Information technology. Cryptographic data security. 906 Block ciphers", GOST R 34.12-2015, 2015. 908 [GOST3413-2015] 909 Federal Agency on Technical Regulating and Metrology, 910 "Information technology. Cryptographic data security. 911 Modes of operation for block ciphers", GOST R 34.13-2015, 912 2015. 914 Appendix A. Test Examples 916 A.1. Test Examples for TODO 918 A.2. Test Examples for TODO 920 Appendix B. Acknowledgments 922 We thank TODO for their useful comments. 924 Authors' Addresses 926 Stanislav Smyshlyaev (editor) 927 CryptoPro 928 18, Suschevsky val 929 Moscow 127018 930 Russian Federation 932 Phone: +7 (495) 995-48-20 933 Email: svs@cryptopro.ru 935 Evgeny Alekseev 936 CryptoPro 937 18, Suschevsky val 938 Moscow 127018 939 Russian Federation 941 Phone: +7 (495) 995-48-20 942 Email: alekseev@cryptopro.ru 943 Ekaterina Smyshlyaeva 944 CryptoPro 945 18, Suschevsky val 946 Moscow 127018 947 Russian Federation 949 Phone: +7 (495) 995-48-20 950 Email: ess@cryptopro.ru 952 Grigory Sedov 953 CryptoPro 954 18, Suschevsky val 955 Moscow 127018 956 Russian Federation 958 Phone: +7 (495) 995-48-20 959 Email: sedovgk@cryptopro.ru