GOST Cipher Suites for TLS 1.2
draft-smyshlyaev-tls12-gost-suites-01

Network Working Group                                 S. Smyshlyaev, Ed.
Internet-Draft                                                 CryptoPro
Intended status: Informational                              D. Belyavsky
Expires: December 31, 2018                                     Cryptocom
                                                             M. Saarinen
                                                  Independent Consultant
                                                           June 29, 2018

                     GOST Cipher Suites for TLS 1.2
                 draft-smyshlyaev-tls12-gost-suites-01

Abstract

   This document specifies a set of cipher suites for the Transport
   Layer Security (TLS) protocol Version 1.2 to support the Russian
   cryptographic standard algorithms.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 31, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Smyshlyaev, et al.      Expires December 31, 2018               [Page 1]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  Basic Terms and Definitions . . . . . . . . . . . . . . . . .   3
   4.  Cipher Suite Definitions  . . . . . . . . . . . . . . . . . .   4
     4.1.  Record Payload Protection . . . . . . . . . . . . . . . .   4
       4.1.1.  CTR_OMAC  . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.2.  CNT_IMIT  . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Key Exchange and Authentication . . . . . . . . . . . . .   6
       4.2.1.  Hello Messages  . . . . . . . . . . . . . . . . . . .   8
         4.2.1.1.  Signature Algorithms Extension  . . . . . . . . .   9
       4.2.2.  CertificateRequest  . . . . . . . . . . . . . . . . .   9
       4.2.3.  ClientKeyExchange . . . . . . . . . . . . . . . . . .  10
         4.2.3.1.  CTR_OMAC  . . . . . . . . . . . . . . . . . . . .  11
         4.2.3.2.  CNT_IMIT  . . . . . . . . . . . . . . . . . . . .  12
       4.2.4.  CertificateVerify . . . . . . . . . . . . . . . . . .  14
     4.3.  Cryptographic Algorithms  . . . . . . . . . . . . . . . .  14
       4.3.1.  Block Cipher  . . . . . . . . . . . . . . . . . . . .  14
       4.3.2.  MAC . . . . . . . . . . . . . . . . . . . . . . . . .  15
       4.3.3.  Encryption Algorithm  . . . . . . . . . . . . . . . .  15
       4.3.4.  SNMAX . . . . . . . . . . . . . . . . . . . . . . . .  15
       4.3.5.  PRF and HASH  . . . . . . . . . . . . . . . . . . . .  15
   5.  Additional Algorithms . . . . . . . . . . . . . . . . . . . .  16
     5.1.  TLSTREE . . . . . . . . . . . . . . . . . . . . . . . . .  16
       5.1.1.  Key Tree Parameters . . . . . . . . . . . . . . . . .  16
     5.2.  KExp15 and KImp15 Algorithms  . . . . . . . . . . . . . .  17
     5.3.  KEG Algorithm . . . . . . . . . . . . . . . . . . . . . .  18
     5.4.  gostIMIT28147 . . . . . . . . . . . . . . . . . . . . . .  19
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  21
   Appendix A.  Test Examples  . . . . . . . . . . . . . . . . . . .  22
     A.1.  Test Examples for CTR_OMAC cipher suites  . . . . . . . .  22
     A.2.  Test Examples for CNT_IMIT cipher suites  . . . . . . . .  22
   Appendix B.  Contributors . . . . . . . . . . . . . . . . . . . .  22
   Appendix C.  Acknowledgments  . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

Smyshlyaev, et al.      Expires December 31, 2018               [Page 2]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

1.  Introduction

   This document specifies three new cipher suites for the Transport
   Layer Security (TLS) Protocol Version 1.2 [RFC5246] to support the
   set of Russian cryptographic standard algorithms (called GOST
   algorithms).  All of them use the GOST R 34.11-2012 [GOST3411-2012]
   hash algorithm (the English version can be found in [RFC6986]) and
   the GOST R 34.10-2012 [GOST3410-2012] signature algorithm (the
   English version can be found in [RFC7091]) but use different
   encryption algorithms, so they are divided into two types: the
   CTR_OMAC cipher suites and the CNT_IMIT cipher suite.

   The CTR_OMAC cipher suites use the GOST R 34.12-2015 [GOST3412-2015]
   block ciphers (the English version can be found in [RFC7801]):

      TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC = {0xXX, 0xXX};
      TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC = {0xXX, 0xXX}.

   The CNT_IMIT cipher suites use the GOST 28147-89 [GOST28147-89] block
   cipher (the English version can be found in [RFC5830]):

      TLS_GOSTR341112_256_WITH_28147_CNT_IMIT = {0xXX, 0xXX}.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Basic Terms and Definitions

   This document uses the following terms and definitions for the sets
   and operations on the elements of these sets:

   B*      the set of all byte strings of a finite length (hereinafter
           referred to as strings), including the empty string;

   B_s     The set of byte vectors of size s, s >= 0, for s = 0 the B_s
           set consists of a single empty element of size 0.  If W is an
           element of B_s, then W = (w^1, w^2, ..., w^s), where w^1,
           w^2, ..., w^s are in {0, ... , 255};

   b[i..j] the string b[i..j] = (b_i, b_{i+1}, ... , b_j) in B_{j-i+1}
           where 1<=i<=j<=s and b = (b_1, ... , b_s) in B_s

   |X|     the byte length of the byte string X;

