idnits 2.17.1 draft-smyslov-esp-gost-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2019) is 1750 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 476, but not defined == Outdated reference: A later version (-06) exists of draft-dolmatov-magma-01 == Outdated reference: A later version (-20) exists of draft-smyshlyaev-mgm-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Informational July 5, 2019 5 Expires: January 6, 2020 7 Using GOST ciphers in ESP and IKEv2 8 draft-smyslov-esp-gost-00 10 Abstract 12 This document defines a set of encryption transforms for use in 13 Encapsulating Security Payload (ESP) and Internet Key Exchange 14 version 2 (IKEv2) protocols. The transforms are based on Russian 15 cryptographic standard algorithms (GOST) in a Multilinear Galois Mode 16 (MGM). 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 January 6, 2020. 35 Copyright Notice 37 Copyright (c) 2019 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Transforms Description . . . . . . . . . . . . . . . . . . . 3 56 4.1. Tree-based External Re-Keying . . . . . . . . . . . . . . 4 57 4.2. Initialization Vector Format . . . . . . . . . . . . . . 5 58 4.3. Nonce Format for MGM . . . . . . . . . . . . . . . . . . 5 59 4.3.1. MGM Nonce Format for "Kuznyechik" based Transforms . 6 60 4.3.2. MGM Nonce Format for "Magma" based Transforms . . . . 6 61 4.4. Keying Material . . . . . . . . . . . . . . . . . . . . . 7 62 4.5. Integrity Check Value . . . . . . . . . . . . . . . . . . 7 63 4.6. Plaintext Padding . . . . . . . . . . . . . . . . . . . . 8 64 4.7. AAD Construction . . . . . . . . . . . . . . . . . . . . 8 65 4.7.1. ESP AAD . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.7.2. IKEv2 AAD . . . . . . . . . . . . . . . . . . . . . . 9 67 4.8. Using Transforms . . . . . . . . . . . . . . . . . . . . 10 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 7.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 This document defines four encryption transforms for the 78 Encapsulating Security Payload (ESP) [RFC4303] and the Internet Key 79 Exchange version 2 (IKEv2) [RFC7296]. These transforms are based on 80 two block ciphers from Russian cryptographic standard algorithms 81 (often called "GOST" algorithms) - "Kuznyechik" [RFC7801] and "Magma" 82 [I-D.dolmatov-magma]. These ciphers are used in Multilinear Galois 83 Mode (MGM) [I-D.smyshlyaev-mgm] which provides Authenticated 84 Encryption with Associated Data (AEAD). In addition these transforms 85 use external re-keying mechanism, described in 86 [I-D.irtf-cfrg-re-keying] to limit a load on a session key. 88 2. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in BCP 93 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 3. Overview 98 Russian cryptographic standard algorithms, often referred as "GOST" 99 algorithms, are a set of cryptographic algorithms of different types 100 - ciphers, hash functions, digital signatures etc. In particular, 101 Russian cryptographic standard [GOST3412-2015] defines two block 102 ciphers - "Kuznyechik" (also defined in [RFC7801]) and "Magma" (also 103 defined in [I-D.dolmatov-magma]). Both these ciphers use 256-bit 104 key. "Kuznyechik" has a block size of 128 bits, while "Magma" has a 105 64-bit block. 107 Multilinear Galois Mode (MGM) is an AEAD mode defined in 108 [I-D.smyshlyaev-mgm]. It is claimed to provide defense against some 109 attacks on well-known AEAD modes, like Galois Counter Mode (GCM). 111 In addition, [I-D.irtf-cfrg-re-keying] defines some mechanisms that 112 can be used to limit the number of times any particular session key 113 is used. One of these mechanisms, called External Re-Keying with 114 Tree-based Construction (defined in Section 5.2.3 of 115 [I-D.irtf-cfrg-re-keying]), is used in the defined transforms. For 116 the purpose of deriving subordinate keys a Key Derivation Function 117 (KDF) KDF_GOSTR3411_2012_256 defined in Section 4.5 of [RFC7836], is 118 used. This KDF is based on an HMAC [RFC2104] in a combination with a 119 Russian GOST hash function defined in Russian cryptographic standard 120 [GOST3411-2012] (also defined in [RFC6986]). 122 4. Transforms Description 124 This document defines four transforms for use in ESP and IKEv2. All 125 of them use MGM mode of operation with Tree-based External Re-Keying. 126 The transforms differ in used underlying algorithms and in 127 cryptographic services they provide. 129 o ENCR_KUZNYECHIK_MGM_KTREE is an AEAD transform based on 130 "Kuznyechik" algorithm; it provides confidentiality and message 131 authentication and thus can be used both in ESP and IKEv2; the 132 Transform ID is ; 134 o ENCR_MAGMA_MGM_KTREE is an AEAD transform based on "Magma" 135 algorithm; it provides confidentiality and message authentication 136 and thus can be used both in ESP and IKEv2; the Transform ID is 137 139 o ENCR_KUZNYECHIK_MGM_MAC_KTREE is a MAC-only transform based on 140 "Kuznyechik" algorithm; it provides no confidentiality and thus 141 can only be used in ESP, but not in IKEv2; the Transform ID is 142 144 o ENCR_MAGMA_MGM_MAC_KTREE is a MAC-only transform based on "Magma" 145 algorithm; it provides no confidentiality and thus can only be 146 used in ESP, but not in IKEv2; the Transform ID is 148 4.1. Tree-based External Re-Keying 150 All four transforms use the same Tree-based External Re-Keying 151 mechanism. The idea is that the key that is provided for the 152 transform (Child SA key derived from KEYMAT in case of ESP or SK_ei/ 153 SK_er in case of IKEv2) is not directly use to protect messages. 154 Instead a tree of keys is derived using this key as a root. This 155 tree may have several levels. The leaf keys are used for message 156 protection, while intermediate nodes keys are used to derive lower 157 level keys (including leaf keys). See Section 5.2.3 of 158 [I-D.irtf-cfrg-re-keying] for more detail. This construction allows 159 to protect a large amount of data, but at the same time providing a 160 bound on a number of times any particular key in the tree is used, 161 thus defending from some side channel attacks. 163 The transforms defined in this document use three-level tree. The 164 leaf key that protects a message is computed as follows: 166 Kmsg = KDF (KDF (KDF (K, L1, I1), L2, I2), L3, I3) 168 where: 170 KDF (k, l, s) Key Derivation Function KDF_GOSTR3411_2012_256 171 defined in Section 4.5 of [RFC7836], which accepts 172 three input parameters - a key (k), a label (l) and a 173 seed (s) and provides a new key as an output; 175 K the key for the transform (ESP SA key derived from 176 KEYMAT or SK_ei/SK_er in case of IKEv2); 178 L1, L2, L3 labels defined as 6 octet ASCII strings without null 179 termination: 181 L1 = "level1" 183 L2 = "level2" 185 L3 = "level3" 187 I1, I2, I3 parameters that determine which keys out of the tree 188 are used on each level, altogether they determine a 189 leaf key that is used for message protection; these 190 parameters are two octet integers in network byte 191 order; 193 This construction allows to generate up to 2^16 keys on each level, 194 but due to IV construction (see Section 4.2) the number of possible 195 keys on the level 1 is limited to 2^8. So, the total number of 196 possible leaf keys generated from one SA key is 2^40. 198 This specifications doesn't any requirements on the frequency the 199 external re-keying takes place. It is expected that sending 200 application will follow its own policy dictating how many times the 201 keys on each level must be used. 203 4.2. Initialization Vector Format 205 Each message protected by the defined transforms must contain 206 Initialization Vector (IV). The IV has a size of 64 bits and 207 consists of the four fields, three of which are I1, I2 and I3 208 parameters that determine the particular leaf key this message was 209 protected with (see Section 4.1), and the fourh is a counter, 210 representing the message number for this key. 212 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | I1 | I2 | I3 | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | I3 (cont) | C | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 1: IV Format 222 where: 224 o I1 (1 octet), I2 (2 octets), I3 (2 octets) - parameters, 225 determining the particular key used to protect this message; 226 2-octets parameters are integers in network byte order 228 o C (3 octets) - message counter for the leaf key protecting this 229 message; up to 2^24 messages may be protected using a single leaf 230 key 232 For any given SA the IV MUST NOT repeat, but there is no requirement 233 that IV is unpredictable. 235 4.3. Nonce Format for MGM 237 MGM requires a per-message nonce (called Initial Counter Nonce, ICN, 238 in the [I-D.smyshlyaev-mgm]) that must be unique in the context of 239 any leaf key (that are used to actually protect messages). The size 240 of the ICN is n-1 bits, where n is the size of the block of the 241 underlying cipher. The two ciphers used in the defined transforms 242 have different block sizes, so the two formats for the ICN are 243 defined. 245 MGM specification requires that the nonce be n-1 bits in size, where 246 n is a block size of underlying cipher. This document defines MGM 247 nonces that are n bits in size, because that makes them having whole 248 number of bytes. When used inside MGM the most significant bit of 249 the first octet if the nonce (represented as an octet string) is 250 dropped, making an effective size of the nonce equal to n-1 bits. 251 Note, that the dropped bit is a part of zero field (see Figure 2 and 252 Figure 3) which is always set to 0, so no information is lost when it 253 is dropped. 255 4.3.1. MGM Nonce Format for "Kuznyechik" based Transforms 257 For transforms based on "Kuznyechik" cipher 258 (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the ICN 259 consists of a zero octet, a 24-bit message counter and a 96-bit 260 secret salt, that is fixed for SA and not transmitted. 262 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | zero | C | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | | 268 | salt | 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2: Nonce format for "Kuznyechik" based transforms 274 where: 276 o zero (1 octet) - set to 0 278 o C (3 octets) - the counter for the messages protected by the given 279 leaf key; this field MUST be equal to the C field in the IV 281 o salt (12 octets) - secret salt 283 4.3.2. MGM Nonce Format for "Magma" based Transforms 285 For transforms based on "Magma" cipher (ENCR_MAGMA_MGM_KTREE and 286 ENCR_MAGMA_MGM_MAC_KTREE) the ICN consists of a zero octet, a 24-bit 287 message counter and a 32-bit secret salt, that is fixed for SA and 288 not transmitted. 290 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | zero | C | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | salt | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 3: Nonce format for "Magma" based transforms 300 where: 302 o zero (1 octet) - set to 0 304 o C (3 octets) - the counter for the messages protected by the given 305 leaf key; this field MUST be equal to the C field in the IV 307 o salt (4 octets) - secret salt 309 4.4. Keying Material 311 The key for ENCR_KUZNYECHIK_MGM_KTREE and 312 ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits, of 313 which the first 256 bits is a root key for the tree (denoted as K in 314 Section 4.1) and the remaining 96 bits is a secret salt (see 315 Section 4.3.1). 317 The key for ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE 318 transforms consists of 288 bits, of which the first 256 bits is a 319 root key for the tree (denoted as K in Section 4.1) and the remaining 320 32 bits is a secret salt (see Section 4.3.2). 322 The keys in case ESP are extracted from the KEYMAT, and in case IKEv2 323 they are SK_ei/SK_er keys. Note, that since these transforms provide 324 authenticated encryption, no additional keys are needed for 325 authentication. It means that in case of IKEv2 the keys SK_ai/SK_ar 326 are not used. 328 4.5. Integrity Check Value 330 The MGM computes authentication tag equal to the size of the block of 331 the underlying cipher. For "Kuznyechik" based transforms 332 (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the 333 resulting Integrity Check Value (ICV) is truncated to 96 bits by 334 dropping the last 4 octets of the produced authentication tag. For 335 "Magma" based transforms the full 64-bit authentication tag is used 336 as ICV. 338 4.6. Plaintext Padding 340 All transforms defined in this document doesn't require any special 341 plaintext padding, as specified in [I-D.smyshlyaev-mgm]. It means, 342 that only those padding requirements that are imposed by the protocol 343 are applied (4 bytes for ESP, no special padding for IKEv2). 345 4.7. AAD Construction 347 4.7.1. ESP AAD 349 Additional Authenticated Data (AAD) in ESP are constructed 350 differently depending on the transform being used and whether 351 Extended Sequence Number (ESN) is in use or not. The 352 ENCR_KUZNYECHIK_MGM_KTREE and ENCR_MAGMA_MGM_KTREE provide 353 confidentiality, so the content of the ESP body is encrypted and AAD 354 consists of the ESP SPI and (E)SN. The AAD is constructed similar to 355 the one in [RFC4106]. 357 On the other hand the ENCR_KUZNYECHIK_MGM_MAC_KTREE and 358 ENCR_MAGMA_MGM_MAC_KTREE don't provide confidentiality, they provide 359 only message authentication. For this purpose the part of ESP packet 360 that is normally encrypted is included in the AAD instead. For these 361 transforms encryption capability provided by MGM is not used. The 362 AAD is constructed similar to the one in [RFC4543]. 364 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | SPI | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | 32-bit Sequence Number | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 4: AAD for AEAD transforms with 32-bit SN 374 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | SPI | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | 64-bit Extended Sequence Number | 380 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Figure 5: AAD for AEAD transforms with 64-bit ESN 384 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | SPI | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | 32-bit Sequence Number | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 ~ Payload Data (variable) ~ 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Padding (0-255 bytes) | 396 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | Pad Length | Next Header | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 6: AAD for authentication only transforms with 32-bit SN 402 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | SPI | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | 64-bit Extended Sequence Number | 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | | 411 ~ Payload Data (variable) ~ 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Padding (0-255 bytes) | 415 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | Pad Length | Next Header | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 7: AAD for authentication only transforms with 64-bit ESN 421 4.7.2. IKEv2 AAD 423 For IKEv2 the AAD consists of the IKEv2 Header, the unencrypted 424 payload followed it and an Encrypted (or Encrypted Fragment) payload 425 header. The AAD is constructed similar to one in [RFC5282]. 427 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 ~ IKEv2 Header ~ 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 ~ Unencrypted IKE Payloads ~ 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Next Payload |C| RESERVED | Payload Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 8: AAD for IKEv2 439 4.8. Using Transforms 441 When SA is established the I1, I2 and I3 parameters are set to 0 by 442 the sender and a leaf key is calculated. The C parameter starts from 443 0 and is incremented with each message protected by the same leaf 444 key. When sender decides that the leaf should be changed, it 445 increments I3 parameter and generates a new leaf key. The C 446 parameter for the new leaf key is reset to 0 and the process 447 continues. If the sender decides, that 3-rd level key corresponding 448 to I3 is used enough times, it increments I2, resets I3 to 0 and 449 calculates a new leaf key. The C is reset to 0 (as with every new 450 leaf key) and the process continues. 452 The receiver always use I1, I2 and I3 from the incoming message. If 453 they differ from the values in previous packets, a new leaf key is 454 calculated . The C parameter is always used from the incoming packet. 455 To improve performance implementations may cache recently used leaf 456 key. When new leaf key is calculated (based on the values from 457 incoming message) the old key may be cacheed for some time to improve 458 performance in case of possible packet reordering (when packets 459 protected by the old leaf key may be delayed and arrive later). 461 5. Security Considerations 463 TBD 465 6. IANA Considerations 467 IANA has assigned four Transform IDs in the "Transform Type 1 - 468 Encryption Algorithm Transform IDs" registry (where RFCXXXX is this 469 document): 471 Number Name ESP Reference IKEv2 Reference 472 --------------------------------------------------------------------- 473 TBA1 ENCR_KUZNYECHIK_MGM_KTREE [RFCXXXX] [RFCXXXX] 474 TBA2 ENCR_MAGMA_MGM_KTREE [RFCXXXX] [RFCXXXX] 475 TBA3 ENCR_KUZNYECHIK_MGM_MAC_KTREE [RFCXXXX] Not allowed 476 TBA4 ENCR_MAGMA_MGM_MAC_KTREE [RFCXXXX] Not allowed 478 7. References 480 7.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, 484 DOI 10.17487/RFC2119, March 1997, 485 . 487 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 488 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 489 May 2017, . 491 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 492 RFC 4303, DOI 10.17487/RFC4303, December 2005, 493 . 495 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 496 Kivinen, "Internet Key Exchange Protocol Version 2 497 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 498 2014, . 500 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 501 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 502 2013, . 504 [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher 505 "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, 506 . 508 [I-D.dolmatov-magma] 509 Dolmatov, V. and D. Eremin-Solenikov, "GOST R 34.12-2015: 510 Block Cipher "Magma"", draft-dolmatov-magma-01 (work in 511 progress), June 2019. 513 [I-D.smyshlyaev-mgm] 514 Smyshlyaev, S., Nozdrunov, V., Shishkin, V., and S. 515 Ekaterina, "Multilinear Galois Mode (MGM)", draft- 516 smyshlyaev-mgm-11 (work in progress), June 2019. 518 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 519 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 520 on the Cryptographic Algorithms to Accompany the Usage of 521 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 522 RFC 7836, DOI 10.17487/RFC7836, March 2016, 523 . 525 7.2. Informative References 527 [GOST3411-2012] 528 Federal Agency on Technical Regulating and Metrology, 529 "Information technology. Cryptographic Data Security. 530 Hashing function", GOST R 34.11-2012 (in Russian), 2012. 532 [GOST3412-2015] 533 Federal Agency on Technical Regulating and Metrology, 534 "Information technology. Cryptographic data security. 535 Block ciphers", GOST R 34.12-2015 (in Russian), 2015. 537 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 538 Hashing for Message Authentication", RFC 2104, 539 DOI 10.17487/RFC2104, February 1997, 540 . 542 [I-D.irtf-cfrg-re-keying] 543 Smyshlyaev, S., "Re-keying Mechanisms for Symmetric Keys", 544 draft-irtf-cfrg-re-keying-17 (work in progress), May 2019. 546 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 547 (GCM) in IPsec Encapsulating Security Payload (ESP)", 548 RFC 4106, DOI 10.17487/RFC4106, June 2005, 549 . 551 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 552 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 553 DOI 10.17487/RFC4543, May 2006, 554 . 556 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 557 Algorithms with the Encrypted Payload of the Internet Key 558 Exchange version 2 (IKEv2) Protocol", RFC 5282, 559 DOI 10.17487/RFC5282, August 2008, 560 . 562 Author's Address 564 Valery Smyslov 565 ELVIS-PLUS 566 PO Box 81 567 Moscow (Zelenograd) 124460 568 RU 570 Phone: +7 495 276 0211 571 Email: svan@elvis.ru