[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         V. Smyslov
Internet-Draft                                                ELVIS-PLUS
Intended status: Informational                              July 5, 2019
Expires: January 6, 2020


                  Using GOST ciphers in ESP and IKEv2
                       draft-smyslov-esp-gost-00

Abstract

   This document defines a set of encryption transforms for use in
   Encapsulating Security Payload (ESP) and Internet Key Exchange
   version 2 (IKEv2) protocols.  The transforms are based on Russian
   cryptographic standard algorithms (GOST) in a Multilinear Galois Mode
   (MGM).

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 January 6, 2020.

Copyright Notice

   Copyright (c) 2019 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Smyslov                  Expires January 6, 2020                [Page 1]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Transforms Description  . . . . . . . . . . . . . . . . . . .   3
     4.1.  Tree-based External Re-Keying . . . . . . . . . . . . . .   4
     4.2.  Initialization Vector Format  . . . . . . . . . . . . . .   5
     4.3.  Nonce Format for MGM  . . . . . . . . . . . . . . . . . .   5
       4.3.1.  MGM Nonce Format for "Kuznyechik" based Transforms  .   6
       4.3.2.  MGM Nonce Format for "Magma" based Transforms . . . .   6
     4.4.  Keying Material . . . . . . . . . . . . . . . . . . . . .   7
     4.5.  Integrity Check Value . . . . . . . . . . . . . . . . . .   7
     4.6.  Plaintext Padding . . . . . . . . . . . . . . . . . . . .   8
     4.7.  AAD Construction  . . . . . . . . . . . . . . . . . . . .   8
       4.7.1.  ESP AAD . . . . . . . . . . . . . . . . . . . . . . .   8
       4.7.2.  IKEv2 AAD . . . . . . . . . . . . . . . . . . . . . .   9
     4.8.  Using Transforms  . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This document defines four encryption transforms for the
   Encapsulating Security Payload (ESP) [RFC4303] and the Internet Key
   Exchange version 2 (IKEv2) [RFC7296].  These transforms are based on
   two block ciphers from Russian cryptographic standard algorithms
   (often called "GOST" algorithms) - "Kuznyechik" [RFC7801] and "Magma"
   [I-D.dolmatov-magma].  These ciphers are used in Multilinear Galois
   Mode (MGM) [I-D.smyshlyaev-mgm] which provides Authenticated
   Encryption with Associated Data (AEAD).  In addition these transforms
   use external re-keying mechanism, described in
   [I-D.irtf-cfrg-re-keying] to limit a load on a session key.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.






Smyslov                  Expires January 6, 2020                [Page 2]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


3.  Overview

   Russian cryptographic standard algorithms, often referred as "GOST"
   algorithms, are a set of cryptographic algorithms of different types
   - ciphers, hash functions, digital signatures etc.  In particular,
   Russian cryptographic standard [GOST3412-2015] defines two block
   ciphers - "Kuznyechik" (also defined in [RFC7801]) and "Magma" (also
   defined in [I-D.dolmatov-magma]).  Both these ciphers use 256-bit
   key.  "Kuznyechik" has a block size of 128 bits, while "Magma" has a
   64-bit block.

   Multilinear Galois Mode (MGM) is an AEAD mode defined in
   [I-D.smyshlyaev-mgm].  It is claimed to provide defense against some
   attacks on well-known AEAD modes, like Galois Counter Mode (GCM).

   In addition, [I-D.irtf-cfrg-re-keying] defines some mechanisms that
   can be used to limit the number of times any particular session key
   is used.  One of these mechanisms, called External Re-Keying with
   Tree-based Construction (defined in Section 5.2.3 of
   [I-D.irtf-cfrg-re-keying]), is used in the defined transforms.  For
   the purpose of deriving subordinate keys a Key Derivation Function
   (KDF) KDF_GOSTR3411_2012_256 defined in Section 4.5 of [RFC7836], is
   used.  This KDF is based on an HMAC [RFC2104] in a combination with a
   Russian GOST hash function defined in Russian cryptographic standard
   [GOST3411-2012] (also defined in [RFC6986]).

4.  Transforms Description

   This document defines four transforms for use in ESP and IKEv2.  All
   of them use MGM mode of operation with Tree-based External Re-Keying.
   The transforms differ in used underlying algorithms and in
   cryptographic services they provide.

   o  ENCR_KUZNYECHIK_MGM_KTREE is an AEAD transform based on
      "Kuznyechik" algorithm; it provides confidentiality and message
      authentication and thus can be used both in ESP and IKEv2; the
      Transform ID is <TBA1 by IANA>;

   o  ENCR_MAGMA_MGM_KTREE is an AEAD transform based on "Magma"
      algorithm; it provides confidentiality and message authentication
      and thus can be used both in ESP and IKEv2; the Transform ID is
      <TBA2 by IANA>

   o  ENCR_KUZNYECHIK_MGM_MAC_KTREE is a MAC-only transform based on
      "Kuznyechik" algorithm; it provides no confidentiality and thus
      can only be used in ESP, but not in IKEv2; the Transform ID is
      <TBA3 by IANA>




Smyslov                  Expires January 6, 2020                [Page 3]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


   o  ENCR_MAGMA_MGM_MAC_KTREE is a MAC-only transform based on "Magma"
      algorithm; it provides no confidentiality and thus can only be
      used in ESP, but not in IKEv2; the Transform ID is <TBA4 by IANA>

4.1.  Tree-based External Re-Keying

   All four transforms use the same Tree-based External Re-Keying
   mechanism.  The idea is that the key that is provided for the
   transform (Child SA key derived from KEYMAT in case of ESP or SK_ei/
   SK_er in case of IKEv2) is not directly use to protect messages.
   Instead a tree of keys is derived using this key as a root.  This
   tree may have several levels.  The leaf keys are used for message
   protection, while intermediate nodes keys are used to derive lower
   level keys (including leaf keys).  See Section 5.2.3 of
   [I-D.irtf-cfrg-re-keying] for more detail.  This construction allows
   to protect a large amount of data, but at the same time providing a
   bound on a number of times any particular key in the tree is used,
   thus defending from some side channel attacks.

   The transforms defined in this document use three-level tree.  The
   leaf key that protects a message is computed as follows:

            Kmsg = KDF (KDF (KDF (K, L1, I1), L2, I2), L3, I3)

   where:

   KDF (k, l, s)   Key Derivation Function KDF_GOSTR3411_2012_256
                   defined in Section 4.5 of [RFC7836], which accepts
                   three input parameters - a key (k), a label (l) and a
                   seed (s) and provides a new key as an output;

   K               the key for the transform (ESP SA key derived from
                   KEYMAT or SK_ei/SK_er in case of IKEv2);

   L1, L2, L3      labels defined as 6 octet ASCII strings without null
                   termination:

                      L1 = "level1"

                      L2 = "level2"

                      L3 = "level3"

   I1, I2, I3      parameters that determine which keys out of the tree
                   are used on each level, altogether they determine a
                   leaf key that is used for message protection; these
                   parameters are two octet integers in network byte
                   order;



Smyslov                  Expires January 6, 2020                [Page 4]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


   This construction allows to generate up to 2^16 keys on each level,
   but due to IV construction (see Section 4.2) the number of possible
   keys on the level 1 is limited to 2^8.  So, the total number of
   possible leaf keys generated from one SA key is 2^40.

   This specifications doesn't any requirements on the frequency the
   external re-keying takes place.  It is expected that sending
   application will follow its own policy dictating how many times the
   keys on each level must be used.

4.2.  Initialization Vector Format

   Each message protected by the defined transforms must contain
   Initialization Vector (IV).  The IV has a size of 64 bits and
   consists of the four fields, three of which are I1, I2 and I3
   parameters that determine the particular leaf key this message was
   protected with (see Section 4.1), and the fourh is a counter,
   representing the message number for this key.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      I1       |               I2              |      I3       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   I3 (cont)   |                      C                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 1: IV Format

   where:

   o  I1 (1 octet), I2 (2 octets), I3 (2 octets) - parameters,
      determining the particular key used to protect this message;
      2-octets parameters are integers in network byte order

   o  C (3 octets) - message counter for the leaf key protecting this
      message; up to 2^24 messages may be protected using a single leaf
      key

   For any given SA the IV MUST NOT repeat, but there is no requirement
   that IV is unpredictable.

4.3.  Nonce Format for MGM

   MGM requires a per-message nonce (called Initial Counter Nonce, ICN,
   in the [I-D.smyshlyaev-mgm]) that must be unique in the context of
   any leaf key (that are used to actually protect messages).  The size
   of the ICN is n-1 bits, where n is the size of the block of the



Smyslov                  Expires January 6, 2020                [Page 5]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


   underlying cipher.  The two ciphers used in the defined transforms
   have different block sizes, so the two formats for the ICN are
   defined.

   MGM specification requires that the nonce be n-1 bits in size, where
   n is a block size of underlying cipher.  This document defines MGM
   nonces that are n bits in size, because that makes them having whole
   number of bytes.  When used inside MGM the most significant bit of
   the first octet if the nonce (represented as an octet string) is
   dropped, making an effective size of the nonce equal to n-1 bits.
   Note, that the dropped bit is a part of zero field (see Figure 2 and
   Figure 3) which is always set to 0, so no information is lost when it
   is dropped.

4.3.1.  MGM Nonce Format for "Kuznyechik" based Transforms

   For transforms based on "Kuznyechik" cipher
   (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the ICN
   consists of a zero octet, a 24-bit message counter and a 96-bit
   secret salt, that is fixed for SA and not transmitted.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     zero      |                      C                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             salt                              |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 2: Nonce format for "Kuznyechik" based transforms

   where:

   o  zero (1 octet) - set to 0

   o  C (3 octets) - the counter for the messages protected by the given
      leaf key; this field MUST be equal to the C field in the IV

   o  salt (12 octets) - secret salt

4.3.2.  MGM Nonce Format for "Magma" based Transforms

   For transforms based on "Magma" cipher (ENCR_MAGMA_MGM_KTREE and
   ENCR_MAGMA_MGM_MAC_KTREE) the ICN consists of a zero octet, a 24-bit
   message counter and a 32-bit secret salt, that is fixed for SA and
   not transmitted.



Smyslov                  Expires January 6, 2020                [Page 6]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     zero      |                      C                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             salt                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 3: Nonce format for "Magma" based transforms

   where:

   o  zero (1 octet) - set to 0

   o  C (3 octets) - the counter for the messages protected by the given
      leaf key; this field MUST be equal to the C field in the IV

   o  salt (4 octets) - secret salt

4.4.  Keying Material

   The key for ENCR_KUZNYECHIK_MGM_KTREE and
   ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits, of
   which the first 256 bits is a root key for the tree (denoted as K in
   Section 4.1) and the remaining 96 bits is a secret salt (see
   Section 4.3.1).

   The key for ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE
   transforms consists of 288 bits, of which the first 256 bits is a
   root key for the tree (denoted as K in Section 4.1) and the remaining
   32 bits is a secret salt (see Section 4.3.2).

   The keys in case ESP are extracted from the KEYMAT, and in case IKEv2
   they are SK_ei/SK_er keys.  Note, that since these transforms provide
   authenticated encryption, no additional keys are needed for
   authentication.  It means that in case of IKEv2 the keys SK_ai/SK_ar
   are not used.

4.5.  Integrity Check Value

   The MGM computes authentication tag equal to the size of the block of
   the underlying cipher.  For "Kuznyechik" based transforms
   (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the
   resulting Integrity Check Value (ICV) is truncated to 96 bits by
   dropping the last 4 octets of the produced authentication tag.  For
   "Magma" based transforms the full 64-bit authentication tag is used
   as ICV.




Smyslov                  Expires January 6, 2020                [Page 7]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


4.6.  Plaintext Padding

   All transforms defined in this document doesn't require any special
   plaintext padding, as specified in [I-D.smyshlyaev-mgm].  It means,
   that only those padding requirements that are imposed by the protocol
   are applied (4 bytes for ESP, no special padding for IKEv2).

4.7.  AAD Construction

4.7.1.  ESP AAD

   Additional Authenticated Data (AAD) in ESP are constructed
   differently depending on the transform being used and whether
   Extended Sequence Number (ESN) is in use or not.  The
   ENCR_KUZNYECHIK_MGM_KTREE and ENCR_MAGMA_MGM_KTREE provide
   confidentiality, so the content of the ESP body is encrypted and AAD
   consists of the ESP SPI and (E)SN.  The AAD is constructed similar to
   the one in [RFC4106].

   On the other hand the ENCR_KUZNYECHIK_MGM_MAC_KTREE and
   ENCR_MAGMA_MGM_MAC_KTREE don't provide confidentiality, they provide
   only message authentication.  For this purpose the part of ESP packet
   that is normally encrypted is included in the AAD instead.  For these
   transforms encryption capability provided by MGM is not used.  The
   AAD is constructed similar to the one in [RFC4543].

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               SPI                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     32-bit Sequence Number                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4: AAD for AEAD transforms with 32-bit SN

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               SPI                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 64-bit Extended Sequence Number               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 5: AAD for AEAD transforms with 64-bit ESN





Smyslov                  Expires January 6, 2020                [Page 8]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               SPI                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     32-bit Sequence Number                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                    Payload Data (variable)                    ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Padding (0-255 bytes)                      |
     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |  Pad Length   | Next Header   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 6: AAD for authentication only transforms with 32-bit SN

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               SPI                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 64-bit Extended Sequence Number               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                    Payload Data (variable)                    ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Padding (0-255 bytes)                      |
     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |  Pad Length   | Next Header   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7: AAD for authentication only transforms with 64-bit ESN

4.7.2.  IKEv2 AAD

   For IKEv2 the AAD consists of the IKEv2 Header, the unencrypted
   payload followed it and an Encrypted (or Encrypted Fragment) payload
   header.  The AAD is constructed similar to one in [RFC5282].









Smyslov                  Expires January 6, 2020                [Page 9]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                         IKEv2 Header                          ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   Unencrypted IKE Payloads                    ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Next Payload  |C|  RESERVED   |         Payload Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 8: AAD for IKEv2

4.8.  Using Transforms

   When SA is established the I1, I2 and I3 parameters are set to 0 by
   the sender and a leaf key is calculated.  The C parameter starts from
   0 and is incremented with each message protected by the same leaf
   key.  When sender decides that the leaf should be changed, it
   increments I3 parameter and generates a new leaf key.  The C
   parameter for the new leaf key is reset to 0 and the process
   continues.  If the sender decides, that 3-rd level key corresponding
   to I3 is used enough times, it increments I2, resets I3 to 0 and
   calculates a new leaf key.  The C is reset to 0 (as with every new
   leaf key) and the process continues.

   The receiver always use I1, I2 and I3 from the incoming message.  If
   they differ from the values in previous packets, a new leaf key is
   calculated . The C parameter is always used from the incoming packet.
   To improve performance implementations may cache recently used leaf
   key.  When new leaf key is calculated (based on the values from
   incoming message) the old key may be cacheed for some time to improve
   performance in case of possible packet reordering (when packets
   protected by the old leaf key may be delayed and arrive later).

5.  Security Considerations

   TBD

6.  IANA Considerations

   IANA has assigned four Transform IDs in the "Transform Type 1 -
   Encryption Algorithm Transform IDs" registry (where RFCXXXX is this
   document):








Smyslov                  Expires January 6, 2020               [Page 10]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


   Number   Name                          ESP Reference  IKEv2 Reference
   ---------------------------------------------------------------------
    TBA1    ENCR_KUZNYECHIK_MGM_KTREE       [RFCXXXX]       [RFCXXXX]
    TBA2    ENCR_MAGMA_MGM_KTREE            [RFCXXXX]       [RFCXXXX]
    TBA3    ENCR_KUZNYECHIK_MGM_MAC_KTREE   [RFCXXXX]      Not allowed
    TBA4    ENCR_MAGMA_MGM_MAC_KTREE        [RFCXXXX]      Not allowed

7.  References

7.1.  Normative References

   [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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [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>.

   [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>.

   [I-D.dolmatov-magma]
              Dolmatov, V. and D. Eremin-Solenikov, "GOST R 34.12-2015:
              Block Cipher "Magma"", draft-dolmatov-magma-01 (work in
              progress), June 2019.

   [I-D.smyshlyaev-mgm]
              Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and S.
              Ekaterina, "Multilinear Galois Mode (MGM)", draft-
              smyshlyaev-mgm-11 (work in progress), June 2019.





Smyslov                  Expires January 6, 2020               [Page 11]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


   [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>.

7.2.  Informative References

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

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

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [I-D.irtf-cfrg-re-keying]
              Smyshlyaev, S., "Re-keying Mechanisms for Symmetric Keys",
              draft-irtf-cfrg-re-keying-17 (work in progress), May 2019.

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)",
              RFC 4106, DOI 10.17487/RFC4106, June 2005,
              <https://www.rfc-editor.org/info/rfc4106>.

   [RFC4543]  McGrew, D. and J. Viega, "The Use of Galois Message
              Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
              DOI 10.17487/RFC4543, May 2006,
              <https://www.rfc-editor.org/info/rfc4543>.

   [RFC5282]  Black, D. and D. McGrew, "Using Authenticated Encryption
              Algorithms with the Encrypted Payload of the Internet Key
              Exchange version 2 (IKEv2) Protocol", RFC 5282,
              DOI 10.17487/RFC5282, August 2008,
              <https://www.rfc-editor.org/info/rfc5282>.








Smyslov                  Expires January 6, 2020               [Page 12]


Internet-Draft         GOST ciphers in ESP & IKEv2             July 2019


Author's Address

   Valery Smyslov
   ELVIS-PLUS
   PO Box 81
   Moscow (Zelenograd)  124460
   RU

   Phone: +7 495 276 0211
   Email: svan@elvis.ru









































Smyslov                  Expires January 6, 2020               [Page 13]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/