Smyshlyaev, et al.      Expires December 31, 2018               [Page 3]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   A | C   concatenation of strings A and C both belonging to B*, i.e.,
           a string in B_{|A|+|C|}, where the left substring in B_|A| is
           equal to A, and the right substring in B_|C| is equal to C;

   Int_s   the transformation that maps a string a = (a_s, ... , a_1) in
           B_s into the integer Int_s(a) = 256^{s-1} * a_s + ... + 256 *
           a_2 + a_1 (the interpretation of the binary string as an
           integer);

   Vec_s   the transformation inverse to the mapping Int_s (the
           interpretation of an integer as a binary string);

   Str_s   the transformation that maps an integer i = 256^{s-1} * i_s +
           ... + 2 * i_2 + i_1 into the string Str_s(i) = (i_1, ... ,
           i_s) in B_s;

   k       the byte-length of the block cipher key;

   n       the block size of the block cipher (in bytes);

   Q_C     the public key stored in the client's certificate;

   k_C     the private key that corresponds to Q_C key;

   Q_S     the server's public key;

   k_C     the server's private key;

   r_C     the random string that corresponds to ClientHello.random
           field from [RFC5246];

   r_S     the random string that corresponds to ServerHello.random
           field from [RFC5246].

4.  Cipher Suite Definitions

4.1.  Record Payload Protection

   All of the cipher suites described in this document MUST use the
   stream cipher (see Section 4.3.3) to protect records.  The
   TLSCiphertext structure for the CTR_OMAC and CNT_IMIT cipher suits is
   specified in accordance with the GenericStreamCipher case (see
   Section 6.2.3.1 of [RFC5246]):

Smyshlyaev, et al.      Expires December 31, 2018               [Page 4]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   struct {
       ContentType type;
       ProtocolVersion version;
       uint16 length;
       GenericStreamCipher fragment;
   } TLSCiphertext;

   Here TLSCiphertext.fragment is generated as described in
   Section 4.1.1 and Section 4.1.2.

   The connection key material consists of the sender_write_key (either
   the client_write_key or the server_write_key), the
   sender_write_MAC_key (either the client_write_MAC_key or the
   server_write_MAC_key) and the sender_write_IV (either the
   client_write_IV or the server_write_IV) parameters that are generated
   according to section 6.3 of [RFC5246].

4.1.1.  CTR_OMAC

   In case of the CTR_OMAC cipher_suites there is a certain key material
   which is used by the peer to protect a record that corresponds to the
   seqnum sequence number (in the following simply record key material)
   and consist of K_ENC_seqnum, K_MAC_seqnum and IV_seqnum values that
   are calculated using the TLSTREE function defined in Section 5.1 and
   the connection key material:

      K_ENC_seqnum = TLSTREE(sender_write_key, seqnum);

      K_MAC_seqnum = TLSTREE(sender_write_MAC_key, seqnum);

      IV_seqnum = Vec_{n/2}((Int_{n/2}(sender_write_IV) + seqnum) mod
      2^{n*8/2}).

   The TLSCiphertext.fragment that corresponds to the seqnum sequence
   number is equal to the ENCValue_seqnum value that is calculated as
   follows:

   1.  The MAC value (MACValue_seqnum) is generated by the MAC algorithm
   (see Section 4.3.2) similar to Section 6.2.3.1 of [RFC5246] except
   the used MAC key: the sender_write_MAC_key is replaced by the
   K^seqnum_MAC key:

      MACData_seqnum = Str_8(seqnum) | type_seqnum | version_seqnum |
      length_seqnum | fragment_seqnum;

      MACValue_seqnum = MAC(K_MAC_seqnum, MACData_seqnum),

Smyshlyaev, et al.      Expires December 31, 2018               [Page 5]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   where type_seqnum, version_seqnum, length_seqnum, fragment_seqnum are
   the TLSCompressed.type, the TLSCompressed.version, the
   TLSCompressed.length and the TLSCompressed.fragment values of the
   record with the seqnum sequence number.

   2.  The stream cipher ENC (see Section 4.3.3) encrypts the entire
   data with the MACValue as follows:

      ENCData_seqnum = fragment_seqnum | MACValue_seqnum;

      ENCValue_seqnum = ENC( K_ENC_seqnum, IV_seqnum, ENCData_seqnum).

