Diff: rfc9227xml2.original.xml

	rfc9227xml2.original.xml	rfc9227.xml
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>


	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
	<rfc category="info" ipr="trust200902" docName="draft-smyslov-esp-gost-14">	<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	<!ENTITY wj "⁠">
		]>
	<?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="no"?>
	<?rfc iprnotified="no" ?>
	<?rfc strict="yes" ?>

	<front>
	<title abbrev="GOST ciphers in ESP & IKEv2">Using GOST ciphers in ES
	P and IKEv2</title>
	<author initials='V.' surname="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>
	</postal>
	<phone>+7 495 276 0211</phone>
	<email>svan@elvis.ru</email>
	</address>
	</author>
	<date/>


	<keyword>AEAD</keyword>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<keyword>MGM</keyword>	-smyslov-esp-gost-14" number="9227" obsoletes="" updates="" submissionType="inde
		pendent" category="info" xml:lang="en" tocInclude="true" symRefs="true" sortRefs
		="false" version="3">


	<abstract>	<!-- xml2rfc v2v3 conversion 3.12.1 -->
	<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) protocols which a
	re parts of the IP Security (IPsec) protocols suite.
	The transforms are based on the GOST R 34.12-2015 block ciphers (whi
	ch are named "Magma" and "Kuznyechik")
	in a Multilinear Galois Mode (MGM) and the external re-keying approa
	ch.
	</t>


	<t> This specification is developed to facilitate implementations th	<front>
	at wish to support the GOST algorithms.	<title abbrev="GOST Ciphers in ESP and IKEv2">Using GOST Ciphers in the Enca
		psulating Security Payload (ESP) and Internet Key Exchange Version 2 (IKEv2) Pro
		tocols</title>
		<seriesInfo name="RFC" value="9227"/>
		<author initials="V." surname="Smyslov" fullname="Valery Smyslov">
		<organization>ELVIS-PLUS</organization>
		<address>
		<postal>
		<street>PO Box 81</street>
		<city>Moscow (Zelenograd)</city>
		<code>124460</code>
		<country>Russian Federation</country>
		</postal>
		<phone>+7 495 276 0211</phone>
		<email>svan@elvis.ru</email>
		</address>
		</author>
		<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 En
		capsulating 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 (whi
		ch are named "Magma" and "Kuznyechik")
		in Multilinear Galois Mode (MGM) and the external rekeying approach.
		</t>
		<t> This specification was developed to facilitate implementations that wi
		sh to support the GOST algorithms.
	This document does not imply IETF endorsement of the cryptographic a lgorithms used in this document.	This document does not imply IETF endorsement of the cryptographic a lgorithms used in this document.

	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>
		<middle>
	<middle>	<section anchor="intro" numbered="true" toc="default">
	<section title="Introduction" anchor="intro">	<name>Introduction</name>
	<t> The IP Security (IPsec) protocols suite consists of several prot	<t> The IP Security (IPsec) protocol suite consists of several protocols,
	ocols, of which	of which
	the Encapsulating Security Payload (ESP) <xref target="RFC4303" /> a	the Encapsulating Security Payload (ESP) <xref target="RFC4303" form
	nd	at="default"/> and
	the Internet Key Exchange version 2 (IKEv2) <xref target="RFC7296" /	the Internet Key Exchange version 2 (IKEv2) <xref target="RFC7296" f
	> are most widely used.	ormat="default"/> are most widely used.
	This document defines four transforms for ESP and IKEv2 based on Rus	This document defines four transforms for ESP and IKEv2 based on Rus
	sian cryptographic standard algorithms (often referred to as "GOST" al	sian cryptographic standard algorithms (often referred to as "GOST" algorithms).
	gorithms).	These definitions are based on the recommendations <xref target="GOS
	This definition is based on the Recommendations <xref target="GOST-E	T-ESP" format="default"/> established by the Federal Agency on Technical Regulat
	SP" /> established by Federal Agency on Technical Regulating and Metrology (Ross	ing and Metrology (Rosstandart),
	tandart),	which describe how Russian cryptographic standard algorithms are use
	which describe how Russian cryptographic standard algorithms are use	d in ESP and IKEv2. The transforms defined in this document are based
	d in ESP and IKEv2. Transforms defined in this document are based	on two block ciphers from Russian cryptographic standard algorithms
	on two block ciphers from Russian cryptographic standard algorithms	--
	-	"Kuznyechik" <xref target="GOST3412-2015" format="default"/> <xref t
	"Kuznyechik" <xref target="GOST3412-2015" /><xref target="	arget="RFC7801" format="default"/>
	RFC7801" />	and "Magma" <xref target="GOST3412-2015" format="default"/> <xref ta
	and "Magma" <xref target="GOST3412-2015" /><xref target="R	rget="RFC8891" format="default"/>
	FC8891" />	in Multilinear Galois Mode (MGM) <xref target="GOST-MGM" format="def
	in Multilinear Galois Mode (MGM) <xref target="GOST-MGM" /><xref tar	ault"/> <xref target="RFC9058" format="default"/>. These transforms
	get="RFC9058" />. These transforms	provide Authenticated Encryption with Associated Data (AEAD). An ext
	provide Authenticated Encryption with Associated Data (AEAD). An ext	ernal rekeying mechanism, described in <xref target="RFC8645" format="default"/>
	ernal re-keying mechanism, described in <xref target="RFC8645" />	,
	is also used in these transforms to limit load on session keys.	is also used in these transforms to limit the load on session keys.
	</t>	</t>
		<t> Because the GOST specification includes the definition of both 128-bit
	<t> Because the GOST specification includes the definition of both 1	("Kuznyechik") and 64-bit ("Magma")
	28 ("Kuznyechik") and 64 ("Magma")	block ciphers, both are included in this document. Implementers shou
	bit block ciphers, both are included in this document. Implementers	ld make themselves aware of the relative security
	should make themselves aware of the relative security	and other cost-benefit implications of the two ciphers. See <xref ta
	and other cost-benefit implications of the two ciphers. See <xref ta	rget="security" format="default"/> for more details.
	rget="security" /> for more details.	</t>
	</t>	<t> This specification was developed to facilitate implementations that wi
		sh to support the GOST algorithms.
	<t> This specification is developed to facilitate implementations th
	at wish to support the GOST algorithms.
	This document does not imply IETF endorsement of the cryptographic a lgorithms used in this document.	This document does not imply IETF endorsement of the cryptographic a lgorithms used in this document.

	</t>	</t>
	</section>	</section>
		<section anchor="req_lang" numbered="true" toc="default">
	<section title="Requirements Language" anchor="req_lang">	<name>Requirements Language</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	",	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in BC	"<bcp14>SHOULD NOT</bcp14>",
	P	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> whe	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	n,	are to be interpreted as described in BCP 14
	and only when, they appear in all capitals, as shown here.</t>	<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
	</section>	when, they appear in all capitals, as shown here.</t>
		</section>
	<section title="Overview" anchor="overview">	<section anchor="overview" numbered="true" toc="default">
	<t> Russian cryptographic standard algorithms, often referred as &qu	<name>Overview</name>
	ot;GOST" algorithms,	<t> Russian cryptographic standard algorithms, often referred to as "GOST"
	constitute a set of cryptographic algorithms of different types - ci	algorithms,
	phers, hash functions, digital	constitute a set of cryptographic algorithms of different types -- c
	signatures, etc. In particular, Russian cryptographic standard <xref	iphers, hash functions, digital
	target="GOST3412-2015" />	signatures, etc. In particular, Russian cryptographic standard <xref
	defines two block ciphers - "Kuznyechik" (also defined in	target="GOST3412-2015" format="default"/>
	<xref target="RFC7801" />)	defines two block ciphers -- "Kuznyechik" (also defined in <xref tar
	and "Magma" (also defined in <xref target="RFC8891" />). B	get="RFC7801" format="default"/>)
	oth	and "Magma" (also defined in <xref target="RFC8891" format="default"
	ciphers use 256-bit key. "Kuznyechik" has a block size of	/>). Both
	128 bits, while "Magma"	ciphers use a 256-bit key. "Kuznyechik" has a block size of 128 bits
		, while "Magma"
	has a 64-bit block.	has a 64-bit block.

	</t>	</t>
		<t> Multilinear Galois Mode (MGM) is an AEAD mode defined in <xref target=
	<t> Multilinear Galois Mode (MGM) is an AEAD mode defined in <xref t	"GOST-MGM" format="default"/> and <xref target="RFC9058" format="default"/>.
	arget="GOST-MGM" /><xref target="RFC9058" />.	It is claimed to provide defense against some attacks on well-known
	It is claimed to provide defense against some attacks on well-known	AEAD modes, like Galois/Counter Mode (GCM).
	AEAD modes, like Galois Counter Mode (GCM).	</t>
	</t>	<t> <xref target="RFC8645" format="default"/> defines mechanisms that can
		be used
	<t> <xref target="RFC8645" /> defines mechanisms that can be used
	to limit the number of times any particular session key is used. One of these mechanisms,	to limit the number of times any particular session key is used. One of these mechanisms,

	called external re-keying with tree-based construction (defined in S	called external rekeying with tree-based construction (defined in <x
	ection 5.2.3 of <xref target="RFC8645" />),	ref target="RFC8645" sectionFormat="of" section="5.2.3"/>),
	is used in the defined transforms. For the purpose of deriving subor	is used in the defined transforms. For the purpose of deriving subor
	dinate keys	dinate keys,
	a Key Derivation Function (KDF) KDF_GOSTR3411_2012_256 defined in Se	the Key Derivation Function (KDF) KDF_GOSTR3411_2012_256, defined in
	ction 4.5 of	<xref target="RFC7836" sectionFormat="of" section="4.5"/>,
	<xref target="RFC7836" />, is used. This KDF is based on an HMAC <xr	is used. This KDF is based on a Hashed Message Authentication Code (HMAC) const
	ef target="RFC2104" /> construction with	ruction <xref target="RFC2104" format="default"/> with
	a Russian GOST hash function defined in Russian cryptographic standa	a Russian GOST hash function defined in Russian cryptographic standa
	rd <xref target="GOST3411-2012" /> (also defined	rd <xref target="GOST3411-2012" format="default"/> (also defined
	in <xref target="RFC6986" />).	in <xref target="RFC6986" format="default"/>).
	</t>	</t>
	</section>	</section>
		<section 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 tre
		e-based
		external rekeying. The transforms differ in underlying ciphers and i
		n cryptographic services they provide.
		</t>


	<section title="Transforms Description" anchor="transforms">	<ul spacing="normal">
	<t> This document defines four transforms of Type 1 (Encryption Algo	<li>ENCR_KUZNYECHIK_MGM_KTREE (Transform ID 32) is an AEAD transform bas
	rithm) for use in ESP and IKEv2. All of them use MGM mode of operation with tree	ed on the "Kuznyechik" algorithm; it provides
	-based	confidentiality and message authentication and thus can be used
	external re-keying. The transforms differ in underlying ciphers and	in both ESP and IKEv2.</li>
	in cryptographic services they provide.	<li>ENCR_MAGMA_MGM_KTREE (Transform ID 33) is an AEAD transform based on
	<list style="symbols">	the "Magma" algorithm; it provides
	<t>ENCR_KUZNYECHIK_MGM_KTREE (Transform ID 32) is an AEAD transf	confidentiality and message authentication and thus can be used
	orm based on "Kuznyechik" algorithm; it provides	in both ESP and IKEv2.</li>
	confidentiality and message authentication and thus can be used	<li>ENCR_KUZNYECHIK_MGM_MAC_KTREE (Transform ID 34) is a MAC-only transf
	in both ESP and IKEv2</t>	orm based on the "Kuznyechik" algorithm; it provides
	<t>ENCR_MAGMA_MGM_KTREE (Transform ID 33) is an AEAD transform b	no confidentiality and thus can only be used in ESP, but not in
	ased on "Magma" algorithm; it provides	IKEv2.</li>
	confidentiality and message authentication and thus can be used	<li>ENCR_MAGMA_MGM_MAC_KTREE (Transform ID 35) is a MAC-only transform b
	in both ESP and IKEv2</t>	ased on the "Magma" algorithm; it provides
	<t>ENCR_KUZNYECHIK_MGM_MAC_KTREE (Transform ID 34) is a MAC-only	no confidentiality and thus can only be used in ESP, but not in
	transform based on "Kuznyechik" algorithm; it provides	IKEv2.</li>
	no confidentiality and thus can only be used in ESP, but not in	</ul>
	IKEv2</t>	<t>
	<t>ENCR_MAGMA_MGM_MAC_KTREE (Transform ID 35) is a MAC-only tran
	sform based on "Magma" algorithm; it provides
	no confidentiality and thus can only be used in ESP, but not in
	IKEv2</t>
	</list>
	Note that transforms ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGMA_MG M_MAC_KTREE don't provide any confidentiality,	Note that transforms ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGMA_MG M_MAC_KTREE don't provide any confidentiality,

	but they are defined as Type 1 (Encryption Algorithm) transforms bec ause of the need to include an Initialization Vector,	but they are defined as Type 1 (Encryption Algorithm) transforms bec ause of the need to include an Initialization Vector (IV),
	which is impossible for Type 3 (Integrity Algorithm) transforms.	which is impossible for Type 3 (Integrity Algorithm) transforms.

	</t>	</t>
		<section anchor="key" numbered="true" toc="default">
	<section title="Tree-based External Re-Keying" anchor="key">	<name>Tree-Based External Rekeying</name>
	<t> All four transforms use the same tree-based external re-keyi	<t> All four transforms use the same tree-based external rekeying mechan
	ng mechanism. The idea is that	ism. 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 .	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 me	This tree may have several levels. The leaf keys are used for me
	ssage protection, while intermediate nodes keys are used to derive	ssage protection, while intermediate-node keys are used to derive
	lower-level keys, including leaf keys. See Section 5.2.3 of <xre	lower-level keys, including leaf keys.
	f target="RFC8645" /> for more details.	See <xref target="RFC8645" sectionFormat="of" section="5.2.3"/> for more detail
		s.
	This construction allows us to protect a large amount of data, a t the same time providing a bound on a number of times any particular key	This construction allows us to protect a large amount of data, a t 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 at	in the tree is used, thus defending against some side-channel at
	tacks and also increasing the key lifetime limitations based on combinatorial pr	tacks and also increasing the key lifetime limitations based on combinatorial pr
	operties.	operties.
	</t>	</t>
		<t> The transforms defined in this document use a three-level tree. The
	<t> The transforms defined in this document use a three-level tr	leaf key that protects a message is computed
	ee. The leaf key that protects a message is computed
	as follows:	as follows:


	<figure>	</t>
	<preamble></preamble>	<artwork align="center" name="" type="" alt=""><![CDATA[
	<artwork align="center"><![CDATA[
	K_msg = KDF (KDF (KDF (K, l1, 0x00 \| i1), l2, i2), l3, i3)	K_msg = KDF (KDF (KDF (K, l1, 0x00 \| i1), l2, i2), l3, i3)
	]]></artwork>	]]></artwork>

	</figure>	<t>

	where:	where:

	<list style="hanging" hangIndent="16">	</t>
	<t hangText="KDF (k, l, s)" >Key Derivation Function KDF_GOS	<dl newline="false" spacing="normal" indent="16">
	TR3411_2012_256 defined in Section 4.5 of <xref target="RFC7836" />, which	<dt>KDF (k, l, s)</dt>
	accepts three input parameters - a key (k), a label (l) and	<dd>Key Derivation Function KDF_GOSTR3411_2012_256 (defined in <xref t
	a seed (s) and provides a new key as an output;	arget="RFC7836" sectionFormat="of" section="4.5"/>), which
	</t>	accepts three input parameters -- a key (k), a label (l), an
	<t hangText="K">the root key for the tree (see <xref target=	d a seed (s) -- and provides a new key as output
	"keymat" />);	</dd>
	</t>	<dt>K</dt>
	<t hangText="l1, l2, l3">labels defined as 6 octet ASCII str	<dd>the root key for the tree (see <xref target="keymat" format="defau
	ings without null termination:	lt"/>)
	<list>	</dd>
	<t>l1 = "level1"</t>	<dt>l1, l2, l3</dt>
	<t>l2 = "level2"</t>	<dd>
	<t>l3 = "level3"</t>	<t>labels defined as 6-octet ASCII strings without null termination:
	</list>	</t>
	</t>	<dl newline="false" spacing="normal">
	<t hangText="i1, i2, i3">parameters that determine which key	<dt>l1 =</dt>
	s out of the tree are used on each level,	<dd>"level1"</dd>
	altogether they determine a leaf key that is used for messag	<dt>l2 = </dt>
	e protection; the length of i1 is one octet,	<dd>"level2"</dd>
	i2 and i3 are two octet integers in network byte order;	<dt>l3 = </dt>
	</t>	<dd>"level3"</dd>
	<t hangText="\|">indicates concatenation;	</dl>
	</t>	</dd>
	</list>	<dt>i1, i2, i3</dt>
	This construction allows us to generate up to 2^8 keys on level	<dd>parameters that determine which keys out of the tree are used on e
	1 and up to 2^16 keys on levels 2 and 3.	ach level.
	So, the total number of possible leaf keys generated from a sing	Together, they determine a leaf key that is used for message
	le SA key is 2^40.	protection; the length of i1 is one octet, and
	</t>	i2 and i3 are two-octet integers in network byte order
		</dd>
	<t>This specification doesn't impose any requirements on the fre	<dt>\|</dt>
	quency of which the external re-keying takes place.	<dd>indicates concatenation
	It is expected that sending application will follow its own poli	</dd>
	cy dictating how many times the keys on each level must be used.	</dl>
	</t>	<t>
	</section>	This construction allows us to generate up to 2<sup>8</sup> keys
		on level 1 and up to 2<sup>16</sup> keys on levels 2 and 3.
	<section title="Initialization Vector Format" anchor="iv">	So, the total number of possible leaf keys generated from a sing
	<t> Each message protected by the defined transforms MUST contai	le Security Association (SA) key is 2<sup>40</sup>.
	n an Initialization Vector (IV).	</t>
	The IV has a size of 64 bits and consists of the four fields, th	<t>This specification doesn't impose any requirements on how frequently
	ree of which are i1, i2 and i3	external rekeying takes place.
	parameters that determine the particular leaf key this message w	It is expected that the sending application will follow its own
	as protected with (see <xref target="key"/>),	policy dictating how many times the keys on each level must be used.
	and the fourth is a counter, representing the message number for	</t>
	this key.	</section>
		<section anchor="iv" numbered="true" toc="default">
		<name>Initialization Vector Format</name>
		<t> Each message protected by the defined transforms <bcp14>MUST</bcp14>
		contain an IV.
		The IV has a size of 64 bits and consists of four fields. The fi
		elds i1, i2, and i3 are
		parameters that determine the particular leaf key this message w
		as protected with (see <xref target="key" format="default"/>).
		The fourth field is a counter, representing the message number f
		or this key.


	<figure title="IV Format" anchor="iv_format">	</t>
	<preamble></preamble>	<figure anchor="iv_format">
	<artwork align="center"><![CDATA[	<name>IV Format</name>
		<artwork align="center" name="" type="" alt=""><![CDATA[
	1 2 3	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	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 \|	\| i1 \| i2 \| i3 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| i3 (cont) \| pnum \|	\| i3 (cont) \| pnum \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>
	where:	where:

	<list style="symbols">	</t>
	<t>i1 (1 octet), i2 (2 octets), i3 (2 octets) - parameters,	<dl spacing="normal">
	determining the particular key used to protect this message;	<dt>i1 (1 octet), i2 (2 octets), i3 (2 octets):</dt><dd>parameters tha
	2-octets parameters are integers in network byte order</t>	t determine the particular key used to protect this message;
	<t>pnum (3 octets) - message counter in network byte order f	2-octet parameters are integers in network byte order</dd>
	or the leaf key protecting this message; up to 2^24 messages may be protected us	<dt>pnum (3 octets):</dt><dd>message counter in network byte order for
	ing	the leaf key protecting this message; up to 2<sup>24</sup> messages may be prot
	a single leaf key</t>	ected using
	</list>	a single leaf key</dd>
	For any given SA the IV MUST NOT be used more than once, but the	</dl>
	re is no requirement that IV is unpredictable.	<t>
	</t>	For any given SA, the IV <bcp14>MUST NOT</bcp14> be used more th
	</section>	an once, but there is no requirement that IV be unpredictable.
		</t>
	<section title="Nonce Format for MGM" anchor="mgm_nonce">	</section>
	<t> MGM requires a per-message nonce (called Initial Counter Non	<section anchor="mgm_nonce" numbered="true" toc="default">
	ce, ICN, in the <xref target="RFC9058" />)	<name>Nonce Format for MGM</name>
	that MUST be unique in the context of any leaf key. The size of	<t> MGM requires a per-message nonce (called the Initial Counter Nonce,
	the ICN	or ICN in <xref target="RFC9058" format="default"/>)
		that <bcp14>MUST</bcp14> be unique in the context of any leaf ke
		y. 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	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.	transforms defined in this document have different block sizes, so two different formats for the ICN are defined.

	</t>	</t>
		<t> MGM specification requires that the nonce be n-1 bits in size, where
	<t> MGM specification requires that the nonce be n-1 bits in siz	n is the block size of the underlying cipher.
	e, where n is the block size of the underlying cipher.
	This document defines MGM nonces having n bits (the block size o f the underlying cipher) in size.	This document defines MGM nonces having n bits (the block size o f the underlying cipher) in size.

	Since the n is always a multiple of 8 bits, this makes MGM nonce	Since n is always a multiple of 8 bits, this makes MGM nonces ha
	s having a whole number of octets.	ving a whole number of octets.
	When used inside MGM the most significant bit of the first octet	When used inside MGM, the most significant bit of the first octe
	of the nonce (represented as an octet string) is	t of the nonce (represented as an octet string) is
	dropped, making the effective size of the nonce equal to n-1 bit	dropped, making the effective size of the nonce equal to n-1 bit
	s. Note that the dropped bit is a part of zero field	s. Note that the dropped bit is a part of the "zero" field
	(see <xref target="nonce_kuznyechik_format" /> and <xref target=	(see Figures <xref target="nonce_kuznyechik_format" format=
	"nonce_magma_format" />) which is always set to 0,	"counter"/> and <xref target="nonce_magma_format" format="counter"/>), which is
		always set to 0,
	so no information is lost when it is dropped.	so no information is lost when it is dropped.

	</t>	</t>
		<section anchor="nonce_kuznyechik" numbered="true" toc="default">
	<section title="MGM Nonce Format for "Kuznyechik" base	<name>MGM Nonce Format for Transforms Based on the "Kuznyechik" Cipher
	d Transforms" anchor="nonce_kuznyechik">	</name>
	<t> For transforms based on "Kuznyechik" cipher (E	<t> For transforms based on the "Kuznyechik" cipher (ENCR_KUZNYECHIK_M
	NCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE)	GM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE),
	the ICN consists of a zero octet, a 24-bit message counter a	the ICN consists of a "zero" octet; a 24-bit message counter
	nd a 96-bit secret salt, that is fixed for SA and is not transmitted.	; and a 96-bit secret salt, which is fixed for the SA and is not transmitted.
		</t>
	<figure title="Nonce format for "Kuznyechik" based	<figure anchor="nonce_kuznyechik_format">
	transforms" anchor="nonce_kuznyechik_format">	<name>Nonce Format for Transforms Based on the "Kuznyechik" Cipher</
	<preamble></preamble>	name>
	<artwork align="center"><![CDATA[	<artwork align="center" name="" type="" alt=""><![CDATA[
	1 2 3	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	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 \|	\| zero \| pnum \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|	\| \|
	\| salt \|	\| salt \|
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>
	where:	where:

	<list style="symbols">	</t>
	<t>zero (1 octet) - set to 0</t>	<dl spacing="normal">
	<t>pnum (3 octets) - the counter for the messages protec	<dt>zero (1 octet):</dt><dd>set to 0</dd>
	ted by the given leaf key; this field MUST be equal to the pnum field in the IV<	<dt>pnum (3 octets):</dt><dd>the counter for the messages protected
	/t>	by the given leaf key; this field <bcp14>MUST</bcp14> be equal to the pnum field
	<t>salt (12 octets) - secret salt</t>	in the IV</dd>
	</list>	<dt>salt (12 octets):</dt><dd>secret salt. The salt is a string of b
	</t>	its that are formed when the SA is created (see <xref target="keymat"/> for deta
	</section>	ils). 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>
	<section title="MGM Nonce Format for "Magma" based Tra	</dl>
	nsforms" anchor="nonce_magma">	</section>
	<t> For transforms based on "Magma" cipher (ENCR_M	<section anchor="nonce_magma" numbered="true" toc="default">
	AGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE)	<name>MGM Nonce Format for Transforms Based on the "Magma" Cipher</nam
	the ICN consists of a zero octet, a 24-bit message counter a	e>
	nd a 32-bit secret salt, that is fixed for SA and is not transmitted.	<t> For transforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE a
		nd 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.


	<figure title="Nonce format for "Magma" based tran	</t>
	sforms" anchor="nonce_magma_format">	<figure anchor="nonce_magma_format">
	<preamble></preamble>	<name>Nonce Format for Transforms Based on the "Magma" Cipher</name>
	<artwork align="center"><![CDATA[	<artwork align="center" name="" type="" alt=""><![CDATA[
	1 2 3	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	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 \|	\| zero \| pnum \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| salt \|	\| salt \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<t>

	where:	where:

	<list style="symbols">	</t>
	<t>zero (1 octet) - set to 0</t>	<dl spacing="normal">
	<t>pnum (3 octets) - the counter for the messages protec	<dt>zero (1 octet):</dt><dd>set to 0</dd>
	ted by the given leaf key; this field MUST be equal to the pnum field in the IV<	<dt>pnum (3 octets):</dt><dd>the counter for the messages protected
	/t>	by the given leaf key; this field <bcp14>MUST</bcp14> be equal to the pnum field
	<t>salt (4 octets) - secret salt</t>	in the IV</dd>
	</list>	<dt>salt (4 octets):</dt><dd>secret salt. The salt is a string of bi
	</t>	ts that are formed when the SA is created (see <xref target="keymat"/> for detai
	</section>	ls). The salt does not change during the SA's lifetime and is not transmitted o
	</section>	n the wire. Every SA will have its own salt.</dd>
		</dl>
	<section title="Keying Material" anchor="keymat">	</section>
	<t>We'll refer as "transform key" to a string of bits that are u	</section>
	sed to initialize the transforms defined	<section anchor="keymat" numbered="true" toc="default">
	in this specification. The transform key is a composite entity c	<name>Keying Material</name>
	onsisting of the root key for the tree and the secret salt.	<t>We'll call a string of bits that is used to initialize the transforms
	</t>	defined in this specification a "transform key". The transform key is a compo
		site entity consisting of the root key for the tree and the secret salt.
	<t>The transform key for ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZN	</t>
	YECHIK_MGM_MAC_KTREE transforms consists of 352 bits (44 octets), of which	<t>The transform key for the ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECH
	the first 256 bits is a root key for the tree (denoted as K in <	IK_MGM_MAC_KTREE transforms consists of 352 bits (44 octets), of which
	xref target="key" />) and the remaining	the first 256 bits is a root key for the tree (denoted as K in <
	96 bits is a secret salt (see <xref target="nonce_kuznyechik" />	xref target="key" format="default"/>) and the remaining
	).	96 bits is a secret salt (see <xref target="nonce_kuznyechik" fo
	</t>	rmat="default"/>).
		</t>
	<t>The transform key for ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM	<t>The transform key for the ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC
	_MAC_KTREE transforms consists of 288 bits (36 octets), of which	_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 <	the first 256 bits is a root key for the tree (denoted as K in <
	xref target="key" />) and the remaining	xref target="key" format="default"/>) and the remaining
	32 bits is a secret salt (see <xref target="nonce_magma" />).	32 bits is a secret salt (see <xref target="nonce_magma" format=
	</t>	"default"/>).
		</t>
	<t>In case of ESP the transform keys are extracted from the KEYM	<t>In the case of ESP, the transform keys are extracted from the KEYMAT
	AT as defined in Section 2.17 of <xref target="RFC7296" />.	as defined in <xref target="RFC7296" sectionFormat="of" section="2.17"/>.
	In case of IKEv2 the transform keys are either SK_ei or SK_er, w	In the case of IKEv2, the transform keys are either SK_ei or SK_
	hich are generated as defined in Section 2.14 of <xref target="RFC7296" />.	er, which are generated as defined in <xref target="RFC7296" sectionFormat="of"
		section="2.14"/>.
	Note that since these transforms provide authenticated encryptio n, no additional keys are needed	Note that since these transforms provide authenticated encryptio n, no additional keys are needed

	for authentication. It means that in case of IKEv2 the keys SK_a i/SK_ar are not used and MUST be treated as	for authentication. This means that, in the case of IKEv2, the k eys SK_ai/SK_ar are not used and <bcp14>MUST</bcp14> be treated as
	having zero length.</t>	having zero length.</t>

	</section>	</section>
		<section anchor="icv" numbered="true" toc="default">
	<section title="Integrity Check Value" anchor="icv">	<name>Integrity Check Value</name>
	<t> The length of the authentication tag that MGM can compute i	<t> The length of the authentication tag that MGM can compute is in the
	s in the range from 32 bits to the block size of the underlying cipher.	range from 32 bits to the block size of the underlying cipher.
	Section 4 of the <xref target="RFC9058" /> states that the authe	<xref target="RFC9058" sectionFormat="of" section="4"/> states t
	ntication tag length must be fixed for a particular protocol.	hat the authentication tag length <bcp14>MUST</bcp14> be fixed for a particular
	For "Kuznyechik" based transforms (ENCR_KUZNYECHIK_MGM	protocol.
	_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the resulting	For transforms based on the "Kuznyechik" cipher (ENCR_KUZNYECHIK
	Integrity Check Value (ICV) length is set to 96 bits. For "	_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE), the resulting
	Magma" based transforms (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE)	Integrity Check Value (ICV) length is set to 96 bits. For transf
		orms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KT
		REE),
	the full ICV length is set to the block size (64 bits).	the full ICV length is set to the block size (64 bits).

	</t>	</t>
	</section>	</section>
		<section anchor="padding" numbered="true" toc="default">
	<section title="Plaintext Padding" anchor="padding">	<name>Plaintext Padding</name>
	<t>Transforms defined in this document don't require any plainte	<t>The transforms defined in this document don't require any plaintext p
	xt padding,	adding,
	as specified in <xref target="RFC9058" />. It means, that only t	as specified in <xref target="RFC9058" format="default"/>. This
	hose	means that only those
	padding requirements that are imposed by the protocol are applie d (4 bytes for ESP,	padding requirements that are imposed by the protocol are applie d (4 bytes for ESP,
	no padding for IKEv2).	no padding for IKEv2).

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="AAD Construction">	<name>AAD Construction</name>
	<section title="ESP AAD" anchor="esp_aad">	<section anchor="esp_aad" numbered="true" toc="default">
	<t> Additional Authenticated Data (AAD) in ESP is constructe	<name>ESP AAD</name>
	d differently depending on the	<t> Additional Authenticated Data (AAD) in ESP is constructed differen
	transform being used and whether Extended Sequence Number (E	tly, depending on the
	SN) is in use or not.	transform being used and whether the Extended Sequence Numbe
	The ENCR_KUZNYECHIK_MGM_KTREE and ENCR_MAGMA_MGM_KTREE	r (ESN) is in use or not.
	provide confidentiality, so the content of the ESP body is e	The ENCR_KUZNYECHIK_MGM_KTREE and ENCR_MAGMA_MGM_KTREE trans
	ncrypted and AAD	forms
	consists of the ESP SPI and (E)SN. The AAD is constructed si	provide confidentiality, so the content of the ESP body is e
	milarly to the one in <xref target="RFC4106" />.	ncrypted and the AAD
	</t>	consists of the ESP Security Parameter Index (SPI) and (E)SN
		.
	<t> On the other hand the ENCR_KUZNYECHIK_MGM_MAC_KTREE and	The AAD is constructed similarly to the AAD in <xref target="RFC4106" format="d
	ENCR_MAGMA_MGM_MAC_KTREE	efault"/>.
	don't provide confidentiality, they provide only message aut	</t>
	hentication.	<t> On the other hand, the ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGM
	For this purpose the IV and the part of ESP packet that is n	A_MGM_MAC_KTREE transforms
	ormally encrypted are included	don't provide confidentiality; they provide only message aut
	in the AAD. For these transforms encryption capability provi	hentication.
	ded by MGM	For this purpose, the IV and the part of the ESP packet that
	is not used. The AAD is constructed similarly to the one in	is normally encrypted are included
	<xref target="RFC4543" />.	in the AAD. For these transforms, the encryption capability
		provided by MGM
		is not used. The AAD is constructed similarly to the AAD in
		<xref target="RFC4543" format="default"/>.


	<figure title="AAD for AEAD transforms with 32-bit SN" ancho	</t>
	r="aad_aead_32">	<figure anchor="aad_aead_32">
	<preamble></preamble>	<name>AAD for AEAD Transforms with 32-Bit SN</name>
	<artwork align="center"><![CDATA[	<artwork align="center" name="" type="" alt=""><![CDATA[
	1 2 3	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	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 \|	\| SPI \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 32-bit Sequence Number \|	\| 32-bit Sequence Number \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<figure anchor="aad_aead_64">
	<figure title="AAD for AEAD transforms with 64-bit ESN" anch	<name>AAD for AEAD Transforms with 64-Bit ESN</name>
	or="aad_aead_64">	<artwork align="center" name="" type="" alt=""><![CDATA[
	<preamble></preamble>
	<artwork align="center"><![CDATA[
	1 2 3	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	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 \|	\| SPI \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 64-bit Extended Sequence Number \|	\| 64-bit Extended Sequence Number \|
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<figure anchor="aad_mac_32">
	<figure title="AAD for authentication only transforms with 3	<name>AAD for Authentication-Only Transforms with 32-Bit SN</name>
	2-bit SN" anchor="aad_mac_32">	<artwork align="center" name="" type="" alt=""><![CDATA[
	<preamble></preamble>
	<artwork align="center"><![CDATA[
	1 2 3	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	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 \|	\| SPI \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 32-bit Sequence Number \|	\| 32-bit Sequence Number \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| IV \|	\| IV \|
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|	\| \|
	~ Payload Data (variable) ~	~ Payload Data (variable) ~
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Padding (0-255 bytes) \|	\| Padding (0-255 bytes) \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \| Pad Length \| Next Header \|	\| \| Pad Length \| Next Header \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		<figure anchor="aad_mac_64">
	<figure title="AAD for authentication only transforms with 6	<name>AAD for Authentication-Only Transforms with 64-Bit ESN</name>
	4-bit ESN" anchor="aad_mac_64">	<artwork align="center" name="" type="" alt=""><![CDATA[
	<preamble></preamble>
	<artwork align="center"><![CDATA[
	1 2 3	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	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 \|	\| SPI \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| 64-bit Extended Sequence Number \|	\| 64-bit Extended Sequence Number \|
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| IV \|	\| IV \|
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \|	\| \|
	~ Payload Data (variable) ~	~ Payload Data (variable) ~
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Padding (0-255 bytes) \|	\| Padding (0-255 bytes) \|
	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| \| Pad Length \| Next Header \|	\| \| Pad Length \| Next Header \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>
		</section>
	</t>	<section anchor="ikev2_aad" numbered="true" toc="default">
	</section>	<name>IKEv2 AAD</name>
		<t> For IKEv2, the AAD consists of the IKEv2 Header,
	<section title="IKEv2 AAD" anchor="ikev2_aad">	any unencrypted payloads following it (if present), and eith
	<t> For IKEv2 the AAD consists of the IKEv2 Header,	er the Encrypted payload header (<xref target="RFC7296" sectionFormat="of" secti
	any unencrypted payloads following it (if present) and the E	on="3.14"/>)
	ncrypted	or the Encrypted Fragment payload (<xref target="RFC7383" se
	(or the Encrypted Fragment) payload header. The AAD is const	ctionFormat="of" section="2.5"/>), depending on whether IKE fragmentation is use
	ructed	d.
	similar to the one in <xref target="RFC5282" />.	The AAD is constructed
		similarly to the AAD in <xref target="RFC5282" format="defau
		lt"/>.


	<figure title="AAD for IKEv2" anchor="aad_ikev2_format">	</t>
	<preamble></preamble>	<figure anchor="aad_ikev2_encr_payload_format">
	<artwork align="center"><![CDATA[	<name>AAD for IKEv2 in the Case of the Encrypted Payload</name>
		<artwork align="center" name="" type="" alt=""><![CDATA[
	1 2 3	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	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 ~	~ IKEv2 Header ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Unencrypted IKE Payloads ~	~ Unencrypted IKE Payloads ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Next Payload \|C\| RESERVED \| Payload Length \|	\| Next Payload \|C\| RESERVED \| Payload Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	]]></artwork>	]]></artwork>

	</figure>	</figure>

	</t>
	</section>
	</section>


	<section title="Using Transforms" anchor="use">	<figure anchor="aad_ikev2_encr_frag_payload_format">
	<t>When SA is established the i1, i2 and i3 parameters are set t	<name>AAD for IKEv2 in the Case of the Encrypted Fragment Payload</n
	o 0 by the sender and a leaf key is calculated.	ame>
		<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>
		<section anchor="use" numbered="true" toc="default">
		<name>Using Transforms</name>
		<t>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 me ssage protected by the same leaf key.	The pnum parameter starts from 0 and is incremented with each me ssage protected by the same leaf key.

	When sender decides that the leaf should be changed, it incremen	When the sender decides that the leaf should be changed, it incr
	ts i3 parameter and generates a new leaf key.	ements the i3 parameter and generates a new leaf key.
	The pnum parameter for the new leaf key is reset to 0 and the pr	The pnum parameter for the new leaf key is reset to 0, and the p
	ocess continues. If the sender decides,	rocess continues. If the sender decides
	that third-level key corresponding to i3 is used enough times, i	that a third-level key corresponding to i3 is used enough times,
	t increments i2, resets i3 to 0	it increments i2, resets i3 to 0,
	and calculates a new leaf key. The pnum is reset to 0 (as with e	and calculates a new leaf key. The pnum is reset to 0 (as with e
	very new leaf key) and the process continues.	very new leaf key), and the process continues.
	Similar procedure is used when second-level key needs to be chan	A similar procedure is used when a second-level key needs to be
	ged.	changed.
	</t>	</t>
		<t>A combination of i1, i2, i3, and pnum <bcp14>MUST NOT</bcp14> repeat
	<t>A combination of i1, i2, i3 and pnum MUST NOT repeat for any	for any particular SA.
	particular SA.	This means that the wrapping of these counters is not allowed: w
	This means that wrapping around of these counters is not allowed	hen i2, i3, or pnum reaches its respective maximum value,
	: when i2, i3 or pnum reach their maximum values,	a procedure for changing a leaf key, described above, is execute
	a procedure of changing a leaf key described above is executed,	d, and if all four parameters reach their maximum values,
	and if all four parameters reach their maximum values,
	the IPsec SA becomes unusable.	the IPsec SA becomes unusable.

	</t>	</t>
		<t>There may be other reasons to recalculate leaf keys besides reaching
	<t>There may be other reasons to recalculate leaf keys beside re	maximum values for the counters.
	aching maximum values for the counters.	For example, as described in <xref target="security" format="def
	For example, as described in <xref target="security" />, it is R	ault"/>, it is <bcp14>RECOMMENDED</bcp14> that the sender count the number of
	ECOMMENDED 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	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" /> f	reaching the octet limits stated in <xref target="security" form
	or each of the ciphers.	at="default"/> for each of the ciphers.
	</t>	</t>
		<t>The receiver always uses i1, i2, and i3 from the received message. If
	<t>The receiver always uses i1, i2 and i3 from the received mess	they differ from the values in previously received packets,
	age. If they differ from the values in previously received packets,
	a new leaf key is calculated. The pnum parameter is always used from the	a new leaf key is calculated. The pnum parameter is always used from the

	received packet. To improve performance implementations may cach	received packet. To improve performance, implementations may cac
	e recently used leaf key.	he recently used leaf keys.
	When a new leaf key is calculated (based on the values from rece	When a new leaf key is calculated (based on the values from the
	ived message)	received message),
	the old key may be kept for some time to improve performance in	the old key may be kept for some time to improve performance in
	case of possible packet reordering	the case of possible packet reordering
	(when packets protected by the old leaf key are delayed and arri ve later).	(when packets protected by the old leaf key are delayed and arri ve later).

	</t>	</t>
	</section>	</section>
		</section>
	</section>	<section anchor="security" numbered="true" toc="default">
		<name>Security Considerations</name>
	<section anchor="security" title="Security Considerations">	<t> The most important security consideration for MGM is that the nonce <b
	<t> The most important security consideration for MGM is that the no	cp14>MUST NOT</bcp14> repeat
	nce MUST NOT repeat	for a given key. For this reason, the transforms defined in this doc
	for a given key. For this reason the transforms defined in this docu	ument <bcp14>MUST NOT</bcp14> be used with manual keying.
	ment MUST NOT be used with manual keying.	</t>
	</t>	<t> Excessive use of the same key can give an attacker advantages in break
		ing security properties of the
	<t> Excessive use of the same key can give an attacker advantages in	transforms defined in this document. For this reason, the amount of
	breaking security properties of the	data that any particular key is used to protect
	transforms defined in this document. For this reason the amount of d	should be limited. This is especially important for algorithms with
	ata any particular key is used to protect	a 64-bit block size (like "Magma"),
	should be limited. This is especially important for algorithms with	which currently are generally considered insecure after protecting a
	64-bit block size (like "Magma"),	relatively
	which currently are generally considered insecure after protecting r	small amount of data. For example, Section 3.4 of <xref target="SP80
	elatively	0-67" format="default"/> limits the number of blocks
	small amount of data. For example, Section 3.4 of <xref target="SP80	that are allowed to be encrypted with the Triple DES cipher to 2<sup
	0-67" /> limits the number of blocks	>20</sup> (8 MB of data).
	that are allowed to be encrypted with Triple DES cipher by 2^20 (8 M	This document defines a rekeying mechanism that allows the mitigatio
	bytes of data).	n of weak security of a 64-bit block cipher
	This document defines a rekeying mechanism that allows to mitigate a	by frequently changing the encryption key.
	weak security of a 64-bit block cipher	</t>
	by frequent changing of encryption key.	<t> For transforms defined in this document, <xref target="GOST-ESP" forma
	</t>	t="default"/> recommends
		limiting the number of octets protected with a single K_msg key by t
		he following values:
		</t>
		<ul>
		<li>2<sup>41</sup> octets for transforms based on the "Kuznyechik" ciphe
		r (ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE)</li>
		<li>2<sup>28</sup> octets for transforms based on the "Magma" cipher (EN
		CR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE)</li>
		</ul>
		<t>
		These values are based on combinatorial properties and may be furthe
		r 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<sup>24</sup> and ea
		ch message (either IKEv2 messages or ESP datagrams) is limited to 2<sup>16</sup>
		octets in size,
		giving 2<sup>40</sup> octets as the maximum amount of data that can
		be protected with a single K_msg.
		</t>
		<t><xref target="RFC9058" sectionFormat="of" section="4"/> discusses the p
		ossibility of truncating authentication tags in MGM
		as a trade-off between message expansion and the probability of forg
		ery. This specification truncates an authentication
		tag length for transforms based on the "Kuznyechik" cipher to 96 bit
		s. This decreases message expansion while still providing a very low probability
		of forgery: 2<sup>-96</sup>.
		</t>
		<t>An attacker can send a lot of packets with arbitrarily chosen i1, i2, a
		nd 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 verifi
		cation attempts (that would fail) on a large amount of data,
		thus allowing the attacker a deeper analysis of the underlying crypt
		ographic primitive (see <xref target="AEAD-USAGE-LIMITS" format="default"/>).
		Implementations <bcp14>MAY</bcp14> initiate rekeying if they deem th
		at 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" numbered="true" toc="default">
		<name>IANA Considerations</name>
		<t> IANA maintains a registry called "Internet Key Exchange Version 2 (IKE
		v2) Parameters" with a subregistry called "Transform Type Values".
		IANA has added the following four Transform IDs to the "Transform Ty
		pe 1 - Encryption Algorithm Transform IDs" subregistry.
		</t>


	<t> For transforms defined in this document, <xref target="GOST-ESP"	<table anchor="iana-table">
	/> recommends	<name>Transform IDs</name>
	limiting the number of octets protected with a single Kmsg key by th	<thead>
	e following values:	<tr>
	<list style="symbols">	<th>Number</th>
	<t>for transforms based on "Kuznyechik" cipher (ENCR_KUZ	<th>Name</th>
	NYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) - 2^41 octets;</t>	<th>ESP Reference</th>
	<t>for transforms based on "Magma" cipher (ENCR_MAGMA_MG	<th>IKEv2 Reference</th>
	M_KTREE and ENCR_MAGMA_MGM_MAC_KTREE) - 2^28 octets;</t>	</tr>
	</list>	</thead>
	These values are based on combinatorial properties and may be furthe	<tbody>
	r restricted if side channels attacks are taken into considerations.	<tr>
	Note that the limit for "Kuznyechik" based transforms is u	<td>32</td>
	nreachable because due to transforms construction	<td>ENCR_KUZNYECHIK_MGM_KTREE</td>
	the number of protected messages is limited to 2^24 and each message	<td>RFC 9227</td>
	(either IKEv2 message or ESP datagram) is limited to 2^16 octets in size,	<td>RFC 9227</td>
	giving 2^40 octets as the maximum amount of data that can be protect	</tr>
	ed with a single Kmsg.	<tr>
	</t>	<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>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2119.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8174.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4303.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7296.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7383.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.6986.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7801.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8891.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.9058.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.7836.xml"/>
		</references>
		<references>
		<name>Informative References</name>


	<t>Section 4 of <xref target="RFC9058" /> discusses the possibility	<reference anchor="GOST3411-2012">
	of truncating authentication tags in MGM	<front>
	as a trade-off between message expansion and the forgery probability	<title>Information technology. Cryptographic data security. Hash fun
	. This specification truncates an authentication	ction</title>
	tag length for "Kuznyechik" based transforms to 96 bits. T	<author>
	his decreases message expansion still providing	<organization>Federal Agency on Technical Regulating and Metrology
	very low forgery probability of 2^-96.	</organization>
	</t>	</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 ci
		phers</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>


	<t>An attacker can send a lot of packets with arbitrary chosen i1, i	<reference anchor="GOST-MGM">
	2, and i3 parameters. This will	<front>
	1) force a recepient to recalculate the leaf key for every received	<title>Information technology. Cryptographic information security. B
	packet if i1, i2, and i3 are different from the previous one,	lock Cipher Modes Implementing Authenticated Encryption</title>
	thus consuming CPU resources and 2) force a recepient to make verifi	<author>
	cation attempts (that would fail) on a large amount of data,	<organization>Federal Agency on Technical Regulating and Metrology
	thus allowing the attacker for deeper analyzing of the underlying cr	</organization>
	yptographic primitive (see <xref target="I-D.irtf-cfrg-aead-limits" />).	</author>
	Implementations MAY initiate re-keying if they deem they receive too	<date month="September" year="2019"/>
	many packets with invalid ICV.	</front>
	</t>	<seriesInfo name="R" value="1323565.1.026-2019"/>
		<annotation>(In Russian)</annotation>
		</reference>


	<t> Security properties of MGM are discussed in <xref target="MGM-SE	<reference anchor="GOST-ESP">
	CURITY" />.	<front>
	</t>	<title>Information technology. Cryptographic information protection.
	</section>	The use of Russian cryptographic algorithms in the ESP information protection p
		rotocol</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>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.2104.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4106.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.4543.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.5282.xml"/>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
		FC.8645.xml"/>


	<section anchor="iana" title="IANA Considerations">	<reference anchor="MGM-SECURITY" target="https://eprint.iacr.org/2019/12
	<t> IANA maintains a registry of "Internet Key Exchange Version 2 (I	3.pdf">
	KEv2) Parameters" with a sub-registry of "Transform Type Values".	<front>
	IANA has assigned four Transform IDs in the "Transform Type 1 - Encr	<title>Security of Multilinear Galois Mode (MGM)</title>
	yption Algorithm Transform IDs" registry and is requested	<author fullname="Liliya Akhmetzyanova"/>
	to update their references to this document (where RFCXXXX is this d	<author fullname="Evgeny Alekseev"/>
	ocument):	<author fullname="Grigory Karpunin"/>
	</t>	<author fullname="Vladislav Nozdrunov"/>
		<date year="2019"/>
		</front>
		</reference>


	<figure>	<reference anchor="SP800-67" target="https://nvlpubs.nist.gov/nistpubs/S
	<preamble></preamble>	pecialPublications/NIST.SP.800-67r2.pdf">
	<artwork align="center"><![CDATA[	<front>
	Number Name ESP Reference IKEv2 Reference	<title>Recommendation for the Triple Data Encryption Algorithm (TDEA
	32 ENCR_KUZNYECHIK_MGM_KTREE [RFCXXXX] [RFCXXXX]	) Block Cipher</title>
	33 ENCR_MAGMA_MGM_KTREE [RFCXXXX] [RFCXXXX]	<author>
	34 ENCR_KUZNYECHIK_MGM_MAC_KTREE [RFCXXXX] Not allowed	<organization>National Institute of Standards and Technology</orga
	35 ENCR_MAGMA_MGM_MAC_KTREE [RFCXXXX] Not allowed	nization>
	]]></artwork>	</author>
	</figure>	<date month="November" year="2017"/>
		</front>
		<seriesInfo name="DOI" value="10.6028/NIST.SP.800-67r2"/>
		</reference>


	</section>	<!-- 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>


	<section title="Acknowledgments" anchor="acknowledgments">	</references>
	<t>Author wants to thank Adrian Farrel, Russ Housley, Yaron Sheffer an	</references>
	d Stanislav Smyshlyaev for valuable input	<section anchor="testvec" numbered="true" toc="default">
	in the process of publication this document.	<name>Test Vectors</name>
		<t> In the following test vectors, binary data is represented in hexadecim
		al format.
		The numbers in square brackets indicate the size of the correspondin
		g data in decimal format.
		</t>
		<ol spacing="normal" type="1"><li>
		<t>ENCR_KUZNYECHIK_MGM_KTREE (Example 1):
	</t>	</t>

	</section>	<sourcecode name="" type="test-vectors"><![CDATA[
	</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>

	<references title='Informative References'>
	<reference anchor="GOST3411-2012">
	<front>
	<title>Information technology. Cryptographic Data Security.
	Hashing function</title>
	<author>
	<organization>Federal Agency on Technical Regulating and
	Metrology</organization>
	</author>
	<date 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 year="2015"/>
	</front>
	<seriesInfo name="GOST R" value="34.12-2015"/>
	<annotation>(In Russian)</annotation>
	</reference>
	<reference anchor="GOST-MGM">
	<front>
	<title>Information technology. Cryptographic data security.
	Authenticated encryption block cipher operation modes</title>
	<author>
	<organization>Federal Agency on Technical Regulating and
	Metrology</organization>
	</author>
	<date year="2019"/>
	</front>
	<seriesInfo name="R" value="1323565.1.026-2019"/>
	<annotation>(In Russian)</annotation>
	</reference>
	<reference anchor="GOST-ESP">
	<front>
	<title>Information technology. Cryptographic data security.
	Using Russian cryptographic algorithms in data security protocol ESP</title>
	<author>
	<organization>Federal Agency on Technical Regulating and
	Metrology</organization>
	</author>
	<date 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" ?>
	<reference anchor="MGM-SECURITY" target="https://eprint.iacr.org/201
	9/123.pdf">
	<front>
	<title>Security of Multilinear Galois Mode (MGM)</title>
	<author fullname="Liliya Akhmetzyanova" />
	<author fullname="Evgeny Alekseev" />
	<author fullname="Grigory Karpunin" />
	<author fullname="Vladislav Nozdrunov" />
	<date year="2019"/>
	</front>
	</reference>
	<reference anchor="SP800-67" target="https://nvlpubs.nist.gov/nistpu
	bs/SpecialPublications/NIST.SP.800-67r2.pdf">
	<front>
	<title>Recommendation for the Triple Data Encryption Algorit
	hm (TDEA) Block Cipher</title>
	<author >
	<organization>National Institute of Standards and Technolo
	gy</organization>
	</author>
	<date month="November" year="2017"/>
	</front>
	</reference>
	<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference
	.I-D.irtf-cfrg-aead-limits.xml" ?>
	</references>

	<section title="Test Vectors" anchor="testvec">
	<t> In the following test vectors binary data is represented in hexa
	decimal format.
	The numbers in square bracket 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[
	transform key [44]:	transform key [44]:
	b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c	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	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	7b 67 e6 f2 44 f9 7f 06 78 95 2e 45
	K [32]:	K [32]:
	b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c	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	e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38
	salt [12]:	salt [12]:
	7b 67 e6 f2 44 f9 7f 06 78 95 2e 45	7b 67 e6 f2 44 f9 7f 06 78 95 2e 45
	i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000	i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000

	skipping to change at line 667 ¶	skipping to change at line 732 ¶
	ESP ICV [12]:	ESP ICV [12]:
	50 b0 70 a1 5a 2b d9 73 86 89 f8 ed	50 b0 70 a1 5a 2b d9 73 86 89 f8 ed
	ESP packet [112]:	ESP packet [112]:
	45 00 00 70 00 4d 00 00 ff 32 91 4f 0a 6f 0a c5	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	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	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	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	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	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	ae 4d a5 6f 50 b0 70 a1 5a 2b d9 73 86 89 f8 ed

	]]></artwork>	]]></sourcecode>
	</figure>	</li>
	</t>	<li>
	<t>ENCR_KUZNYECHIK_MGM_KTREE, example 2:	<t>ENCR_KUZNYECHIK_MGM_KTREE (Example 2):
	<figure>	</t>
	<preamble></preamble>	<sourcecode name="" type="test-vectors"><![CDATA[
	<artwork align="left"><![CDATA[
	transform key [44]:	transform key [44]:
	b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c	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	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	7b 67 e6 f2 44 f9 7f 06 78 95 2e 45
	K [32]:	K [32]:
	b6 18 0c 14 5c 51 2d bd 69 d9 ce a9 2c ac 1b 5c	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	e1 bc fa 73 79 2d 61 af 0b 44 0d 84 b5 22 cc 38
	salt [12]:	salt [12]:
	7b 67 e6 f2 44 f9 7f 06 78 95 2e 45	7b 67 e6 f2 44 f9 7f 06 78 95 2e 45
	i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000	i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000

	skipping to change at line 713 ¶	skipping to change at line 777 ¶
	ESP ICV [12]:	ESP ICV [12]:
	c2 2f 87 40 83 8e 3d fa ce 91 cc b8	c2 2f 87 40 83 8e 3d fa ce 91 cc b8
	ESP packet [112]:	ESP packet [112]:
	45 00 00 70 00 5c 00 00 ff 32 91 40 0a 6f 0a c5	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	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	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	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	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	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	a4 d4 9a 4d c2 2f 87 40 83 8e 3d fa ce 91 cc b8

	]]></artwork>	]]></sourcecode>
	</figure>	</li>
	</t>	<li>
	<t>ENCR_MAGMA_MGM_KTREE, example 1:	<t>ENCR_MAGMA_MGM_KTREE (Example 1):
	<figure>	</t>
	<preamble></preamble>	<sourcecode name="" type="test-vectors"><![CDATA[
	<artwork align="left"><![CDATA[
	transform key [36]:	transform key [36]:
	5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c	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	22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03
	cf 36 63 12	cf 36 63 12
	K [32]:	K [32]:
	5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c	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	22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03
	salt [4]:	salt [4]:
	cf 36 63 12	cf 36 63 12
	i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000	i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000

	skipping to change at line 759 ¶	skipping to change at line 822 ¶
	ESP ICV [8]:	ESP ICV [8]:
	5f 4a fa 8b 02 94 0f 5c	5f 4a fa 8b 02 94 0f 5c
	ESP packet [108]:	ESP packet [108]:
	45 00 00 6c 00 62 00 00 ff 32 91 3e 0a 6f 0a c5	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	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	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	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	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	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	15 52 cc e8 5f 4a fa 8b 02 94 0f 5c

	]]></artwork>	]]></sourcecode>
	</figure>	</li>
	</t>	<li>
	<t>ENCR_MAGMA_MGM_KTREE, example 2:	<t>ENCR_MAGMA_MGM_KTREE (Example 2):
	<figure>	</t>
	<preamble></preamble>	<sourcecode name="" type="test-vectors"><![CDATA[
	<artwork align="left"><![CDATA[
	transform key [36]:	transform key [36]:
	5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c	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	22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03
	cf 36 63 12	cf 36 63 12
	K [32]:	K [32]:
	5b 50 bf 33 78 87 02 38 f3 ca 74 0f d1 24 ba 6c	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	22 83 ef 58 9b e6 f4 6a 89 4a a3 5d 5f 06 b2 03
	salt [4]:	salt [4]:
	cf 36 63 12	cf 36 63 12
	i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000	i1 = 00, i2 = 0001, i3 = 0001, pnum = 000000

	skipping to change at line 805 ¶	skipping to change at line 867 ¶
	ESP ICV [8]:	ESP ICV [8]:
	dd 5d 50 9a fd b8 09 98	dd 5d 50 9a fd b8 09 98
	ESP packet [108]:	ESP packet [108]:
	45 00 00 6c 00 71 00 00 ff 32 91 2f 0a 6f 0a c5	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	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	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	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	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	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	bf fe a1 dd dd 5d 50 9a fd b8 09 98

	]]></artwork>	]]></sourcecode>
	</figure>	</li>
	</t>	<li>
	<t>ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 1:	<t>ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 1):
	<figure>	</t>
	<preamble></preamble>	<sourcecode name="" type="test-vectors"><![CDATA[
	<artwork align="left"><![CDATA[
	transform key [44]:	transform key [44]:
	98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4	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	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	6c 51 cb ac 93 c4 5b ea 99 62 79 1d
	K [32]:	K [32]:
	98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4	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	88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be
	salt [12]:	salt [12]:
	6c 51 cb ac 93 c4 5b ea 99 62 79 1d	6c 51 cb ac 93 c4 5b ea 99 62 79 1d
	i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000	i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000

	skipping to change at line 847 ¶	skipping to change at line 908 ¶
	ESP ICV [12]:	ESP ICV [12]:
	ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d	ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d
	ESP packet [112]:	ESP packet [112]:
	45 00 00 70 00 01 00 00 ff 32 91 9b 0a 6f 0a c5	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	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	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	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	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	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	01 02 02 04 ca c5 8c e5 e8 8b 4b f3 2d 6c f0 4d

	]]></artwork>	]]></sourcecode>
	</figure>	</li>
	</t>	<li>
	<t>ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 2:	<t>ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 2):
	<figure>	</t>
	<preamble></preamble>	<sourcecode name="" type="test-vectors"><![CDATA[
	<artwork align="left"><![CDATA[
	transform key [44]:	transform key [44]:
	98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4	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	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	6c 51 cb ac 93 c4 5b ea 99 62 79 1d
	K [32]:	K [32]:
	98 bd 34 ce 3b e1 9a 34 65 e4 87 c0 06 48 83 f4	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	88 cc 23 92 63 dc 32 04 91 9b 64 3f e7 57 b2 be
	salt [12]:	salt [12]:
	6c 51 cb ac 93 c4 5b ea 99 62 79 1d	6c 51 cb ac 93 c4 5b ea 99 62 79 1d
	i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000	i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000

	skipping to change at line 889 ¶	skipping to change at line 949 ¶
	ESP ICV [12]:	ESP ICV [12]:
	ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91	ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91
	ESP packet [112]:	ESP packet [112]:
	45 00 00 70 00 06 00 00 ff 32 91 96 0a 6f 0a c5	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	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	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	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	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	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	01 02 02 04 ba bc 67 ec 72 a8 c3 1a 89 b4 0e 91

	]]></artwork>	]]></sourcecode>
	</figure>	</li>
	</t>	<li>
	<t>ENCR_MAGMA_MGM_MAC_KTREE, example 1:	<t>ENCR_MAGMA_MGM_MAC_KTREE (Example 1):
	<figure>	</t>
	<preamble></preamble>	<sourcecode name="" type="test-vectors"><![CDATA[
	<artwork align="left"><![CDATA[
	transform key [36]:	transform key [36]:
	d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39	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	2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30
	88 79 8f 29	88 79 8f 29
	K [32]:	K [32]:
	d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39	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	2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30
	salt [4]:	salt [4]:
	88 79 8f 29	88 79 8f 29
	i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000	i1 = 00, i2 = 0000, i3 = 0000, pnum = 000000

	skipping to change at line 931 ¶	skipping to change at line 990 ¶
	ESP ICV [8]:	ESP ICV [8]:
	4d d4 25 8a 25 35 95 df	4d d4 25 8a 25 35 95 df
	ESP packet [108]:	ESP packet [108]:
	45 00 00 6c 00 13 00 00 ff 32 91 8d 0a 6f 0a c5	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	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	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	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	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	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	01 02 02 04 4d d4 25 8a 25 35 95 df

	]]></artwork>	]]></sourcecode>
	</figure>	</li>
	</t>	<li>
	<t>ENCR_MAGMA_MGM_MAC_KTREE, example 2:	<t>ENCR_MAGMA_MGM_MAC_KTREE (Example 2):
	<figure>	</t>
	<preamble></preamble>	<sourcecode name="" type="test-vectors"><![CDATA[
	<artwork align="left"><![CDATA[
	transform key [36]:	transform key [36]:
	d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39	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	2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30
	88 79 8f 29	88 79 8f 29
	K [32]:	K [32]:
	d0 65 b5 30 fa 20 b8 24 c7 57 0c 1d 86 2a e3 39	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	2c 1c 07 6d fa da 69 75 74 4a 07 a8 85 7d bd 30
	salt [4]:	salt [4]:
	88 79 8f 29	88 79 8f 29
	i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000	i1 = 00, i2 = 0000, i3 = 0001, pnum = 000000

	skipping to change at line 973 ¶	skipping to change at line 1031 ¶
	ESP ICV [8]:	ESP ICV [8]:
	84 84 a9 23 30 a0 b1 96	84 84 a9 23 30 a0 b1 96
	ESP packet [108]:	ESP packet [108]:
	45 00 00 6c 00 18 00 00 ff 32 91 88 0a 6f 0a c5	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	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	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	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	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	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	01 02 02 04 84 84 a9 23 30 a0 b1 96

	]]></artwork>	]]></sourcecode>
	</figure>	</li>
	</t>	</ol>
	</list>	</section>
	</t>	<section anchor="acknowledgments" numbered="false" toc="default">
	</section>	<name>Acknowledgments</name>
	</back>	<t>The author wants to thank <contact fullname="Adrian Farrel"/>, <contact
		fullname="Russ Housley"/>, <contact fullname="Yaron Sheffer"/>, and <contact fu
		llname="Stanislav Smyshlyaev"/> for valuable input during the
		publication process for this document.
		</t>
		</section>
		</back>
	</rfc>	</rfc>

End of changes. 61 change blocks.
	736 lines changed or deleted	815 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/