diff options
Diffstat (limited to 'doc/rfc/rfc9227.txt')
| -rw-r--r-- | doc/rfc/rfc9227.txt | 1094 |
1 files changed, 1094 insertions, 0 deletions
diff --git a/doc/rfc/rfc9227.txt b/doc/rfc/rfc9227.txt new file mode 100644 index 0000000..93a903c --- /dev/null +++ b/doc/rfc/rfc9227.txt @@ -0,0 +1,1094 @@ + + + + +Independent Submission V. Smyslov +Request for Comments: 9227 ELVIS-PLUS +Category: Informational March 2022 +ISSN: 2070-1721 + + + Using GOST Ciphers in the Encapsulating Security Payload (ESP) and + Internet Key Exchange Version 2 (IKEv2) Protocols + +Abstract + + This document defines a set of encryption transforms for use in the + Encapsulating Security Payload (ESP) and in the Internet Key Exchange + version 2 (IKEv2) protocols, which are parts of the IP Security + (IPsec) protocol suite. The transforms are based on the GOST R + 34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik") + in Multilinear Galois Mode (MGM) and the external rekeying approach. + + This specification was developed to facilitate implementations that + wish to support the GOST algorithms. This document does not imply + IETF endorsement of the cryptographic algorithms used in this + document. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9227. + +Copyright Notice + + Copyright (c) 2022 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. + +Table of Contents + + 1. Introduction + 2. Requirements Language + 3. Overview + 4. Description of Transforms + 4.1. Tree-Based External Rekeying + 4.2. Initialization Vector Format + 4.3. Nonce Format for MGM + 4.3.1. MGM Nonce Format for Transforms Based on the + "Kuznyechik" Cipher + 4.3.2. MGM Nonce Format for Transforms Based on the "Magma" + Cipher + 4.4. Keying Material + 4.5. Integrity Check Value + 4.6. Plaintext Padding + 4.7. AAD Construction + 4.7.1. ESP AAD + 4.7.2. IKEv2 AAD + 4.8. Using Transforms + 5. Security Considerations + 6. IANA Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Appendix A. Test Vectors + Acknowledgments + Author's Address + +1. Introduction + + The IP Security (IPsec) protocol suite consists of several protocols, + of which the Encapsulating Security Payload (ESP) [RFC4303] and the + Internet Key Exchange version 2 (IKEv2) [RFC7296] are most widely + used. This document defines four transforms for ESP and IKEv2 based + on Russian cryptographic standard algorithms (often referred to as + "GOST" algorithms). These definitions are based on the + recommendations [GOST-ESP] established by the Federal Agency on + Technical Regulating and Metrology (Rosstandart), which describe how + Russian cryptographic standard algorithms are used in ESP and IKEv2. + The transforms defined in this document are based on two block + ciphers from Russian cryptographic standard algorithms -- + "Kuznyechik" [GOST3412-2015] [RFC7801] and "Magma" [GOST3412-2015] + [RFC8891] in Multilinear Galois Mode (MGM) [GOST-MGM] [RFC9058]. + These transforms provide Authenticated Encryption with Associated + Data (AEAD). An external rekeying mechanism, described in [RFC8645], + is also used in these transforms to limit the load on session keys. + + Because the GOST specification includes the definition of both + 128-bit ("Kuznyechik") and 64-bit ("Magma") block ciphers, both are + included in this document. Implementers should make themselves aware + of the relative security and other cost-benefit implications of the + two ciphers. See Section 5 for more details. + + This specification was developed to facilitate implementations that + wish to support the GOST algorithms. This document does not imply + IETF endorsement of the cryptographic algorithms used in this + document. + +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. + +3. Overview + + Russian cryptographic standard algorithms, often referred to as + "GOST" algorithms, constitute 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 [RFC8891]). Both ciphers use a 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 [GOST-MGM] + and [RFC9058]. It is claimed to provide defense against some attacks + on well-known AEAD modes, like Galois/Counter Mode (GCM). + + [RFC8645] defines mechanisms that can be used to limit the number of + times any particular session key is used. One of these mechanisms, + called external rekeying with tree-based construction (defined in + Section 5.2.3 of [RFC8645]), is used in the defined transforms. For + the purpose of deriving subordinate keys, the Key Derivation Function + (KDF) KDF_GOSTR3411_2012_256, defined in Section 4.5 of [RFC7836], is + used. This KDF is based on a Hashed Message Authentication Code + (HMAC) construction [RFC2104] with a Russian GOST hash function + defined in Russian cryptographic standard [GOST3411-2012] (also + defined in [RFC6986]). + +4. Description of Transforms + + This document defines four transforms of Type 1 (Encryption + Algorithm) for use in ESP and IKEv2. All of them use MGM as the mode + of operation with tree-based external rekeying. The transforms + differ in underlying ciphers and in cryptographic services they + provide. + + * ENCR_KUZNYECHIK_MGM_KTREE (Transform ID 32) is an AEAD transform + based on the "Kuznyechik" algorithm; it provides confidentiality + and message authentication and thus can be used in both ESP and + IKEv2. + + * ENCR_MAGMA_MGM_KTREE (Transform ID 33) is an AEAD transform based + on the "Magma" algorithm; it provides confidentiality and message + authentication and thus can be used in both ESP and IKEv2. + + * ENCR_KUZNYECHIK_MGM_MAC_KTREE (Transform ID 34) is a MAC-only + transform based on the "Kuznyechik" algorithm; it provides no + confidentiality and thus can only be used in ESP, but not in + IKEv2. + + * ENCR_MAGMA_MGM_MAC_KTREE (Transform ID 35) is a MAC-only transform + based on the "Magma" algorithm; it provides no confidentiality and + thus can only be used in ESP, but not in IKEv2. + + Note that transforms ENCR_KUZNYECHIK_MGM_MAC_KTREE and + ENCR_MAGMA_MGM_MAC_KTREE don't provide any confidentiality, but they + are defined as Type 1 (Encryption Algorithm) transforms because of + the need to include an Initialization Vector (IV), which is + impossible for Type 3 (Integrity Algorithm) transforms. + +4.1. Tree-Based External Rekeying + + All four transforms use the same tree-based external rekeying + mechanism. The idea is that the key that is provided for the + transform is not directly used 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-node keys are used to derive lower-level keys, including + leaf keys. See Section 5.2.3 of [RFC8645] for more details. This + construction allows us to protect a large amount of data, at the same + time providing a bound on a number of times any particular key in the + tree is used, thus defending against some side-channel attacks and + also increasing the key lifetime limitations based on combinatorial + properties. + + The transforms defined in this document use a three-level tree. The + leaf key that protects a message is computed as follows: + + K_msg = KDF (KDF (KDF (K, l1, 0x00 | 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 output + + K the root key for the tree (see Section 4.4) + + 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. Together, they determine a + leaf key that is used for message protection; the + length of i1 is one octet, and i2 and i3 are two- + octet integers in network byte order + + | indicates concatenation + + This construction allows us to generate up to 2^8 keys on level 1 and + up to 2^16 keys on levels 2 and 3. So, the total number of possible + leaf keys generated from a single Security Association (SA) key is + 2^40. + + This specification doesn't impose any requirements on how frequently + external rekeying takes place. It is expected that the 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 an IV. + The IV has a size of 64 bits and consists of four fields. The fields + i1, i2, and i3 are parameters that determine the particular leaf key + this message was protected with (see Section 4.1). The fourth field + 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) | pnum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: IV Format + + where: + + i1 (1 octet), i2 (2 octets), i3 (2 octets): parameters that + determine the particular key used to protect this message; 2-octet + parameters are integers in network byte order + + pnum (3 octets): message counter in network byte order 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 be used more than once, but there + is no requirement that IV be unpredictable. + +4.3. Nonce Format for MGM + + MGM requires a per-message nonce (called the Initial Counter Nonce, + or ICN in [RFC9058]) that MUST be unique in the context of any leaf + key. The size of the ICN is n-1 bits, where n is the block size of + the underlying cipher. The two ciphers used in the transforms + defined in this document have different block sizes, so two different + formats for the ICN are defined. + + MGM specification requires that the nonce be n-1 bits in size, where + n is the block size of the underlying cipher. This document defines + MGM nonces having n bits (the block size of the underlying cipher) in + size. Since n is always a multiple of 8 bits, this makes MGM nonces + having a whole number of octets. When used inside MGM, the most + significant bit of the first octet of the nonce (represented as an + octet string) is dropped, making the effective size of the nonce + equal to n-1 bits. Note that the dropped bit is a part of the "zero" + field (see Figures 2 and 3), which is always set to 0, so no + information is lost when it is dropped. + +4.3.1. MGM Nonce Format for Transforms Based on the "Kuznyechik" Cipher + + For transforms based on the "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, which is fixed for the SA and is 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 | pnum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | salt | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Nonce Format for Transforms Based on the "Kuznyechik" + Cipher + + where: + + zero (1 octet): set to 0 + + pnum (3 octets): the counter for the messages protected by the given + leaf key; this field MUST be equal to the pnum field in the IV + + salt (12 octets): secret salt. The salt is a string of bits that + are formed when the SA is created (see Section 4.4 for details). + The salt does not change during the SA's lifetime and is not + transmitted on the wire. Every SA will have its own salt. + +4.3.2. MGM Nonce Format for Transforms Based on the "Magma" Cipher + + For transforms based on the "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, which is fixed for + the SA and is 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 | pnum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | salt | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Nonce Format for Transforms Based on the "Magma" Cipher + + where: + + zero (1 octet): set to 0 + + pnum (3 octets): the counter for the messages protected by the given + leaf key; this field MUST be equal to the pnum field in the IV + + salt (4 octets): secret salt. The salt is a string of bits that are + formed when the SA is created (see Section 4.4 for details). The + salt does not change during the SA's lifetime and is not + transmitted on the wire. Every SA will have its own salt. + +4.4. Keying Material + + We'll call a string of bits that is used to initialize the transforms + defined in this specification a "transform key". The transform key + is a composite entity consisting of the root key for the tree and the + secret salt. + + The transform key for the ENCR_KUZNYECHIK_MGM_KTREE and + ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits (44 + octets), 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 transform key for the ENCR_MAGMA_MGM_KTREE and + ENCR_MAGMA_MGM_MAC_KTREE transforms consists of 288 bits (36 octets), + 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). + + In the case of ESP, the transform keys are extracted from the KEYMAT + as defined in Section 2.17 of [RFC7296]. In the case of IKEv2, the + transform keys are either SK_ei or SK_er, which are generated as + defined in Section 2.14 of [RFC7296]. Note that since these + transforms provide authenticated encryption, no additional keys are + needed for authentication. This means that, in the case of IKEv2, + the keys SK_ai/SK_ar are not used and MUST be treated as having zero + length. + +4.5. Integrity Check Value + + The length of the authentication tag that MGM can compute is in the + range from 32 bits to the block size of the underlying cipher. + Section 4 of [RFC9058] states that the authentication tag length MUST + be fixed for a particular protocol. For transforms based on the + "Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE and + ENCR_KUZNYECHIK_MGM_MAC_KTREE), the resulting Integrity Check Value + (ICV) length is set to 96 bits. For transforms based on the "Magma" + cipher (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE), the full + ICV length is set to the block size (64 bits). + +4.6. Plaintext Padding + + The transforms defined in this document don't require any plaintext + padding, as specified in [RFC9058]. This means that only those + padding requirements that are imposed by the protocol are applied (4 + bytes for ESP, no padding for IKEv2). + +4.7. AAD Construction + +4.7.1. ESP AAD + + Additional Authenticated Data (AAD) in ESP is constructed + differently, depending on the transform being used and whether the + Extended Sequence Number (ESN) is in use or not. The + ENCR_KUZNYECHIK_MGM_KTREE and ENCR_MAGMA_MGM_KTREE transforms provide + confidentiality, so the content of the ESP body is encrypted and the + AAD consists of the ESP Security Parameter Index (SPI) and (E)SN. + The AAD is constructed similarly to the AAD in [RFC4106]. + + On the other hand, the ENCR_KUZNYECHIK_MGM_MAC_KTREE and + ENCR_MAGMA_MGM_MAC_KTREE transforms don't provide confidentiality; + they provide only message authentication. For this purpose, the IV + and the part of the ESP packet that is normally encrypted are + included in the AAD. For these transforms, the encryption capability + provided by MGM is not used. The AAD is constructed similarly to the + AAD 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 + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IV | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ 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 | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IV | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ 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, any unencrypted + payloads following it (if present), and either the Encrypted payload + header (Section 3.14 of [RFC7296]) or the Encrypted Fragment payload + (Section 2.5 of [RFC7383]), depending on whether IKE fragmentation is + used. The AAD is constructed similarly to the AAD in [RFC5282]. + + 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 in the Case of the Encrypted Payload + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Fragment Number | Total Fragments | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: AAD for IKEv2 in the Case of the Encrypted Fragment Payload + +4.8. Using Transforms + + When the SA is established, the i1, i2, and i3 parameters are set to + 0 by the sender and a leaf key is calculated. The pnum parameter + starts from 0 and is incremented with each message protected by the + same leaf key. When the sender decides that the leaf should be + changed, it increments the i3 parameter and generates a new leaf key. + The pnum parameter for the new leaf key is reset to 0, and the + process continues. If the sender decides that a third-level key + corresponding to i3 is used enough times, it increments i2, resets i3 + to 0, and calculates a new leaf key. The pnum is reset to 0 (as with + every new leaf key), and the process continues. A similar procedure + is used when a second-level key needs to be changed. + + A combination of i1, i2, i3, and pnum MUST NOT repeat for any + particular SA. This means that the wrapping of these counters is not + allowed: when i2, i3, or pnum reaches its respective maximum value, a + procedure for changing a leaf key, described above, is executed, and + if all four parameters reach their maximum values, the IPsec SA + becomes unusable. + + There may be other reasons to recalculate leaf keys besides reaching + maximum values for the counters. For example, as described in + Section 5, it is RECOMMENDED that the sender count the number of + octets protected by a particular leaf key and generate a new key when + some threshold is reached, and at the latest when reaching the octet + limits stated in Section 5 for each of the ciphers. + + The receiver always uses i1, i2, and i3 from the received message. + If they differ from the values in previously received packets, a new + leaf key is calculated. The pnum parameter is always used from the + received packet. To improve performance, implementations may cache + recently used leaf keys. When a new leaf key is calculated (based on + the values from the received message), the old key may be kept for + some time to improve performance in the case of possible packet + reordering (when packets protected by the old leaf key are delayed + and arrive later). + +5. Security Considerations + + The most important security consideration for MGM is that the nonce + MUST NOT repeat for a given key. For this reason, the transforms + defined in this document MUST NOT be used with manual keying. + + Excessive use of the same key can give an attacker advantages in + breaking security properties of the transforms defined in this + document. For this reason, the amount of data that any particular + key is used to protect should be limited. This is especially + important for algorithms with a 64-bit block size (like "Magma"), + which currently are generally considered insecure after protecting a + relatively small amount of data. For example, Section 3.4 of + [SP800-67] limits the number of blocks that are allowed to be + encrypted with the Triple DES cipher to 2^20 (8 MB of data). This + document defines a rekeying mechanism that allows the mitigation of + weak security of a 64-bit block cipher by frequently changing the + encryption key. + + For transforms defined in this document, [GOST-ESP] recommends + limiting the number of octets protected with a single K_msg key by + the following values: + + * 2^41 octets for transforms based on the "Kuznyechik" cipher + (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) + + * 2^28 octets for transforms based on the "Magma" cipher + (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE) + + These values are based on combinatorial properties and may be further + restricted if side-channel attacks are taken into consideration. + Note that the limit for transforms based on the "Kuznyechik" cipher + is unreachable because, due to the construction of the transforms, + the number of protected messages is limited to 2^24 and each message + (either IKEv2 messages or ESP datagrams) is limited to 2^16 octets in + size, giving 2^40 octets as the maximum amount of data that can be + protected with a single K_msg. + + Section 4 of [RFC9058] discusses the possibility of truncating + authentication tags in MGM as a trade-off between message expansion + and the probability of forgery. This specification truncates an + authentication tag length for transforms based on the "Kuznyechik" + cipher to 96 bits. This decreases message expansion while still + providing a very low probability of forgery: 2^-96. + + An attacker can send a lot of packets with arbitrarily chosen i1, i2, + and i3 parameters. This will 1) force a recipient to recalculate the + leaf key for every received packet if i1, i2, and i3 are different + from these values in previously received packets, thus consuming CPU + resources and 2) force a recipient to make verification attempts + (that would fail) on a large amount of data, thus allowing the + attacker a deeper analysis of the underlying cryptographic primitive + (see [AEAD-USAGE-LIMITS]). Implementations MAY initiate rekeying if + they deem that they receive too many packets with an invalid ICV. + + Security properties of MGM are discussed in [MGM-SECURITY]. + +6. IANA Considerations + + IANA maintains a registry called "Internet Key Exchange Version 2 + (IKEv2) Parameters" with a subregistry called "Transform Type + Values". IANA has added the following four Transform IDs to the + "Transform Type 1 - Encryption Algorithm Transform IDs" subregistry. + + +========+===============================+===========+===========+ + | Number | Name | ESP | IKEv2 | + | | | Reference | Reference | + +========+===============================+===========+===========+ + | 32 | ENCR_KUZNYECHIK_MGM_KTREE | RFC 9227 | RFC 9227 | + +--------+-------------------------------+-----------+-----------+ + | 33 | ENCR_MAGMA_MGM_KTREE | RFC 9227 | RFC 9227 | + +--------+-------------------------------+-----------+-----------+ + | 34 | ENCR_KUZNYECHIK_MGM_MAC_KTREE | RFC 9227 | Not | + | | | | allowed | + +--------+-------------------------------+-----------+-----------+ + | 35 | ENCR_MAGMA_MGM_MAC_KTREE | RFC 9227 | Not | + | | | | allowed | + +--------+-------------------------------+-----------+-----------+ + + Table 1: Transform IDs + +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>. + + [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 + (IKEv2) Message Fragmentation", RFC 7383, + DOI 10.17487/RFC7383, November 2014, + <https://www.rfc-editor.org/info/rfc7383>. + + [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>. + + [RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: + Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891, + September 2020, <https://www.rfc-editor.org/info/rfc8891>. + + [RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E. + Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058, + DOI 10.17487/RFC9058, June 2021, + <https://www.rfc-editor.org/info/rfc9058>. + + [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. Hash + function", GOST R 34.11-2012, August 2012. (In Russian) + + [GOST3412-2015] + Federal Agency on Technical Regulating and Metrology, + "Information technology. Cryptographic data security. + Block ciphers", GOST R 34.12-2015, June 2015. (In + Russian) + + [GOST-MGM] Federal Agency on Technical Regulating and Metrology, + "Information technology. Cryptographic information + security. Block Cipher Modes Implementing Authenticated + Encryption", R 1323565.1.026-2019, September 2019. (In + Russian) + + [GOST-ESP] Federal Agency on Technical Regulating and Metrology, + "Information technology. Cryptographic information + protection. The use of Russian cryptographic algorithms in + the ESP information protection protocol", + R 1323565.1.035-2021, January 2021. (In Russian) + + [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>. + + [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>. + + [RFC8645] Smyshlyaev, S., Ed., "Re-keying Mechanisms for Symmetric + Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019, + <https://www.rfc-editor.org/info/rfc8645>. + + [MGM-SECURITY] + Akhmetzyanova, L., Alekseev, E., Karpunin, G., and V. + Nozdrunov, "Security of Multilinear Galois Mode (MGM)", + 2019, <https://eprint.iacr.org/2019/123.pdf>. + + [SP800-67] National Institute of Standards and Technology, + "Recommendation for the Triple Data Encryption Algorithm + (TDEA) Block Cipher", DOI 10.6028/NIST.SP.800-67r2, + November 2017, + <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ + NIST.SP.800-67r2.pdf>. + + [AEAD-USAGE-LIMITS] + Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on + AEAD Algorithms", Work in Progress, Internet-Draft, draft- + irtf-cfrg-aead-limits-04, 7 March 2022, + <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg- + aead-limits-04>. + +Appendix A. Test Vectors + + In the following test vectors, binary data is represented in + hexadecimal format. The numbers in square brackets indicate the size + of the corresponding data in decimal format. + + 1. ENCR_KUZNYECHIK_MGM_KTREE (Example 1): + + transform key [44]: + b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c + e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 + 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 + K [32]: + b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c + e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 + salt [12]: + 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 + i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 + K_msg [32]: + 2f f1 c9 0e de 78 6e 06 1e 17 b3 74 d7 82 af 7b + d8 80 bd 52 7c 66 a2 ba dc 3e 56 9a ab 27 1d a4 + nonce [16]: + 00 00 00 00 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 + IV [8]: + 00 00 00 00 00 00 00 00 + AAD [8]: + 51 46 53 6b 00 00 00 01 + plaintext [64]: + 45 00 00 3c 23 35 00 00 7f 01 ee cc 0a 6f 0a c5 + 0a 6f 0a 1d 08 00 f3 5b 02 00 58 00 61 62 63 64 + 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 + 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 + ciphertext [64]: + 18 9d 12 88 b7 18 f9 ea be 55 4b 23 9b ee 65 96 + c6 d4 ea fd 31 64 96 ef 90 1c ac 31 60 05 aa 07 + 62 97 b2 24 bf 6d 2b e3 5f d6 f6 7e 7b 9d eb 31 + 85 ff e9 17 9c a9 bf 0b db af c2 3e ae 4d a5 6f + ESP ICV [12]: + 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed + ESP packet [112]: + 45 00 00 70 00 4d 00 00 ff 32 91 4f 0a 6f 0a c5 + 0a 6f 0a 1d 51 46 53 6b 00 00 00 01 00 00 00 00 + 00 00 00 00 18 9d 12 88 b7 18 f9 ea be 55 4b 23 + 9b ee 65 96 c6 d4 ea fd 31 64 96 ef 90 1c ac 31 + 60 05 aa 07 62 97 b2 24 bf 6d 2b e3 5f d6 f6 7e + 7b 9d eb 31 85 ff e9 17 9c a9 bf 0b db af c2 3e + ae 4d a5 6f 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed + + 2. ENCR_KUZNYECHIK_MGM_KTREE (Example 2): + + transform key [44]: + b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c + e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 + 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 + K [32]: + b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c + e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38 + salt [12]: + 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 + i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000 + K_msg [32]: + 9a ba c6 57 78 18 0e 6f 2a f6 1f b8 d5 71 62 36 + 66 c2 f5 13 0d 54 e2 11 6c 7d 53 0e 6e 7d 48 bc + nonce [16]: + 00 00 00 00 7b 67 e6 f2 44 f9 7f 06 78 95 2e 45 + IV [8]: + 00 00 01 00 01 00 00 00 + AAD [8]: + 51 46 53 6b 00 00 00 10 + plaintext [64]: + 45 00 00 3c 23 48 00 00 7f 01 ee b9 0a 6f 0a c5 + 0a 6f 0a 1d 08 00 e4 5b 02 00 67 00 61 62 63 64 + 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 + 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 + ciphertext [64]: + 78 0a 2c 62 62 32 15 7b fe 01 76 32 f3 2d b4 d0 + a4 fa 61 2f 66 c2 bf 79 d5 e2 14 9b ac 1d fc 4b + 15 4b 69 03 4d c2 1d ef 20 90 6d 59 62 81 12 7c + ff 72 56 ab f0 0b a1 22 bb 5e 6c 71 a4 d4 9a 4d + ESP ICV [12]: + c2 2f 87 40 83 8e 3d fa ce 91 cc b8 + ESP packet [112]: + 45 00 00 70 00 5c 00 00 ff 32 91 40 0a 6f 0a c5 + 0a 6f 0a 1d 51 46 53 6b 00 00 00 10 00 00 01 00 + 01 00 00 00 78 0a 2c 62 62 32 15 7b fe 01 76 32 + f3 2d b4 d0 a4 fa 61 2f 66 c2 bf 79 d5 e2 14 9b + ac 1d fc 4b 15 4b 69 03 4d c2 1d ef 20 90 6d 59 + 62 81 12 7c ff 72 56 ab f0 0b a1 22 bb 5e 6c 71 + a4 d4 9a 4d c2 2f 87 40 83 8e 3d fa ce 91 cc b8 + + 3. ENCR_MAGMA_MGM_KTREE (Example 1): + + transform key [36]: + 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c + 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 + cf 36 63 12 + K [32]: + 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c + 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 + salt [4]: + cf 36 63 12 + i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 + K_msg [32]: + 25 65 21 e2 70 b7 4a 16 4d fc 26 e6 bf 0c ca 76 + 5e 9d 41 02 7d 4b 7b 19 76 2b 1c c9 01 dc de 7f + nonce [8]: + 00 00 00 00 cf 36 63 12 + IV [8]: + 00 00 00 00 00 00 00 00 + AAD [8]: + c8 c2 b2 8d 00 00 00 01 + plaintext [64]: + 45 00 00 3c 24 2d 00 00 7f 01 ed d4 0a 6f 0a c5 + 0a 6f 0a 1d 08 00 de 5b 02 00 6d 00 61 62 63 64 + 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 + 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 + ciphertext [64]: + fa 08 40 33 2c 4f 3f c9 64 4d 8c 2c 4a 91 7e 0c + d8 6f 8e 61 04 03 87 64 6b b9 df bd 91 50 3f 4a + f5 d2 42 69 49 d3 5a 22 9e 1e 0e fc 99 ac ee 9e + 32 43 e2 3b a4 d1 1e 84 5c 91 a7 19 15 52 cc e8 + ESP ICV [8]: + 5f 4a fa 8b 02 94 0f 5c + ESP packet [108]: + 45 00 00 6c 00 62 00 00 ff 32 91 3e 0a 6f 0a c5 + 0a 6f 0a 1d c8 c2 b2 8d 00 00 00 01 00 00 00 00 + 00 00 00 00 fa 08 40 33 2c 4f 3f c9 64 4d 8c 2c + 4a 91 7e 0c d8 6f 8e 61 04 03 87 64 6b b9 df bd + 91 50 3f 4a f5 d2 42 69 49 d3 5a 22 9e 1e 0e fc + 99 ac ee 9e 32 43 e2 3b a4 d1 1e 84 5c 91 a7 19 + 15 52 cc e8 5f 4a fa 8b 02 94 0f 5c + + 4. ENCR_MAGMA_MGM_KTREE (Example 2): + + transform key [36]: + 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c + 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 + cf 36 63 12 + K [32]: + 5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c + 22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03 + salt [4]: + cf 36 63 12 + i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000 + K_msg [32]: + 20 e0 46 d4 09 83 9b 23 f0 66 a5 0a 7a 06 5b 4a + 39 24 4f 0e 29 ef 1e 6f 2e 5d 2e 13 55 f5 da 08 + nonce [8]: + 00 00 00 00 cf 36 63 12 + IV [8]: + 00 00 01 00 01 00 00 00 + AAD [8]: + c8 c2 b2 8d 00 00 00 10 + plaintext [64]: + 45 00 00 3c 24 40 00 00 7f 01 ed c1 0a 6f 0a c5 + 0a 6f 0a 1d 08 00 cf 5b 02 00 7c 00 61 62 63 64 + 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 + 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 + ciphertext [64]: + 7a 71 48 41 a5 34 b7 58 93 6a 8e ab 26 91 40 a8 + 25 a7 f3 5d b9 e4 37 1f e7 6c 99 9c 9b 88 db 72 + 1d c7 59 f6 56 b5 b3 ea b6 b1 4d 6b d7 7a 07 1d + 4b 93 78 bd 08 97 6c 33 ed 9a 01 91 bf fe a1 dd + ESP ICV [8]: + dd 5d 50 9a fd b8 09 98 + ESP packet [108]: + 45 00 00 6c 00 71 00 00 ff 32 91 2f 0a 6f 0a c5 + 0a 6f 0a 1d c8 c2 b2 8d 00 00 00 10 00 00 01 00 + 01 00 00 00 7a 71 48 41 a5 34 b7 58 93 6a 8e ab + 26 91 40 a8 25 a7 f3 5d b9 e4 37 1f e7 6c 99 9c + 9b 88 db 72 1d c7 59 f6 56 b5 b3 ea b6 b1 4d 6b + d7 7a 07 1d 4b 93 78 bd 08 97 6c 33 ed 9a 01 91 + bf fe a1 dd dd 5d 50 9a fd b8 09 98 + + 5. ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 1): + + transform key [44]: + 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 + 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be + 6c 51 cb ac 93 c4 5b ea 99 62 79 1d + K [32]: + 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 + 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be + salt [12]: + 6c 51 cb ac 93 c4 5b ea 99 62 79 1d + i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 + K_msg [32]: + 98 f1 03 01 81 0a 04 1c da dd e1 bd 85 a0 8f 21 + 8b ac b5 7e 00 35 e2 22 c8 31 e3 e4 f0 a2 0c 8f + nonce [16]: + 00 00 00 00 6c 51 cb ac 93 c4 5b ea 99 62 79 1d + IV [8]: + 00 00 00 00 00 00 00 00 + AAD [80]: + 3d ac 92 6a 00 00 00 01 00 00 00 00 00 00 00 00 + 45 00 00 3c 0c f1 00 00 7f 01 05 11 0a 6f 0a c5 + 0a 6f 0a 1d 08 00 48 5c 02 00 03 00 61 62 63 64 + 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 + 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 + plaintext [0]: + ciphertext [0]: + ESP ICV [12]: + ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d + ESP packet [112]: + 45 00 00 70 00 01 00 00 ff 32 91 9b 0a 6f 0a c5 + 0a 6f 0a 1d 3d ac 92 6a 00 00 00 01 00 00 00 00 + 00 00 00 00 45 00 00 3c 0c f1 00 00 7f 01 05 11 + 0a 6f 0a c5 0a 6f 0a 1d 08 00 48 5c 02 00 03 00 + 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 + 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 + 01 02 02 04 ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d + + 6. ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 2): + + transform key [44]: + 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 + 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be + 6c 51 cb ac 93 c4 5b ea 99 62 79 1d + K [32]: + 98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4 + 88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be + salt [12]: + 6c 51 cb ac 93 c4 5b ea 99 62 79 1d + i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000 + K_msg [32]: + 02 c5 41 87 7c c6 23 f3 f1 35 91 9a 75 13 b6 f8 + a8 a1 8c b2 63 99 86 2f 50 81 4f 52 91 01 67 84 + nonce [16]: + 00 00 00 00 6c 51 cb ac 93 c4 5b ea 99 62 79 1d + IV [8]: + 00 00 00 00 01 00 00 00 + AAD [80]: + 3d ac 92 6a 00 00 00 06 00 00 00 00 01 00 00 00 + 45 00 00 3c 0c fb 00 00 7f 01 05 07 0a 6f 0a c5 + 0a 6f 0a 1d 08 00 43 5c 02 00 08 00 61 62 63 64 + 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 + 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 + plaintext [0]: + ciphertext [0]: + ESP ICV [12]: + ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91 + ESP packet [112]: + 45 00 00 70 00 06 00 00 ff 32 91 96 0a 6f 0a c5 + 0a 6f 0a 1d 3d ac 92 6a 00 00 00 06 00 00 00 00 + 01 00 00 00 45 00 00 3c 0c fb 00 00 7f 01 05 07 + 0a 6f 0a c5 0a 6f 0a 1d 08 00 43 5c 02 00 08 00 + 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 + 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 + 01 02 02 04 ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91 + + 7. ENCR_MAGMA_MGM_MAC_KTREE (Example 1): + + transform key [36]: + d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 + 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 + 88 79 8f 29 + K [32]: + d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 + 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 + salt [4]: + 88 79 8f 29 + i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000 + K_msg [32]: + 4c 61 45 99 a0 a0 67 f1 94 87 24 0a e1 00 e1 b7 + ea f2 3e da f8 7e 38 73 50 86 1c 68 3b a4 04 46 + nonce [8]: + 00 00 00 00 88 79 8f 29 + IV [8]: + 00 00 00 00 00 00 00 00 + AAD [80]: + 3e 40 69 9c 00 00 00 01 00 00 00 00 00 00 00 00 + 45 00 00 3c 0e 08 00 00 7f 01 03 fa 0a 6f 0a c5 + 0a 6f 0a 1d 08 00 36 5c 02 00 15 00 61 62 63 64 + 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 + 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 + plaintext [0]: + ciphertext [0]: + ESP ICV [8]: + 4d d4 25 8a 25 35 95 df + ESP packet [108]: + 45 00 00 6c 00 13 00 00 ff 32 91 8d 0a 6f 0a c5 + 0a 6f 0a 1d 3e 40 69 9c 00 00 00 01 00 00 00 00 + 00 00 00 00 45 00 00 3c 0e 08 00 00 7f 01 03 fa + 0a 6f 0a c5 0a 6f 0a 1d 08 00 36 5c 02 00 15 00 + 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 + 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 + 01 02 02 04 4d d4 25 8a 25 35 95 df + + 8. ENCR_MAGMA_MGM_MAC_KTREE (Example 2): + + transform key [36]: + d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 + 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 + 88 79 8f 29 + K [32]: + d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39 + 2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30 + salt [4]: + 88 79 8f 29 + i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000 + K_msg [32]: + b4 f3 f9 0d c4 87 fa b8 c4 af d0 eb 45 49 f2 f0 + e4 36 32 b6 79 19 37 2e 1e 96 09 ea f0 b8 e2 28 + nonce [8]: + 00 00 00 00 88 79 8f 29 + IV [8]: + 00 00 00 00 01 00 00 00 + AAD [80]: + 3e 40 69 9c 00 00 00 06 00 00 00 00 01 00 00 00 + 45 00 00 3c 0e 13 00 00 7f 01 03 ef 0a 6f 0a c5 + 0a 6f 0a 1d 08 00 31 5c 02 00 1a 00 61 62 63 64 + 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 + 75 76 77 61 62 63 64 65 66 67 68 69 01 02 02 04 + plaintext [0]: + ciphertext [0]: + ESP ICV [8]: + 84 84 a9 23 30 a0 b1 96 + ESP packet [108]: + 45 00 00 6c 00 18 00 00 ff 32 91 88 0a 6f 0a c5 + 0a 6f 0a 1d 3e 40 69 9c 00 00 00 06 00 00 00 00 + 01 00 00 00 45 00 00 3c 0e 13 00 00 7f 01 03 ef + 0a 6f 0a c5 0a 6f 0a 1d 08 00 31 5c 02 00 1a 00 + 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 + 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 + 01 02 02 04 84 84 a9 23 30 a0 b1 96 + +Acknowledgments + + The author wants to thank Adrian Farrel, Russ Housley, Yaron Sheffer, + and Stanislav Smyshlyaev for valuable input during the publication + process for this document. + +Author's Address + + Valery Smyslov + ELVIS-PLUS + PO Box 81 + Moscow (Zelenograd) + 124460 + Russian Federation + Phone: +7 495 276 0211 + Email: svan@elvis.ru |