4.1.2.  CNT_IMIT

   In case of the CNT_IMIT cipher_suites the TLSCiphertext.fragment that
   corresponds to the seqnum sequence number is equal to the
   ENCValue_seqnum value that is calculated as follows:

   1.  The MAC value (MACValue_seqnum) is generated by the MAC algorithm
   (see Section 4.3.2) as follows:

      MACData_i = Str_8(i) | type_i | version_i | length_i | fragment_i,
      i in {0, ... , seqnum};

      MACValue_seqnum = MAC(sender_write_MAC_key, MACData_0 | ... |
      MACData_seqnum),

   where type_i, version_i, length_i, fragment_i are the
   TLSCompressed.type, the TLSCompressed.version, the
   TLSCompressed.length and the TLSCompressed.fragment values of the
   record with the i sequence number.

   2.  The stream cipher ENC (see Section 4.3.3) encrypts the entire
   data ENCData_i with the MACValue_i that correspond to the record
   sequence number i with the MACValue as follows:

      ENCData_i = fragment_i | MACValue_i, i in {0, ... , seqnum};

      ENCValue_0 | ... | ENCValue_seqnum = ENC(sender_write_key,
      sender_write_IV, ENCData_0 | ... |ENCData_seqnum).

4.2.  Key Exchange and Authentication

   All of the cipher suites described in this document use ECDH to
   compute the TLS premaster secret.

Smyshlyaev, et al.      Expires December 31, 2018               [Page 6]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

         Client                                               Server

         ClientHello                  -------->
                                                         ServerHello
                                                         Certificate
                                                  CertificateRequest*
                                      <--------      ServerHelloDone
         Certificate*
         ClientKeyExchange
         CertificateVerify*
         [ChangeCipherSpec]
         Finished                     -------->
                                                  [ChangeCipherSpec]
                                      <--------             Finished
         Application Data             <------->     Application Data

   * message is not sent unless client authentication is desired

   Figure 1 shows all messages involved in the TLS key establishment
   protocol (aka full handshake).  A ServerKeyExchange MUST NOT be sent
   (the server's certificate contains all the necessary keying
   information required by the client to arrive at the premaster
   secret).

   The key exchange process consists of the following steps:

   1.  The client generates ECDHE key pair (Q_eph, k_eph), Q_eph is on
       the same curve as the server's long-term public key Q_S.

   2.  The client generates the premaster secret value PS.  The PS value
       is chosen by random from B_32.

   3.  Using k_eph, server long-term public key and some generated nonce
       value the client generates the encryption key for key-wrap
       algorithm and then sends the PS value wrapped with particular
       key-wrap algorithm.

   4.  The client sends its ephemeral public key Q_eph and the wrapped
       PS value in the ClientKeyExchange message.

   5.  The server extract the premaster secret value PS using its long-
       term secret key k_S in accordance with the key wrap algorithm.

   The server side of the channel is always authenticated; the client
   side is optionally authenticated.  The server is authenticated using

Smyshlyaev, et al.      Expires December 31, 2018               [Page 7]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   it's long term private key from the certificate and proving that it
   knows a shared secret.  The client is authenticated when the server
   is checking its signature.

   The proposed cipher suites has direct impact only on the ClientHello,
   the ServerHello, the CertificateRequest, the ClientKeyExchange and
   the CertificateVerify handshake messages, that are described bellow
   in greater detail in terms of the content and processing of these
   messages.

4.2.1.  Hello Messages

   The ClientHello message must meet the following requirements:

   o  The ClientHello.compression_methods field MUST contain exactly one
      byte, set to zero, which corresponds to the "null" compression
      method.

   o  While using cipher CTR_OMAC cipher suites the
      ClientHello.extensions field MUST contain the following three
      extensions: signature_algorithms (see Section 4.2.1.1),
      extended_master_secret (see [RFC7627]), renegotiation_info (see
      [RFC5746]).

   o  While using the CNT_IMIT cipher suite the ClientHello.extensions
      field MUST contain the signature_algorithms (see Section 4.2.1.1)
      extension.  And it is RECOMMENDED to contain the following two
      extensions: extended_master_secret (see [RFC7627]),
      renegotiation_info (see [RFC5746]).

   The ServerHello message must meet the following requirements:

   o  The ServerHello.compression_method field MUST contain exactly one
      byte, set to zero, which corresponds to the "null" compression
      method.

   o  While using the CTR_OMAC cipher suites the ServerHello.extensions
      field MUST contain the following two extensions:
      extended_master_secret (see [RFC7627]), renegotiation_info (see
      [RFC5746]).

   o  While using the CNT_IMIT cipher suite it is RECOMMENDED for the
      ServerHello.extensions field to contain the following two
      extensions: extended_master_secret (see [RFC7627]),
      renegotiation_info (see [RFC5746]).

   Note: If the extended_master_secret extension is agreed, then the
   master secret value MUST be calculated in accordance with [RFC7627].

