<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd">[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfccategory="info"xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"docName="draft-smyslov-esp-gost-14"> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="no"?> <?rfc iprnotified="no" ?> <?rfc strict="yes" ?>docName="draft-smyslov-esp-gost-14" number="9227" obsoletes="" updates="" submissionType="independent" category="info" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="false" version="3"> <!-- xml2rfc v2v3 conversion 3.12.1 --> <front> <title abbrev="GOSTciphersCiphers in ESP&and IKEv2">Using GOSTciphersCiphers inESPthe Encapsulating Security Payload (ESP) andIKEv2</title>Internet Key Exchange Version 2 (IKEv2) Protocols</title> <seriesInfo name="RFC" value="9227"/> <authorinitials='V.'initials="V." surname="Smyslov"fullname='Valery Smyslov'>fullname="Valery Smyslov"> <organization>ELVIS-PLUS</organization> <address> <postal> <street>PO Box 81</street> <city>Moscow (Zelenograd)</city> <code>124460</code><country>RU</country><country>Russian Federation</country> </postal> <phone>+7 495 276 0211</phone> <email>svan@elvis.ru</email> </address> </author><date/><date year="2022" month="March" /> <keyword>AEAD</keyword> <keyword>MGM</keyword> <abstract> <t> 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)protocolsprotocols, which are parts of the IP Security (IPsec)protocolsprotocol suite. The transforms are based on the GOST R 34.12-2015 block ciphers (which are named"Magma""Magma" and"Kuznyechik")"Kuznyechik") inaMultilinear Galois Mode (MGM) and the externalre-keyingrekeying approach. </t> <t> This specificationiswas 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. </t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="intro">anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t> The IP Security (IPsec)protocolsprotocol suite consists of several protocols, of which the Encapsulating Security Payload (ESP) <xref target="RFC4303"/>format="default"/> and the Internet Key Exchange version 2 (IKEv2) <xref target="RFC7296"/>format="default"/> are most widely used. This document defines four transforms for ESP and IKEv2 based on Russian cryptographic standard algorithms (often referred to as"GOST""GOST" algorithms).This definition isThese definitions are based on theRecommendationsrecommendations <xref target="GOST-ESP"/>format="default"/> established by the Federal Agency on Technical Regulating and Metrology (Rosstandart), which describe how Russian cryptographic standard algorithms are used in ESP and IKEv2.TransformsThe transforms defined in this document are based on two block ciphers from Russian cryptographic standard algorithms- "Kuznyechik"-- "Kuznyechik" <xref target="GOST3412-2015"/><xrefformat="default"/> <xref target="RFC7801"/>format="default"/> and"Magma""Magma" <xref target="GOST3412-2015"/><xrefformat="default"/> <xref target="RFC8891"/>format="default"/> in Multilinear Galois Mode (MGM) <xref target="GOST-MGM"/><xrefformat="default"/> <xref target="RFC9058"/>.format="default"/>. These transforms provide Authenticated Encryption with Associated Data (AEAD). An externalre-keyingrekeying mechanism, described in <xref target="RFC8645"/>format="default"/>, is also used in these transforms to limit the load on session keys. </t> <t> Because the GOST specification includes the definition of both128 ("Kuznyechik")128-bit ("Kuznyechik") and64 ("Magma") bit64-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 <xref target="security"/>format="default"/> for more details. </t> <t> This specificationiswas 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. </t> </section> <sectiontitle="Requirements Language" anchor="req_lang">anchor="req_lang" numbered="true" toc="default"> <name>Requirements Language</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </section> <sectiontitle="Overview" anchor="overview">anchor="overview" numbered="true" toc="default"> <name>Overview</name> <t> Russian cryptographic standard algorithms, often referred to as"GOST""GOST" algorithms, constitute a set of cryptographic algorithms of different types--- ciphers, hash functions, digital signatures, etc. In particular, Russian cryptographic standard <xref target="GOST3412-2015"/>format="default"/> defines two block ciphers- "Kuznyechik"-- "Kuznyechik" (also defined in <xref target="RFC7801"/>)format="default"/>) and"Magma""Magma" (also defined in <xref target="RFC8891"/>).format="default"/>). Both ciphers use a 256-bit key."Kuznyechik""Kuznyechik" has a block size of 128 bits, while"Magma""Magma" has a 64-bit block. </t> <t> Multilinear Galois Mode (MGM) is an AEAD mode defined in <xref target="GOST-MGM"/><xrefformat="default"/> and <xref target="RFC9058"/>.format="default"/>. It is claimed to provide defense against some attacks on well-known AEAD modes, likeGalois CounterGalois/Counter Mode (GCM). </t> <t> <xref target="RFC8645"/>format="default"/> defines mechanisms that can be used to limit the number of times any particular session key is used. One of these mechanisms, called externalre-keyingrekeying with tree-based construction (defined inSection 5.2.3 of<xref target="RFC8645"/>),sectionFormat="of" section="5.2.3"/>), is used in the defined transforms. For the purpose of deriving subordinatekeys akeys, the Key Derivation Function (KDF)KDF_GOSTR3411_2012_256KDF_GOSTR3411_2012_256, defined inSection 4.5 of<xref target="RFC7836"/>,sectionFormat="of" section="4.5"/>, is used. This KDF is based onan HMACa Hashed Message Authentication Code (HMAC) construction <xref target="RFC2104"/> constructionformat="default"/> with a Russian GOST hash function defined in Russian cryptographic standard <xref target="GOST3411-2012"/>format="default"/> (also defined in <xref target="RFC6986"/>).format="default"/>). </t> </section> <sectiontitle="Transforms Description" anchor="transforms">anchor="transforms" numbered="true" toc="default"> <name>Description of Transforms</name> <t> 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 externalre-keying.rekeying. The transforms differ in underlying ciphers and in cryptographic services they provide.<list style="symbols"> <t>ENCR_KUZNYECHIK_MGM_KTREE</t> <ul spacing="normal"> <li>ENCR_KUZNYECHIK_MGM_KTREE (Transform ID 32) is an AEAD transform based on"Kuznyechik"the "Kuznyechik" algorithm; it provides confidentiality and message authentication and thus can be used in both ESP andIKEv2</t> <t>ENCR_MAGMA_MGM_KTREEIKEv2.</li> <li>ENCR_MAGMA_MGM_KTREE (Transform ID 33) is an AEAD transform based on"Magma"the "Magma" algorithm; it provides confidentiality and message authentication and thus can be used in both ESP andIKEv2</t> <t>ENCR_KUZNYECHIK_MGM_MAC_KTREEIKEv2.</li> <li>ENCR_KUZNYECHIK_MGM_MAC_KTREE (Transform ID 34) is a MAC-only transform based on"Kuznyechik"the "Kuznyechik" algorithm; it provides no confidentiality and thus can only be used in ESP, but not inIKEv2</t> <t>ENCR_MAGMA_MGM_MAC_KTREEIKEv2.</li> <li>ENCR_MAGMA_MGM_MAC_KTREE (Transform ID 35) is a MAC-only transform based on"Magma"the "Magma" algorithm; it provides no confidentiality and thus can only be used in ESP, but not inIKEv2</t> </list>IKEv2.</li> </ul> <t> 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 InitializationVector,Vector (IV), which is impossible for Type 3 (Integrity Algorithm) transforms. </t> <sectiontitle="Tree-basedanchor="key" numbered="true" toc="default"> <name>Tree-Based ExternalRe-Keying" anchor="key">Rekeying</name> <t> All four transforms use the same tree-based externalre-keyingrekeying 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, whileintermediate nodesintermediate-node keys are used to derive lower-level keys, including leaf keys. SeeSection 5.2.3 of<xref target="RFC8645"/>sectionFormat="of" section="5.2.3"/> 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 someside channelside-channel attacks and also increasing the key lifetime limitations based on combinatorial properties. </t> <t> The transforms defined in this document use a three-level tree. The leaf key that protects a message is computed as follows:<figure> <preamble></preamble></t> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ K_msg = KDF (KDF (KDF (K, l1, 0x00 | i1), l2, i2), l3, i3) ]]></artwork></figure><t> where:<list style="hanging" hangIndent="16"> <t hangText="KDF</t> <dl newline="false" spacing="normal" indent="16"> <dt>KDF (k, l,s)" >Keys)</dt> <dd>Key Derivation Function KDF_GOSTR3411_2012_256defined(defined inSection 4.5 of<xref target="RFC7836"/>,sectionFormat="of" section="4.5"/>), which accepts three input parameters--- a key (k), a label(l)(l), and a seed (s) -- and provides a new key asan output; </t> <t hangText="K">theoutput </dd> <dt>K</dt> <dd>the root key for the tree (see <xref target="keymat"/>); </t> <t hangText="l1,format="default"/>) </dd> <dt>l1, l2,l3">labelsl3</dt> <dd> <t>labels defined as6 octet6-octet ASCII strings without null termination:<list> <t>l1 = "level1"</t> <t>l2</t> <dl newline="false" spacing="normal"> <dt>l1 =</dt> <dd>"level1"</dd> <dt>l2 ="level2"</t> <t>l3</dt> <dd>"level2"</dd> <dt>l3 ="level3"</t> </list> </t> <t hangText="i1,</dt> <dd>"level3"</dd> </dl> </dd> <dt>i1, i2,i3">parametersi3</dt> <dd>parameters that determine which keys out of the tree are used on eachlevel, altogetherlevel. Together, they determine a leaf key that is used for message protection; the length of i1 is one octet, and i2 and i3 aretwo octettwo-octet integers in network byteorder; </t> <t hangText="|">indicates concatenation; </t> </list>order </dd> <dt>|</dt> <dd>indicates concatenation </dd> </dl> <t> This construction allows us to generate up to2^82<sup>8</sup> keys on level 1 and up to2^162<sup>16</sup> keys on levels 2 and 3. So, the total number of possible leaf keys generated from a singleSASecurity Association (SA) key is2^40.2<sup>40</sup>. </t> <t>This specification doesn't impose any requirements onthe frequency of which thehow frequently externalre-keyingrekeying 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. </t> </section> <sectiontitle="Initializationanchor="iv" numbered="true" toc="default"> <name>Initialization VectorFormat" anchor="iv">Format</name> <t> Each message protected by the defined transformsMUST<bcp14>MUST</bcp14> contain anInitialization Vector (IV).IV. The IV has a size of 64 bits and consists ofthefourfields, three of which arefields. The fields i1,i2i2, and i3 are parameters that determine the particular leaf key this message was protected with (see <xreftarget="key"/>), and thetarget="key" format="default"/>). The fourth field is a counter, representing the message number for this key. </t> <figuretitle="IV Format"anchor="iv_format"><preamble></preamble><name>IV Format</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t> where:<list style="symbols"> <t>i1</t> <dl spacing="normal"> <dt>i1 (1 octet), i2 (2 octets), i3 (2octets) - parameters, determiningoctets):</dt><dd>parameters that determine the particular key used to protect this message;2-octets2-octet parameters are integers in network byteorder</t> <t>pnumorder</dd> <dt>pnum (3octets) - messageoctets):</dt><dd>message counter in network byte order for the leaf key protecting this message; up to2^242<sup>24</sup> messages may be protected using a single leafkey</t> </list>key</dd> </dl> <t> For any givenSASA, the IVMUST NOT<bcp14>MUST NOT</bcp14> be used more than once, but there is no requirement that IVisbe unpredictable. </t> </section> <sectiontitle="Nonceanchor="mgm_nonce" numbered="true" toc="default"> <name>Nonce Format forMGM" anchor="mgm_nonce">MGM</name> <t> MGM requires a per-message nonce (called the Initial Counter Nonce,ICN,or ICN inthe<xref target="RFC9058"/>)format="default"/>) thatMUST<bcp14>MUST</bcp14> 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. </t> <t> 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. Sincethen is always a multiple of 8 bits, this makes MGM nonces having a whole number of octets. When used insideMGMMGM, 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 ofzerothe "zero" field (see<xrefFigures <xref target="nonce_kuznyechik_format"/>format="counter"/> and <xref target="nonce_magma_format"/>)format="counter"/>), which is always set to 0, so no information is lost when it is dropped. </t> <sectiontitle="MGManchor="nonce_kuznyechik" numbered="true" toc="default"> <name>MGM Nonce Format for"Kuznyechik" based Transforms" anchor="nonce_kuznyechik">Transforms Based on the "Kuznyechik" Cipher</name> <t> For transforms based on"Kuznyechik"the "Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE andENCR_KUZNYECHIK_MGM_MAC_KTREE)ENCR_KUZNYECHIK_MGM_MAC_KTREE), the ICN consists of azero octet,"zero" octet; a 24-bit messagecountercounter; and a 96-bit secret salt,thatwhich is fixed for the SA and is not transmitted. </t> <figuretitle="Nonce format for "Kuznyechik" based transforms"anchor="nonce_kuznyechik_format"><preamble></preamble><name>Nonce Format for Transforms Based on the "Kuznyechik" Cipher</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t> where:<list style="symbols"> <t>zero</t> <dl spacing="normal"> <dt>zero (1octet) - setoctet):</dt><dd>set to0</t> <t>pnum0</dd> <dt>pnum (3octets) - theoctets):</dt><dd>the counter for the messages protected by the given leaf key; this fieldMUST<bcp14>MUST</bcp14> be equal to the pnum field in theIV</t> <t>saltIV</dd> <dt>salt (12octets) - secret salt</t> </list> </t>octets):</dt><dd>secret salt. The salt is a string of bits that are formed when the SA is created (see <xref target="keymat"/> 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.</dd> </dl> </section> <sectiontitle="MGManchor="nonce_magma" numbered="true" toc="default"> <name>MGM Nonce Format for"Magma" based Transforms" anchor="nonce_magma">Transforms Based on the "Magma" Cipher</name> <t> For transforms based on"Magma"the "Magma" cipher (ENCR_MAGMA_MGM_KTREE andENCR_MAGMA_MGM_MAC_KTREE)ENCR_MAGMA_MGM_MAC_KTREE), the ICN consists of azero octet,"zero" octet; a 24-bit messagecountercounter; and a 32-bit secret salt,thatwhich is fixed for the SA and is not transmitted. </t> <figuretitle="Nonce format for "Magma" based transforms"anchor="nonce_magma_format"><preamble></preamble><name>Nonce Format for Transforms Based on the "Magma" Cipher</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <t> where:<list style="symbols"> <t>zero</t> <dl spacing="normal"> <dt>zero (1octet) - setoctet):</dt><dd>set to0</t> <t>pnum0</dd> <dt>pnum (3octets) - theoctets):</dt><dd>the counter for the messages protected by the given leaf key; this fieldMUST<bcp14>MUST</bcp14> be equal to the pnum field in theIV</t> <t>saltIV</dd> <dt>salt (4octets) - secret salt</t> </list> </t>octets):</dt><dd>secret salt. The salt is a string of bits that are formed when the SA is created (see <xref target="keymat"/> 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.</dd> </dl> </section> </section> <sectiontitle="Keying Material" anchor="keymat">anchor="keymat" numbered="true" toc="default"> <name>Keying Material</name> <t>We'llrefer as "transform key" tocall a string of bits thatareis used to initialize the transforms defined in thisspecification.specification a "transform key". The transform key is a composite entity consisting of the root key for the tree and the secret salt. </t> <t>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 <xref target="key"/>)format="default"/>) and the remaining 96 bits is a secret salt (see <xref target="nonce_kuznyechik"/>).format="default"/>). </t> <t>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 <xref target="key"/>)format="default"/>) and the remaining 32 bits is a secret salt (see <xref target="nonce_magma"/>).format="default"/>). </t> <t>In the case ofESPESP, the transform keys are extracted from the KEYMAT as defined inSection 2.17 of<xref target="RFC7296"/>.sectionFormat="of" section="2.17"/>. In the case ofIKEv2IKEv2, the transform keys are either SK_ei or SK_er, which are generated as defined inSection 2.14 of<xref target="RFC7296"/>.sectionFormat="of" section="2.14"/>. Note that since these transforms provide authenticated encryption, no additional keys are needed for authentication.ItThis meansthatthat, in the case ofIKEv2IKEv2, the keys SK_ai/SK_ar are not used andMUST<bcp14>MUST</bcp14> be treated as having zero length.</t> </section> <sectiontitle="Integrityanchor="icv" numbered="true" toc="default"> <name>Integrity CheckValue" anchor="icv">Value</name> <t> 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 the<xref target="RFC9058"/>sectionFormat="of" section="4"/> states that the authentication tag lengthmust<bcp14>MUST</bcp14> be fixed for a particular protocol. For"Kuznyechik" basedtransforms based on the "Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE andENCR_KUZNYECHIK_MGM_MAC_KTREE)ENCR_KUZNYECHIK_MGM_MAC_KTREE), the resulting Integrity Check Value (ICV) length is set to 96 bits. For"Magma" basedtransforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE andENCR_MAGMA_MGM_MAC_KTREE)ENCR_MAGMA_MGM_MAC_KTREE), the full ICV length is set to the block size (64 bits). </t> </section> <sectiontitle="Plaintext Padding" anchor="padding"> <t>Transformsanchor="padding" numbered="true" toc="default"> <name>Plaintext Padding</name> <t>The transforms defined in this document don't require any plaintext padding, as specified in <xref target="RFC9058"/>. It means,format="default"/>. This means that only those padding requirements that are imposed by the protocol are applied (4 bytes for ESP, no padding for IKEv2). </t> </section> <sectiontitle="AAD Construction">numbered="true" toc="default"> <name>AAD Construction</name> <sectiontitle="ESP AAD" anchor="esp_aad">anchor="esp_aad" numbered="true" toc="default"> <name>ESP AAD</name> <t> Additional Authenticated Data (AAD) in ESP is constructeddifferentlydifferently, 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 ESPSPISecurity Parameter Index (SPI) and (E)SN. The AAD is constructed similarly to theoneAAD in <xref target="RFC4106"/>.format="default"/>. </t> <t> On the otherhandhand, the ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGMA_MGM_MAC_KTREE transforms don't provideconfidentiality,confidentiality; they provide only message authentication. For thispurposepurpose, the IV and the part of the ESP packet that is normally encrypted are included in the AAD. For thesetransformstransforms, the encryption capability provided by MGM is not used. The AAD is constructed similarly to theoneAAD in <xref target="RFC4543"/>.format="default"/>. </t> <figuretitle="AADanchor="aad_aead_32"> <name>AAD for AEADtransformsTransforms with32-bit SN" anchor="aad_aead_32"> <preamble></preamble>32-Bit SN</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <figuretitle="AADanchor="aad_aead_64"> <name>AAD for AEADtransformsTransforms with64-bit ESN" anchor="aad_aead_64"> <preamble></preamble>64-Bit ESN</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <figuretitle="AADanchor="aad_mac_32"> <name>AAD forauthentication only transformsAuthentication-Only Transforms with32-bit SN" anchor="aad_mac_32"> <preamble></preamble>32-Bit SN</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> <figuretitle="AADanchor="aad_mac_64"> <name>AAD forauthentication only transformsAuthentication-Only Transforms with64-bit ESN" anchor="aad_mac_64"> <preamble></preamble>64-Bit ESN</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure></t></section> <sectiontitle="IKEv2 AAD" anchor="ikev2_aad">anchor="ikev2_aad" numbered="true" toc="default"> <name>IKEv2 AAD</name> <t> ForIKEv2IKEv2, the AAD consists of the IKEv2 Header, any unencrypted payloads following it (ifpresent)present), and either the Encrypted(orpayload header (<xref target="RFC7296" sectionFormat="of" section="3.14"/>) or the EncryptedFragment)Fragment payloadheader.(<xref target="RFC7383" sectionFormat="of" section="2.5"/>), depending on whether IKE fragmentation is used. The AAD is constructedsimilarsimilarly to theoneAAD in <xref target="RFC5282"/>.format="default"/>. </t> <figuretitle="AADanchor="aad_ikev2_encr_payload_format"> <name>AAD forIKEv2" anchor="aad_ikev2_format"> <preamble></preamble>IKEv2 in the Case of the Encrypted Payload</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure></t><figure anchor="aad_ikev2_encr_frag_payload_format"> <name>AAD for IKEv2 in the Case of the Encrypted Fragment Payload</name> <artwork align="center" name="" type="" alt=""><![CDATA[ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </section> </section> <sectiontitle="Using Transforms" anchor="use">anchor="use" numbered="true" toc="default"> <name>Using Transforms</name> <t>When the SA isestablishedestablished, the i1,i2i2, 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 to00, and the process continues. If the senderdecides,decides that a third-level key corresponding to i3 is used enough times, it increments i2, resets i3 to00, and calculates a new leaf key. The pnum is reset to 0 (as with every new leafkey)key), and the process continues.SimilarA similar procedure is used when a second-level key needs to be changed. </t> <t>A combination of i1, i2,i3i3, and pnumMUST NOT<bcp14>MUST NOT</bcp14> repeat for any particular SA. This means that the wrappingaroundof these counters is not allowed: when i2,i3i3, or pnumreach theirreaches its respective maximumvalues,value, a procedureoffor changing a leafkeykey, describedaboveabove, is executed, and if all four parameters reach their maximum values, the IPsec SA becomes unusable. </t> <t>There may be other reasons to recalculate leaf keysbesidebesides reaching maximum values for the counters. For example, as described in <xref target="security"/>,format="default"/>, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> 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 <xref target="security"/>format="default"/> for each of the ciphers. </t> <t>The receiver always uses i1,i2i2, 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 improveperformanceperformance, implementations may cache recently used leafkey.keys. When a new leaf key is calculated (based on the values from the receivedmessage)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). </t> </section> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> The most important security consideration for MGM is that the nonceMUST NOT<bcp14>MUST NOT</bcp14> repeat for a given key. For thisreasonreason, the transforms defined in this documentMUST NOT<bcp14>MUST NOT</bcp14> be used with manual keying. </t> <t> Excessive use of the same key can give an attacker advantages in breaking security properties of the transforms defined in this document. For thisreasonreason, 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"),"Magma"), which currently are generally considered insecure after protecting a relatively small amount of data. For example, Section 3.4 of <xref target="SP800-67"/>format="default"/> limits the number of blocks that are allowed to be encrypted with the Triple DES cipherby 2^20to 2<sup>20</sup> (8MbytesMB of data). This document defines a rekeying mechanism that allowsto mitigate athe mitigation of weak security of a 64-bit block cipher byfrequentfrequently changingofthe encryption key. </t> <t> For transforms defined in this document, <xref target="GOST-ESP"/>format="default"/> recommends limiting the number of octets protected with a singleKmsgK_msg key by the following values:<list style="symbols"> <t>for</t> <ul> <li>2<sup>41</sup> octets for transforms based on"Kuznyechik"the "Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE andENCR_KUZNYECHIK_MGM_MAC_KTREE) - 2^41 octets;</t> <t>forENCR_KUZNYECHIK_MGM_MAC_KTREE)</li> <li>2<sup>28</sup> octets for transforms based on"Magma"the "Magma" cipher (ENCR_MAGMA_MGM_KTREE andENCR_MAGMA_MGM_MAC_KTREE) - 2^28 octets;</t> </list>ENCR_MAGMA_MGM_MAC_KTREE)</li> </ul> <t> These values are based on combinatorial properties and may be further restricted ifside channelsside-channel attacks are taken intoconsiderations.consideration. Note that the limit for"Kuznyechik" basedtransforms based on the "Kuznyechik" cipher is unreachablebecausebecause, due totransformsthe construction of the transforms, the number of protected messages is limited to2^242<sup>24</sup> and each message (either IKEv2messagemessages or ESPdatagram)datagrams) is limited to2^162<sup>16</sup> octets in size, giving2^402<sup>40</sup> octets as the maximum amount of data that can be protected with a singleKmsg.K_msg. </t><t>Section 4 of <xref<t><xref target="RFC9058"/>sectionFormat="of" section="4"/> discusses the possibility of truncating authentication tags in MGM as a trade-off between message expansion and theforgery probability.probability of forgery. This specification truncates an authentication tag length for"Kuznyechik" basedtransforms based on the "Kuznyechik" cipher to 96 bits. This decreases message expansion while still providing a very lowforgeryprobability of2^-96.forgery: 2<sup>-96</sup>. </t> <t>An attacker can send a lot of packets witharbitraryarbitrarily chosen i1, i2, and i3 parameters. This will 1) force arecepientrecipient to recalculate the leaf key for every received packet if i1, i2, and i3 are different fromthe previous one,these values in previously received packets, thus consuming CPU resources and 2) force arecepientrecipient to make verification attempts (that would fail) on a large amount of data, thus allowing the attackerfora deeperanalyzinganalysis of the underlying cryptographic primitive (see <xreftarget="I-D.irtf-cfrg-aead-limits" />).target="AEAD-USAGE-LIMITS" format="default"/>). ImplementationsMAY<bcp14>MAY</bcp14> initiatere-keyingrekeying if they deem that they receive too many packets with an invalid ICV. </t> <t> Security properties of MGM are discussed in <xref target="MGM-SECURITY"/>.format="default"/>. </t> </section> <section anchor="iana"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t> IANA maintains a registryofcalled "Internet Key Exchange Version 2 (IKEv2) Parameters" with asub-registry ofsubregistry called "Transform Type Values". IANA hasassignedadded the following four Transform IDsinto the "Transform Type 1 - Encryption Algorithm Transform IDs"registry and is requested to update their references to this document (where RFCXXXX is this document): </t> <figure> <preamble></preamble> <artwork align="center"><![CDATA[ Number Name ESP Reference IKEv2 Reference --------------------------------------------------------------------- 32 ENCR_KUZNYECHIK_MGM_KTREE [RFCXXXX] [RFCXXXX] 33 ENCR_MAGMA_MGM_KTREE [RFCXXXX] [RFCXXXX] 34 ENCR_KUZNYECHIK_MGM_MAC_KTREE [RFCXXXX] Not allowed 35 ENCR_MAGMA_MGM_MAC_KTREE [RFCXXXX] Not allowed ]]></artwork> </figure> </section> <section title="Acknowledgments" anchor="acknowledgments"> <t>Author wants to thank Adrian Farrel, Russ Housley, Yaron Sheffer and Stanislav Smyshlyaev for valuable input in the process of publication this document.subregistry. </t> <table anchor="iana-table"> <name>Transform IDs</name> <thead> <tr> <th>Number</th> <th>Name</th> <th>ESP Reference</th> <th>IKEv2 Reference</th> </tr> </thead> <tbody> <tr> <td>32</td> <td>ENCR_KUZNYECHIK_MGM_KTREE</td> <td>RFC 9227</td> <td>RFC 9227</td> </tr> <tr> <td>33</td> <td>ENCR_MAGMA_MGM_KTREE</td> <td>RFC 9227</td> <td>RFC 9227</td> </tr> <tr> <td>34</td> <td>ENCR_KUZNYECHIK_MGM_MAC_KTREE</td> <td>RFC 9227</td> <td>Not allowed</td> </tr> <tr> <td>35</td> <td>ENCR_MAGMA_MGM_MAC_KTREE</td> <td>RFC 9227</td> <td>Not allowed</td> </tr> </tbody> </table> </section> </middle> <back><references title='Normative References'> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6986.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7801.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8891.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9058.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7836.xml" ?><references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7383.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6986.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7801.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8891.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9058.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7836.xml"/> </references><references title='Informative References'><references> <name>Informative References</name> <reference anchor="GOST3411-2012"> <front> <title>Information technology. CryptographicData Security. Hashingdata security. Hash function</title> <author> <organization>Federal Agency on Technical Regulating and Metrology</organization> </author> <date month="August" year="2012"/> </front> <seriesInfo name="GOST R" value="34.11-2012"/> <annotation>(In Russian)</annotation> </reference> <reference anchor="GOST3412-2015"> <front> <title>Information technology. Cryptographic data security. Block ciphers</title> <author> <organization>Federal Agency on Technical Regulating and Metrology</organization> </author> <date month="June" year="2015"/> </front> <seriesInfo name="GOST R" value="34.12-2015"/> <annotation>(In Russian)</annotation> </reference> <reference anchor="GOST-MGM"> <front> <title>Information technology. Cryptographicdatainformation security. Block Cipher Modes Implementing Authenticatedencryption block cipher operation modes</title>Encryption</title> <author> <organization>Federal Agency on Technical Regulating and Metrology</organization> </author> <date month="September" year="2019"/> </front> <seriesInfo name="R" value="1323565.1.026-2019"/> <annotation>(In Russian)</annotation> </reference> <reference anchor="GOST-ESP"> <front> <title>Information technology. Cryptographicdata security. Usinginformation protection. The use of Russian cryptographic algorithms indata security protocol ESP</title>the ESP information protection protocol</title> <author> <organization>Federal Agency on Technical Regulating and Metrology</organization> </author> <date month="January" year="2021"/> </front> <seriesInfo name="R" value="1323565.1.035-2021"/> <annotation>(In Russian)</annotation> </reference><?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4106.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4543.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5282.xml" ?> <?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8645.xml" ?><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4106.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4543.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5282.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8645.xml"/> <reference anchor="MGM-SECURITY" target="https://eprint.iacr.org/2019/123.pdf"> <front> <title>Security of Multilinear Galois Mode (MGM)</title> <author fullname="LiliyaAkhmetzyanova" />Akhmetzyanova"/> <author fullname="EvgenyAlekseev" />Alekseev"/> <author fullname="GrigoryKarpunin" />Karpunin"/> <author fullname="VladislavNozdrunov" />Nozdrunov"/> <date year="2019"/> </front> </reference> <reference anchor="SP800-67" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-67r2.pdf"> <front> <title>Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher</title><author ><author> <organization>National Institute of Standards and Technology</organization> </author> <date month="November" year="2017"/> </front> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-67r2"/> </reference><?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-aead-limits.xml" ?><!-- draft-irtf-cfrg-aead-limits (I-D Exists) ("Long way" to fix author initials) --> <reference anchor="AEAD-USAGE-LIMITS"> <front> <title>Usage Limits on AEAD Algorithms</title> <author fullname="Felix Günther"> <organization>ETH Zurich</organization> </author> <author fullname="Martin Thomson"> <organization>Mozilla</organization> </author> <author fullname="Christopher A. Wood" initials="C.A."> <organization>Cloudflare</organization> </author> <date month="March" day="7" year="2022" /> </front> <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-aead-limits-04" /> </reference> </references> </references> <sectiontitle="Test Vectors" anchor="testvec">anchor="testvec" numbered="true" toc="default"> <name>Test Vectors</name> <t> In the following testvectorsvectors, binary data is represented in hexadecimal format. The numbers in squarebracketbrackets indicate the size of the corresponding data in decimal format.<list style="numbers"> <t>ENCR_KUZNYECHIK_MGM_KTREE, example 1: <figure> <preamble></preamble> <artwork align="left"><![CDATA[</t> <ol spacing="normal" type="1"><li> <t>ENCR_KUZNYECHIK_MGM_KTREE (Example 1): </t> <sourcecode name="" type="test-vectors"><![CDATA[ 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]]></artwork> </figure>]]></sourcecode> </li> <li> <t>ENCR_KUZNYECHIK_MGM_KTREE (Example 2): </t><t>ENCR_KUZNYECHIK_MGM_KTREE, example 2: <figure> <preamble></preamble> <artwork align="left"><![CDATA[<sourcecode name="" type="test-vectors"><![CDATA[ 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]]></artwork> </figure>]]></sourcecode> </li> <li> <t>ENCR_MAGMA_MGM_KTREE (Example 1): </t><t>ENCR_MAGMA_MGM_KTREE, example 1: <figure> <preamble></preamble> <artwork align="left"><![CDATA[<sourcecode name="" type="test-vectors"><![CDATA[ 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]]></artwork> </figure>]]></sourcecode> </li> <li> <t>ENCR_MAGMA_MGM_KTREE (Example 2): </t><t>ENCR_MAGMA_MGM_KTREE, example 2: <figure> <preamble></preamble> <artwork align="left"><![CDATA[<sourcecode name="" type="test-vectors"><![CDATA[ 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]]></artwork> </figure>]]></sourcecode> </li> <li> <t>ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 1): </t><t>ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 1: <figure> <preamble></preamble> <artwork align="left"><![CDATA[<sourcecode name="" type="test-vectors"><![CDATA[ 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]]></artwork> </figure>]]></sourcecode> </li> <li> <t>ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 2): </t><t>ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 2: <figure> <preamble></preamble> <artwork align="left"><![CDATA[<sourcecode name="" type="test-vectors"><![CDATA[ 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]]></artwork> </figure>]]></sourcecode> </li> <li> <t>ENCR_MAGMA_MGM_MAC_KTREE (Example 1): </t><t>ENCR_MAGMA_MGM_MAC_KTREE, example 1: <figure> <preamble></preamble> <artwork align="left"><![CDATA[<sourcecode name="" type="test-vectors"><![CDATA[ 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]]></artwork> </figure>]]></sourcecode> </li> <li> <t>ENCR_MAGMA_MGM_MAC_KTREE (Example 2): </t><t>ENCR_MAGMA_MGM_MAC_KTREE, example 2: <figure> <preamble></preamble> <artwork align="left"><![CDATA[<sourcecode name="" type="test-vectors"><![CDATA[ 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]]></artwork> </figure> </t> </list>]]></sourcecode> </li> </ol> </section> <section anchor="acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</name> <t>The author wants to thank <contact fullname="Adrian Farrel"/>, <contact fullname="Russ Housley"/>, <contact fullname="Yaron Sheffer"/>, and <contact fullname="Stanislav Smyshlyaev"/> for valuable input during the publication process for this document. </t> </section> </back> </rfc>