Smyshlyaev, et al.      Expires December 31, 2018               [Page 8]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

4.2.1.1.  Signature Algorithms Extension

   The signature_algorithms extension is described in Section 7.4.1.4.1
   of (see [RFC5246]) and is specified as follows.

   SignatureAndHashAlgorithm
       supported_signature_algorithms<2..2^16-2>;

   struct {
       HashAlgorithm hash;
       SignatureAlgorithm signature;
   } SignatureAndHashAlgorithm;

   The set of supported hash algorithms is specified as follows:

   enum {
       gostr34112012_256(238),
       gostr34112012_512(239), (255)
   } HashAlgorithm;

   where gostr34112012_256 and gostr34112012_512 values correspond to
   the GOST R 34.11-2012 [GOST3411-2012] hash algorithm with 32-byte
   (256-bit) and 64-byte (512-bit) hash code respectively.

   The set of supported signature algorithms is specified as follows:

   enum {
       gostr34102012_256(238),
       gostr34102012_512(239), (255)
   } SignatureAlgorithm;

   where gostr34102012_256 and gostr34102012_512 values correspond to
   the GOST R 34.10-2012 [GOST3410-2012] signature algorithm with
   32-byte (256-bit) and 64-byte (512-bit) key length respectively.

4.2.2.  CertificateRequest

   When this message is sent: this message is sent when requesting
   client authentication.

   Meaning of this message: the server uses this message to suggest
   acceptable certificates.

Smyshlyaev, et al.      Expires December 31, 2018               [Page 9]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   The TLS CertificateRequest message is extended as follows.

   struct {
       ClientCertificateType certificate_types<1..2^8-1>;
       SignatureAndHashAlgorithm
           supported_signature_algorithms<2..2^16-2>;
       DistinguishedName certificate_authorities<0..2^16-1>;
   } CertificateRequest;

   where the SignatureAndHashAlgorithm structure is specified in
   Section 4.2.1.1, the ClientCertificateType and the DistinguishedName
   structures are specified as follows.

   enum {
       gostr34102012_256(238),
       gostr34102012_512(239), (255)
   } ClientCertificateType;

   opaque DistinguishedName<1..2^16-1>;

4.2.3.  ClientKeyExchange

   The ClientKeyExchange structure is defined as follows.

   enum { vko_kdf_gost, vko_gost } KeyExchangeAlgorithm;

   struct {
       select (KeyExchangeAlgorithm) {
           case vko_kdf_gost: PSKeyTransport;
           case vko_gost: TLSGostKeyTransportBlob;
       } exchange_keys;
   } ClientKeyExchange;

   The PSKeyTransport structure corresponds to the CTR_OMAC cipher
   suites and is described in Section 4.2.3.1 and the
   TLSGostKeyTransportBlob corresponds to CNT_IMIT cipher suite and is
   described in Section 4.2.3.2.

Smyshlyaev, et al.      Expires December 31, 2018              [Page 10]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

4.2.3.1.  CTR_OMAC

   The CTR_OMAC cipher suites use the KExp15 and the KImp15 algorithms
   defined in Section 5.2 for key wrapping.

   The export representation of the PS value is calculated as follows.

   1.  The client generates the keys K^EXP_MAC and K^EXP_ENC using the
   KEG function described in Section 5.3:

      H = HASH(r_C | r_S);

      K^EXP_MAC | K^EXP_ENC = KEG(k_eph, Q_S, H).

   2.  The client generates export representation of the premaster
   secret value PS:

      IV = H[25..24 + n / 2];

      PSExp = KExp15(PS, K^EXP_MAC, K^EXP_ENC, IV).

   3.  The client creates the PSKeyTransport structure that is defined
   as follows:

   PSKeyTransport ::= SEQUENCE {
       PSEXP OCTET STRING,
       ephemeralPublicKey SubjectPublicKeyInfo
   }
   SubjectPublicKeyInfo ::= SEQUENCE {
       algorithm AlgorithmIdentifier,
       subjectPublicKey BITSTRING
   }
   AlgorithmIdentifier ::= SEQUENCE {
       algorithm OBJECT IDENTIFIER,
       parameters ANY OPTIONAL
   }

   Here the PSEXP field contains the PSExp value and the
   ephemeralPublicKey field contains the Q_eph value.

   After receiving the ClientKeyExchange message the server process it
   as follows.

   1.  Checks the next three conditions fulfilling and terminates the
   connection with fatal error if not.

Smyshlyaev, et al.      Expires December 31, 2018              [Page 11]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   o  Q_eph is on the same curve as server public key;

   o  Q_eph is not equal to zero point;

   o  q * Q_eph is not equal to zero point.

   2.  Generates the keys K^EXP_MAC and K^EXP_ENC using the KEG function
   described in Section 5.3:

      H = HASH(r_C | r_S);

      K^EXP_MAC | K^EXP_ENC = KEG(k_S, Q_eph, H).

   3.  Extracts the common secret PS from the export representation
   PSExp:

      IV = H[25..24+n/2];

      PS = KImp15(PSExp, K^EXP_MAC, K^EXP_ENC, IV).

4.2.3.2.  CNT_IMIT

   The client generates the key KEK using the VKO function.  VKO is one
   of the functions VKO_GOSTR3410_2012_256 or VKO_GOSTR3410_2012_512
   described in [RFC7836].  The particular function depends on the
   elliptic curve used in the server certificate.  The KEK calculation
   is made as follow

      UKM = HASH(r_C | r_S)

      KEK = VKO(k_eph, Q_S, UKM)

   Generates the diversified key KEK(UKM) using the function CryptoPro
   KEK Diversification Algorithm defined in [RFC4357]

   Generates export representation of the common secret PS:

      Compute a 4-byte MAC value, gost28147IMIT (UKM, KEK(UKM), CEK) as
      described in Section 5.4.  Call the result CEK_MAC.

      Encrypt CEK in ECB mode using KEK(UKM).  Call the ciphertext
      CEK_ENC.

      The wrapped key is the string UKM | CEK_ENC | CEK_MAC in B_44.

   The TLSGostKeyTransportBlob is defined as

Smyshlyaev, et al.      Expires December 31, 2018              [Page 12]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

  TLSGostKeyTransportBlob ::= SEQUENCE {
      keyBlob               GostR3410-KeyTransport,
  }
  GostR3410-KeyTransport ::=
      SEQUENCE {
          sessionEncryptedKey Gost28147-89-EncryptedKey,
          transportParameters [0] IMPLICIT GostR3410-TransportParameters
  }
  Gost28147-89-EncryptedKey ::=
      SEQUENCE {
          encryptedKey Gost28147-89-Key,
          macKey Gost28147-89-MAC
  }
  GostR3410-TransportParameters ::=
      SEQUENCE {
          encryptionParamSet OBJECT IDENTIFIER,
          ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo,
          ukm OCTET STRING
  }

   The Gost28147-89-EncryptedKey.encryptedKey value contais CEK_ENC
   value, the Gost28147-89-EncryptedKey.macKey contains CEK_MAC, and
   GostR3410-TransportParameters.ukm contains the UKM value.

   There MUST be a keyBlob.transportParameters.ephemeralPublicKey field
   containing the client ephemeral public key Q_eph.

   After receiving ClientKeyExchange message server process it as
   follows

   o  Checks the next four conditions fulfilling and terminates the
      connection with fatal error if not.

      1.  Q_eph is on the same curve as server public key;

      2.  Q_eph is not equal to zero point;

      3.  q * Q_eph is not equal to zero point;

      4.  Checks if UKM = HASH(r_C | r_S).

   o  Generates the key KEK using the VKO function.

         KEK = VKO(k_S, Q_eph, UKM).

   o  Generates the diversified key KEK(UKM) using the function
      CryptoPro KEK Diversification Algorithm defined in [RFC4357]

Smyshlyaev, et al.      Expires December 31, 2018              [Page 13]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   o  Extracts the common secret PS from the export representation:

         Decrypt CEK_ENC in ECB mode using KEK(UKM).  Call the result
         CEK.

         Compute a 4-byte MAC value, gost28147IMIT (UKM, KEK(UKM), CEK).
         If the result is not equal to CEK_MAC return a fault value.

4.2.4.  CertificateVerify

   The TLS CertificateVerify message is extended as follows.

   struct {
       SignatureAndHashAlgorithm algorithm;
       opaque signature<0..2^16-1>;
   } CertificateVerify;

   where SignatureAndHashAlgorithm structure is specified in
   Section 4.2.1.1.

   The CertificateVerify.signature field is specified as follows.

CertificateVerify.signature = SIGN_{k_C}(handshake_messages) = Str_l(r) | Str_l(s)

   where SIGN_{k_C} is the GOST R 34.10-2012 [GOST3410-2012] signature
   algorithm, k_C is a client long-term private key that corresponds to
   the client long-term public key Q_C from the client's certificate, l
   = 32 for gostr34102012_256 signature algorithm and l = 64 for
   gostr34102012_512 signature algorithm.

4.3.  Cryptographic Algorithms

4.3.1.  Block Cipher

   The cipher suite TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC MUST
   use Kuznyechik [RFC7801] as a base block cipher for the encryption
   and MAC algorithm.  The block length for this suite is 16 bytes and
   the key length is 32 bytes.  The cipher suite
   TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC MUST use Magma
   [GOST3412-2015] as a base block cipher for the encryption and MAC
   algorithm.  The block length for this suite is 8 bytes and the key
   length is 32 bytes.

Smyshlyaev, et al.      Expires December 31, 2018              [Page 14]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   The cipher suite TLS_GOSTR341112_256_WITH_28147_CNT_IMIT MUST use
   GOST 28147-89 as a base block cipher [RFC5830] with the set of
   parameters id-tc26-gost-28147-param-Z defined in [RFC7836].  The
   block length for this suite is 8 bytes and the key length is 32
   bytes.

4.3.2.  MAC

   The CTR_OMAC cipher suites use the OMAC message authentication code
   construction defined in [GOST3413-2015], which can be considered as
   the CMAC mode defined in [RFC4493] where Kuznyechik or Magma block
   cipher (see Section 4.3.1) are used instead of AES block cipher (see
   [IK2003] for more detail) as the MAC function.

   The CNT_IMIT cipher suite uses the message authentication code
   function gostIMIT28147 defined in Section 5.4 with the initialization
   vector IV = IV0, where IV0 in B_8 is a string of all zeros, with the
   CryptoPro Key Meshing algorithm defined in [RFC4357].

4.3.3.  Encryption Algorithm

   The CTR_OMAC cipher suites use the block cipher in CTR-ACPKM
   encryption mode defined in [DraftRekeying] as the ENC encryption
   algorithm.  The section size N is 4 KB for
   TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite and 1 KB
   for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC cipher suite.  The
   initial counter nonce is defined as in Section 4.1.

   The CNT_IMIT cipher suite uses use the block cipher in counter
   encryption mode (CNT) defined in Section 6 of [RFC5830] with the
   CryptoPro Key Meshing algorithm defined in [RFC4357] as the ENC
   encryption algorithm.

4.3.4.  SNMAX

   The SNMAX parameter defines the maximal amount of messages that can
   be send during one TLS 1.2 connection.  For
   TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_OMAC cipher suite this amount
   is 2^64 - 1 messages and for TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC
   is 2^32 - 1 messages.

4.3.5.  PRF and HASH

   The pseudorandom function (PRF) for all the cipher suites defined in
   this document is the PRF_TLS_GOSTR3411_2012_256 function described in
   [RFC7836].

Smyshlyaev, et al.      Expires December 31, 2018              [Page 15]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   The hash function Hash for all the cipher suites defined in this
   document is the GOST R 34.11-2012 [GOST3411-2012] hash algorithm with
   32-byte (256-bit) hash code.

5.  Additional Algorithms

5.1.  TLSTREE

   The TLSTREE function is defined as follows:

      TLSTREE(K_root, i) = KDF_3(KDF_2(KDF_1(K_root, Vec(i & C_1)),
      Vec(i & C_2)), Vec(i & C_2)),

   where

   o  K_root in B_32;

   o  i in {0, 1, ... , 2^64 - 1};

   o  C_1, C_2, C_3 are constants defined by the particular cipher suite
      (see Section 5.1.1);

   o  KDF_j(K, D), j = 1, 2, 3, K in B_32, D in B_8, is the key
      derivation functions based on the KDF_GOSTR3411_2012_256 function
      defined in [RFC7836]:

      KDF_1(K, D) = KDF_GOSTR3411_2012_256(K, "level1", D);
      KDF_2(K, D) = KDF_GOSTR3411_2012_256(K, "level2", D);
      KDF_3(K, D) = KDF_GOSTR3411_2012_256(K, "level3", D).

5.1.1.  Key Tree Parameters

   The CTR_OMAC cipher suites use the TLSTREE function for the re-keying
   approach.  The constants for it are defined as in the table below.

Smyshlyaev, et al.      Expires December 31, 2018              [Page 16]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

                            Key tree constants

   +------------------------------------------+------------------------+
   | CipherSuites                             | C_1, C_2, C_3          |
   +------------------------------------------+------------------------+
   | TLS_GOSTR341112_256_WITH_KUZNYECHIK_CTR_ | C_1=0xFFFFFFFF00000000 |
   | OMAC                                     | , C_2=0xFFFFFFFFFFF800 |
   |                                          | 00,                    |
   |                                          | C_3=0xFFFFFFFFFFFFFFC0 |
   |                                          |                        |
   | TLS_GOSTR341112_256_WITH_MAGMA_CTR_OMAC  | C_1=0xFFFFFFC000000000 |
   |                                          | , C_2=0xFFFFFFFFFE0000 |
   |                                          | 00,                    |
   |                                          | C_3=0xFFFFFFFFFFFFF000 |
   +------------------------------------------+------------------------+

5.2.  KExp15 and KImp15 Algorithms

   Algorithms KExp15 and KImp15 are keywrap algorithms those provide
   confidentiality and integrity of keys.  These algorithms use the
   block cipher defined by the particular cipher suite.

   The inputs of Kexp15 key export algorithm are

   o  key K in V*;

   o  MAC key K^Exp_MAC in B_k;

   o  encryption key K^Exp_ENC in B_k;

   o  IV value in B_{n/2}.

   The keys K^Exp_MAC and K^Exp_ENC MUST be independent.  The export
   representation of the key K is computed as follows

   o  Compute the MAC value of n byte length:
      KEYMAC = OMAC(K^Exp_MAC, IV | K),
      where OMAC(K, M) is a MAC function defined in Section 4.3.2.

   o  Compute the KEXP value:
      KEXP = encKey | encKeyMac = CTR(K^Exp_ENC, IV, KEYMAC),
      where |encKey| = |K|, |encKeyMAC| = |KEYMAC|, CTR(K, IV, M) is the
      counter encryption mode CTR defined in [GOST3413-2015] where s = n
      which can be considered as the CTR mode defined in [MODES].

   o  The export representation of key K is the result of the Kexp15
      algorithm and is defined as
      KExp15(K, K^Exp_MAC, K^Exp_ENC, IV) = KEXP.

Smyshlyaev, et al.      Expires December 31, 2018              [Page 17]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   The import of key K via KImp15 algorithm is restoring the key K from
   export representation KEXP with keys K^Exp_MAC and K^Exp_ENC from B_k
   and value IV from B_{n/2}. This is performed as follows

   o  The string KEXP is decrypted on the key K^Exp_ENC with counter
      encryption mode CTR.  The result of this operation is the string
      K|KEYMAC.

   o  Compute the MAC value of n byte length:
      KEYMAC' = OMAC(K^Exp_MAC, IV | K).

   o  If KEYMAC is not equal to KEYMAC' return a fault value.

   o  Otherwise the result of the KImp15 algorithm is defined as
      KImp15(KEXP, K^KExp_MAC, K^KExp_ENC, IV) and is equal to string K.

   During the use of one keypair (K^Exp_ENC, K^Exp_MAC) the IV values
   MUST be unique.  For the import of key K with the KImp15 algorithm
   every IV value MUST be sent with the export key representation or be
   a preshared value.

5.3.  KEG Algorithm

   The KEG algorithm of export key elaboration takes on input private
   key d, public key Q and string h from B_32.  Then it returns the
   string from B_64.

   The KEG algorithm is defined by two distinct ways depending on the
   private key length.

   If the length of private key d is 64 bytes the KEG algorithm is
   defined as follows:

   KEG(d, Q, h) = VKO_512(d, Q, UKM),

   where VKO_512 is the VKO_GOSTR3410_2012_512 function defined in
   [RFC7836] and the UKM parameter is equal to r = Int_32(h[1..16]) if r
   is not equal to 0 and is equal to 1 otherwise.

   If the length of private key d is 32 bytes the KEG algorithm is
   defined as follows:

   KEG(d, Q, h) = KDFTREE_256(K_EXP, "kdf tree", seed, 1),

   where KDFTREE_256 is the KDF_TREE_GOSTR3411_2012_256 function defined
   in [RFC7836] and the parameters K_EXP and seed are defined as

      K_EXP = VKO_256(d, Q, UKM);

Smyshlyaev, et al.      Expires December 31, 2018              [Page 18]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

      UKM is equal to r if r is not equal to 0 and is equal to 1
      otherwise;

      r = Int_32(h[1..16]);

      seed = h[17..24],

   where VKO_256 is the function VKO_GOSTR3410_2012_256 defined in
   [RFC7836].

5.4.  gostIMIT28147

   gost28147IMIT (IV, K, M) IV in B_8, K in B_32, M in B* is a MAC
   computation algorithm with 4 bytes output that proceed as follow

   1.  Divide M into 8 byte blocks: M = M_0 | M_1 | ... | M_r.

   2.  Let M' = M_0 (xor) IV | M_1 | M_2 | ... | M_r.

   3.  Compute MAC value with 4 byte length with algorithm described in
       [RFC5830] using K as key and M' as input.

   4.  The result of MAC computation is the result of gost28147IMIT (IV,
       K, M) algorithm.

6.  IANA Considerations

   IANA has added the following entries in the TLS Cipher Suite
   Registry: TODO

7.  Security Considerations

8.  References

8.1.  Normative References

   [DraftRekeying]
              Smyshlyaev, S., "Re-keying Mechanisms for Symmetric Keys",
              2018, <https://tools.ietf.org/html/
              draft-irtf-cfrg-re-keying-12>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Smyshlyaev, et al.      Expires December 31, 2018              [Page 19]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   [RFC4357]  Popov, V., Kurepkin, I., and S. Leontiev, "Additional
              Cryptographic Algorithms for Use with GOST 28147-89, GOST
              R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
              Algorithms", RFC 4357, DOI 10.17487/RFC4357, January 2006,
              <https://www.rfc-editor.org/info/rfc4357>.

   [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
              AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
              2006, <https://www.rfc-editor.org/info/rfc4493>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
              <https://www.rfc-editor.org/info/rfc5746>.

   [RFC5830]  Dolmatov, V., Ed., "GOST 28147-89: Encryption, Decryption,
              and Message Authentication Code (MAC) Algorithms",
              RFC 5830, DOI 10.17487/RFC5830, March 2010,
              <https://www.rfc-editor.org/info/rfc5830>.

   [RFC6986]  Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
              Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
              2013, <https://www.rfc-editor.org/info/rfc6986>.

   [RFC7091]  Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012:
              Digital Signature Algorithm", RFC 7091,
              DOI 10.17487/RFC7091, December 2013,
              <https://www.rfc-editor.org/info/rfc7091>.

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,
              <https://www.rfc-editor.org/info/rfc7627>.

   [RFC7801]  Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
              "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
              <https://www.rfc-editor.org/info/rfc7801>.

Smyshlyaev, et al.      Expires December 31, 2018              [Page 20]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   [RFC7836]  Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,
              Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines
              on the Cryptographic Algorithms to Accompany the Usage of
              Standards GOST R 34.10-2012 and GOST R 34.11-2012",
              RFC 7836, DOI 10.17487/RFC7836, March 2016,
              <https://www.rfc-editor.org/info/rfc7836>.

8.2.  Informative References

   [GOST28147-89]
              Government Committee of the USSR for Standards,
              "Cryptographic Protection for Data Processing System,
              Gosudarstvennyi Standard of USSR (In Russian)",
              GOST 28147-89, 1989.

   [GOST3410-2012]
              Federal Agency on Technical Regulating and Metrology,
              "Information technology. Cryptographic data security.
              Signature and verification processes of [electronic]
              digital signature", GOST R 34.10-2012, 2012.

   [GOST3411-2012]
              Federal Agency on Technical Regulating and Metrology,
              "Information technology. Cryptographic Data Security.
              Hashing function", GOST R 34.11-2012, 2012.

   [GOST3412-2015]
              Federal Agency on Technical Regulating and Metrology,
              "Information technology. Cryptographic data security.
              Block ciphers", GOST R 34.12-2015, 2015.

   [GOST3413-2015]
              Federal Agency on Technical Regulating and Metrology,
              "Information technology. Cryptographic data security.
              Modes of operation for block ciphers", GOST R 34.13-2015,
              2015.

   [IK2003]   Iwata T., Kurosawa K. (2003), "OMAC: One-Key CBC MAC.",
              FSE 2003. Lecture Notes in Computer Science,  vol 2887.
              Springer, Berlin, Heidelberg, 2003.

   [MODES]    Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: Methods and Techniques", NIST Special
              Publication  800-38A, December 2001.

Smyshlyaev, et al.      Expires December 31, 2018              [Page 21]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

Appendix A.  Test Examples

A.1.  Test Examples for CTR_OMAC cipher suites

A.2.  Test Examples for CNT_IMIT cipher suites

Appendix B.  Contributors

   o  Evgeny Alekseev
      CryptoPro
      alekseev@cryptopro.ru

   o  Ekaterina Smyshlyaeva
      CryptoPro
      ess@cryptopro.ru

   o  Grigory Sedov
      CryptoPro
      sedovgk@cryptopro.ru

   o  Dmitry Eremin-Solenikov
      Auriga
      dbaryshkov@gmail.com

Appendix C.  Acknowledgments

Authors' Addresses

   Stanislav Smyshlyaev (editor)
   CryptoPro
   18, Suschevsky val
   Moscow  127018
   Russian Federation

   Phone: +7 (495) 995-48-20
   Email: svs@cryptopro.ru

   Dmitry Belyavsky
   Cryptocom
   14/2 Kedrova st
   Moscow  117218
   Russian Federation

   Email: beldmit@gmail.com

Smyshlyaev, et al.      Expires December 31, 2018              [Page 22]
Internet-DraGOST Cipher Suites for Transport Layer Security (  June 2018

   Markku-Juhani O. Saarinen
   Independent Consultant

   Email: mjos@iki.fi

Smyshlyaev, et al.      Expires December 31, 2018              [Page 23]