rfc9227.original		rfc9227.txt
	Network Working Group V. Smyslov		Independent Submission V. Smyslov
	Internet-Draft ELVIS-PLUS		Request for Comments: 9227 ELVIS-PLUS
	Intended status: Informational 7 February 2022		Category: Informational March 2022
	Expires: 11 August 2022		ISSN: 2070-1721
	Using GOST ciphers in ESP and IKEv2		Using GOST Ciphers in the Encapsulating Security Payload (ESP) and
	draft-smyslov-esp-gost-14		Internet Key Exchange Version 2 (IKEv2) Protocols
	Abstract		Abstract
	This document defines a set of encryption transforms for use in the		This document defines a set of encryption transforms for use in the
	Encapsulating Security Payload (ESP) and in the Internet Key Exchange		Encapsulating Security Payload (ESP) and in the Internet Key Exchange
	version 2 (IKEv2) protocols which are parts of the IP Security		version 2 (IKEv2) protocols, which are parts of the IP Security
	(IPsec) protocols suite. The transforms are based on the GOST R		(IPsec) protocol suite. The transforms are based on the GOST R
	34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik")		34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik")
	in a Multilinear Galois Mode (MGM) and the external re-keying		in Multilinear Galois Mode (MGM) and the external rekeying approach.
	approach.
	This specification is developed to facilitate implementations that		This specification was developed to facilitate implementations that
	wish to support the GOST algorithms. This document does not imply		wish to support the GOST algorithms. This document does not imply
	IETF endorsement of the cryptographic algorithms used in this		IETF endorsement of the cryptographic algorithms used in this
	document.		document.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This is a contribution to the RFC Series, independently of any other
	and may be updated, replaced, or obsoleted by other documents at any		RFC stream. The RFC Editor has chosen to publish this document at
	time. It is inappropriate to use Internet-Drafts as reference		its discretion and makes no statement about its value for
	material or to cite them other than as "work in progress."		implementation or deployment. Documents approved for publication by
			the RFC Editor are not candidates for any level of Internet Standard;
			see Section 2 of RFC 7841.
	This Internet-Draft will expire on 11 August 2022.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9227.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document.
	described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Overview
	4. Transforms Description . . . . . . . . . . . . . . . . . . . 4		4. Description of Transforms
	4.1. Tree-based External Re-Keying . . . . . . . . . . . . . . 4		4.1. Tree-Based External Rekeying
	4.2. Initialization Vector Format . . . . . . . . . . . . . . 6		4.2. Initialization Vector Format
	4.3. Nonce Format for MGM . . . . . . . . . . . . . . . . . . 6		4.3. Nonce Format for MGM
	4.3.1. MGM Nonce Format for "Kuznyechik" based Transforms . 7		4.3.1. MGM Nonce Format for Transforms Based on the
	4.3.2. MGM Nonce Format for "Magma" based Transforms . . . . 7		"Kuznyechik" Cipher
	4.4. Keying Material . . . . . . . . . . . . . . . . . . . . . 8		4.3.2. MGM Nonce Format for Transforms Based on the "Magma"
	4.5. Integrity Check Value . . . . . . . . . . . . . . . . . . 9		Cipher
	4.6. Plaintext Padding . . . . . . . . . . . . . . . . . . . . 9		4.4. Keying Material
	4.7. AAD Construction . . . . . . . . . . . . . . . . . . . . 9		4.5. Integrity Check Value
	4.7.1. ESP AAD . . . . . . . . . . . . . . . . . . . . . . . 9		4.6. Plaintext Padding
	4.7.2. IKEv2 AAD . . . . . . . . . . . . . . . . . . . . . . 11		4.7. AAD Construction
	4.8. Using Transforms . . . . . . . . . . . . . . . . . . . . 12		4.7.1. ESP AAD
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4.7.2. IKEv2 AAD
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		4.8. Using Transforms
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		7. References
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		7.1. Normative References
	Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 16		7.2. Informative References
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24		Appendix A. Test Vectors
			Acknowledgments
			Author's Address
	1. Introduction		1. Introduction
	The IP Security (IPsec) protocols suite consists of several		The IP Security (IPsec) protocol suite consists of several protocols,
	protocols, of which the Encapsulating Security Payload (ESP)		of which the Encapsulating Security Payload (ESP) [RFC4303] and the
	[RFC4303] and the Internet Key Exchange version 2 (IKEv2) [RFC7296]		Internet Key Exchange version 2 (IKEv2) [RFC7296] are most widely
	are most widely used. This document defines four transforms for ESP		used. This document defines four transforms for ESP and IKEv2 based
	and IKEv2 based on Russian cryptographic standard algorithms (often		on Russian cryptographic standard algorithms (often referred to as
	referred to as "GOST" algorithms). This definition is based on the		"GOST" algorithms). These definitions are based on the
	Recommendations [GOST-ESP] established by Federal Agency on Technical		recommendations [GOST-ESP] established by the Federal Agency on
	Regulating and Metrology (Rosstandart), which describe how Russian		Technical Regulating and Metrology (Rosstandart), which describe how
	cryptographic standard algorithms are used in ESP and IKEv2.		Russian cryptographic standard algorithms are used in ESP and IKEv2.
	Transforms defined in this document are based on two block ciphers		The transforms defined in this document are based on two block
	from Russian cryptographic standard algorithms - "Kuznyechik"		ciphers from Russian cryptographic standard algorithms --
	[GOST3412-2015][RFC7801] and "Magma" [GOST3412-2015][RFC8891] in		"Kuznyechik" [GOST3412-2015] [RFC7801] and "Magma" [GOST3412-2015]
	Multilinear Galois Mode (MGM) [GOST-MGM][RFC9058]. These transforms		[RFC8891] in Multilinear Galois Mode (MGM) [GOST-MGM] [RFC9058].
	provide Authenticated Encryption with Associated Data (AEAD). An		These transforms provide Authenticated Encryption with Associated
	external re-keying mechanism, described in [RFC8645] is also used in		Data (AEAD). An external rekeying mechanism, described in [RFC8645],
	these transforms to limit load on session keys.		is also used in these transforms to limit the load on session keys.
	Because the GOST specification includes the definition of both 128		Because the GOST specification includes the definition of both
	("Kuznyechik") and 64 ("Magma") bit block ciphers, both are included		128-bit ("Kuznyechik") and 64-bit ("Magma") block ciphers, both are
	in this document. Implementers should make themselves aware of the		included in this document. Implementers should make themselves aware
	relative security and other cost-benefit implications of the two		of the relative security and other cost-benefit implications of the
	ciphers. See Section 5 for more details.		two ciphers. See Section 5 for more details.
	This specification is developed to facilitate implementations that		This specification was developed to facilitate implementations that
	wish to support the GOST algorithms. This document does not imply		wish to support the GOST algorithms. This document does not imply
	IETF endorsement of the cryptographic algorithms used in this		IETF endorsement of the cryptographic algorithms used in this
	document.		document.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Overview		3. Overview
	Russian cryptographic standard algorithms, often referred as "GOST"		Russian cryptographic standard algorithms, often referred to as
	algorithms, constitute a set of cryptographic algorithms of different		"GOST" algorithms, constitute a set of cryptographic algorithms of
	types - ciphers, hash functions, digital signatures, etc. In		different types -- ciphers, hash functions, digital signatures, etc.
	particular, Russian cryptographic standard [GOST3412-2015] defines		In particular, Russian cryptographic standard [GOST3412-2015] defines
	two block ciphers - "Kuznyechik" (also defined in [RFC7801]) and		two block ciphers -- "Kuznyechik" (also defined in [RFC7801]) and
	"Magma" (also defined in [RFC8891]). Both ciphers use 256-bit key.		"Magma" (also defined in [RFC8891]). Both ciphers use a 256-bit key.
	"Kuznyechik" has a block size of 128 bits, while "Magma" has a 64-bit		"Kuznyechik" has a block size of 128 bits, while "Magma" has a 64-bit
	block.		block.
	Multilinear Galois Mode (MGM) is an AEAD mode defined in		Multilinear Galois Mode (MGM) is an AEAD mode defined in [GOST-MGM]
	[GOST-MGM][RFC9058]. It is claimed to provide defense against some		and [RFC9058]. It is claimed to provide defense against some attacks
	attacks on well-known AEAD modes, like Galois Counter Mode (GCM).		on well-known AEAD modes, like Galois/Counter Mode (GCM).
	[RFC8645] defines mechanisms that can be used to limit the number of		[RFC8645] defines mechanisms that can be used to limit the number of
	times any particular session key is used. One of these mechanisms,		times any particular session key is used. One of these mechanisms,
	called external re-keying with tree-based construction (defined in		called external rekeying with tree-based construction (defined in
	Section 5.2.3 of [RFC8645]), is used in the defined transforms. For		Section 5.2.3 of [RFC8645]), is used in the defined transforms. For
	the purpose of deriving subordinate keys a Key Derivation Function		the purpose of deriving subordinate keys, the Key Derivation Function
	(KDF) KDF_GOSTR3411_2012_256 defined in Section 4.5 of [RFC7836], is		(KDF) KDF_GOSTR3411_2012_256, defined in Section 4.5 of [RFC7836], is
	used. This KDF is based on an HMAC [RFC2104] construction with a		used. This KDF is based on a Hashed Message Authentication Code
	Russian GOST hash function defined in Russian cryptographic standard		(HMAC) construction [RFC2104] with a Russian GOST hash function
	[GOST3411-2012] (also defined in [RFC6986]).		defined in Russian cryptographic standard [GOST3411-2012] (also
			defined in [RFC6986]).
	4. Transforms Description		4. Description of Transforms
	This document defines four transforms of Type 1 (Encryption		This document defines four transforms of Type 1 (Encryption
	Algorithm) for use in ESP and IKEv2. All of them use MGM mode of		Algorithm) for use in ESP and IKEv2. All of them use MGM as the mode
	operation with tree-based external re-keying. The transforms differ		of operation with tree-based external rekeying. The transforms
	in underlying ciphers and in cryptographic services they provide.		differ in underlying ciphers and in cryptographic services they
			provide.
	* ENCR_KUZNYECHIK_MGM_KTREE (Transform ID 32) is an AEAD transform		* ENCR_KUZNYECHIK_MGM_KTREE (Transform ID 32) is an AEAD transform
	based on "Kuznyechik" algorithm; it provides confidentiality and		based on the "Kuznyechik" algorithm; it provides confidentiality
	message authentication and thus can be used in both ESP and IKEv2		and message authentication and thus can be used in both ESP and
			IKEv2.
	* ENCR_MAGMA_MGM_KTREE (Transform ID 33) is an AEAD transform based		* ENCR_MAGMA_MGM_KTREE (Transform ID 33) is an AEAD transform based
	on "Magma" algorithm; it provides confidentiality and message		on the "Magma" algorithm; it provides confidentiality and message
	authentication and thus can be used in both ESP and IKEv2		authentication and thus can be used in both ESP and IKEv2.
	* ENCR_KUZNYECHIK_MGM_MAC_KTREE (Transform ID 34) is a MAC-only		* ENCR_KUZNYECHIK_MGM_MAC_KTREE (Transform ID 34) is a MAC-only
	transform based on "Kuznyechik" algorithm; it provides no		transform based on the "Kuznyechik" algorithm; it provides no
	confidentiality and thus can only be used in ESP, but not in IKEv2		confidentiality and thus can only be used in ESP, but not in
			IKEv2.
	* ENCR_MAGMA_MGM_MAC_KTREE (Transform ID 35) is a MAC-only transform		* ENCR_MAGMA_MGM_MAC_KTREE (Transform ID 35) is a MAC-only transform
	based on "Magma" algorithm; it provides no confidentiality and		based on the "Magma" algorithm; it provides no confidentiality and
	thus can only be used in ESP, but not in IKEv2		thus can only be used in ESP, but not in IKEv2.
	Note that transforms ENCR_KUZNYECHIK_MGM_MAC_KTREE and		Note that transforms ENCR_KUZNYECHIK_MGM_MAC_KTREE and
	ENCR_MAGMA_MGM_MAC_KTREE don't provide any confidentiality, but they		ENCR_MAGMA_MGM_MAC_KTREE don't provide any confidentiality, but they
	are defined as Type 1 (Encryption Algorithm) transforms because of		are defined as Type 1 (Encryption Algorithm) transforms because of
	the need to include an Initialization Vector, which is impossible for		the need to include an Initialization Vector (IV), which is
	Type 3 (Integrity Algorithm) transforms.		impossible for Type 3 (Integrity Algorithm) transforms.
	4.1. Tree-based External Re-Keying		4.1. Tree-Based External Rekeying
	All four transforms use the same tree-based external re-keying		All four transforms use the same tree-based external rekeying
	mechanism. The idea is that the key that is provided for the		mechanism. The idea is that the key that is provided for the
	transform is not directly used to protect messages. Instead, a tree		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		of keys is derived using this key as a root. This tree may have
	several levels. The leaf keys are used for message protection, while		several levels. The leaf keys are used for message protection, while
	intermediate nodes keys are used to derive lower-level keys,		intermediate-node keys are used to derive lower-level keys, including
	including leaf keys. See Section 5.2.3 of [RFC8645] for more		leaf keys. See Section 5.2.3 of [RFC8645] for more details. This
	details. This construction allows us to protect a large amount of		construction allows us to protect a large amount of data, at the same
	data, at the same time providing a bound on a number of times any		time providing a bound on a number of times any particular key in the
	particular key in the tree is used, thus defending against some side		tree is used, thus defending against some side-channel attacks and
	channel attacks and also increasing the key lifetime limitations		also increasing the key lifetime limitations based on combinatorial
	based on combinatorial properties.		properties.
	The transforms defined in this document use a three-level tree. The		The transforms defined in this document use a three-level tree. The
	leaf key that protects a message is computed as follows:		leaf key that protects a message is computed as follows:
	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)
	where:		where:
	KDF (k, l, s) Key Derivation Function KDF_GOSTR3411_2012_256		KDF (k, l, s) Key Derivation Function KDF_GOSTR3411_2012_256
	defined in Section 4.5 of [RFC7836], which accepts		(defined in Section 4.5 of [RFC7836]), which accepts
	three input parameters - a key (k), a label (l) and a		three input parameters -- a key (k), a label (l), and
	seed (s) and provides a new key as an output;		a seed (s) -- and provides a new key as output
	K the root key for the tree (see Section 4.4);		K the root key for the tree (see Section 4.4)
	l1, l2, l3 labels defined as 6 octet ASCII strings without null		l1, l2, l3 labels defined as 6-octet ASCII strings without null
	termination:		termination:
	l1 = "level1"		l1 = "level1"
	l2 = "level2"		l2 = "level2"
	l3 = "level3"		l3 = "level3"
	i1, i2, i3 parameters that determine which keys out of the tree		i1, i2, i3 parameters that determine which keys out of the tree
	are used on each level, altogether they determine a		are used on each level. Together, they determine a
	leaf key that is used for message protection; the		leaf key that is used for message protection; the
	length of i1 is one octet, i2 and i3 are two octet		length of i1 is one octet, and i2 and i3 are two-
	integers in network byte order;		octet integers in network byte order
	| indicates concatenation;		| indicates concatenation
	This construction allows us to generate up to 2^8 keys on level 1 and		This construction allows us to generate up to 2^8 keys on level 1 and
	up to 2^16 keys on levels 2 and 3. So, the total number of possible		up to 2^16 keys on levels 2 and 3. So, the total number of possible
	leaf keys generated from a single SA key is 2^40.		leaf keys generated from a single Security Association (SA) key is
			2^40.
	This specification doesn't impose any requirements on the frequency		This specification doesn't impose any requirements on how frequently
	of which the external re-keying takes place. It is expected that		external rekeying takes place. It is expected that the sending
	sending application will follow its own policy dictating how many		application will follow its own policy dictating how many times the
	times the keys on each level must be used.		keys on each level must be used.
	4.2. Initialization Vector Format		4.2. Initialization Vector Format
	Each message protected by the defined transforms MUST contain an		Each message protected by the defined transforms MUST contain an IV.
	Initialization Vector (IV). The IV has a size of 64 bits and		The IV has a size of 64 bits and consists of four fields. The fields
	consists of the four fields, three of which are i1, i2 and i3		i1, i2, and i3 are parameters that determine the particular leaf key
	parameters that determine the particular leaf key this message was		this message was protected with (see Section 4.1). The fourth field
	protected with (see Section 4.1), and the fourth is a counter,		is a counter, representing the message number for this key.
	representing the message number for this key.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: IV Format		Figure 1: IV Format
	where:		where:
	* i1 (1 octet), i2 (2 octets), i3 (2 octets) - parameters,		i1 (1 octet), i2 (2 octets), i3 (2 octets): parameters that
	determining the particular key used to protect this message;		determine the particular key used to protect this message; 2-octet
	2-octets parameters are integers in network byte order		parameters are integers in network byte order
	* pnum (3 octets) - message counter in network byte order for the		pnum (3 octets): message counter in network byte order for the leaf
	leaf key protecting this message; up to 2^24 messages may be		key protecting this message; up to 2^24 messages may be protected
	protected using a single leaf key		using a single leaf key
	For any given SA the IV MUST NOT be used more than once, but there is		For any given SA, the IV MUST NOT be used more than once, but there
	no requirement that IV is unpredictable.		is no requirement that IV be unpredictable.
	4.3. Nonce Format for MGM		4.3. Nonce Format for MGM
	MGM requires a per-message nonce (called Initial Counter Nonce, ICN,		MGM requires a per-message nonce (called the Initial Counter Nonce,
	in the [RFC9058]) that MUST be unique in the context of any leaf key.		or ICN in [RFC9058]) that MUST be unique in the context of any leaf
	The size of the ICN is n-1 bits, where n is the block size of the		key. The size of the ICN is n-1 bits, where n is the block size of
	underlying cipher. The two ciphers used in the transforms defined in		the underlying cipher. The two ciphers used in the transforms
	this document have different block sizes, so two different formats		defined in this document have different block sizes, so two different
	for the ICN are defined.		formats for the ICN are defined.
	MGM specification requires that the nonce be n-1 bits in size, where		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		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		MGM nonces having n bits (the block size of the underlying cipher) in
	size. Since the n is always a multiple of 8 bits, this makes MGM		size. Since n is always a multiple of 8 bits, this makes MGM nonces
	nonces having a whole number of octets. When used inside MGM the		having a whole number of octets. When used inside MGM, the most
	most significant bit of the first octet of the nonce (represented as		significant bit of the first octet of the nonce (represented as an
	an octet string) is dropped, making the effective size of the nonce		octet string) is dropped, making the effective size of the nonce
	equal to n-1 bits. Note that the dropped bit is a part of zero field		equal to n-1 bits. Note that the dropped bit is a part of the "zero"
	(see Figure 2 and Figure 3) which is always set to 0, so no		field (see Figures 2 and 3), which is always set to 0, so no
	information is lost when it is dropped.		information is lost when it is dropped.
	4.3.1. MGM Nonce Format for "Kuznyechik" based Transforms		4.3.1. MGM Nonce Format for Transforms Based on the "Kuznyechik" Cipher
	For transforms based on "Kuznyechik" cipher		For transforms based on the "Kuznyechik" cipher
	(ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) the ICN		(ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE), the
	consists of a zero octet, a 24-bit message counter and a 96-bit		ICN consists of a "zero" octet; a 24-bit message counter; and a
	secret salt, that is fixed for SA and is not transmitted.		96-bit secret salt, which is fixed for the SA and is not transmitted.
	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 |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Nonce format for "Kuznyechik" based transforms		Figure 2: Nonce Format for Transforms Based on the "Kuznyechik"
			Cipher
	where:		where:
	* zero (1 octet) - set to 0		zero (1 octet): set to 0
	* pnum (3 octets) - the counter for the messages protected by the		pnum (3 octets): the counter for the messages protected by the given
	given leaf key; this field MUST be equal to the pnum field in the		leaf key; this field MUST be equal to the pnum field in the IV
	IV
	* salt (12 octets) - secret salt		salt (12 octets): secret salt. The salt is a string of bits that
			are formed when the SA is created (see Section 4.4 for details).
			The salt does not change during the SA's lifetime and is not
			transmitted on the wire. Every SA will have its own salt.
	4.3.2. MGM Nonce Format for "Magma" based Transforms		4.3.2. MGM Nonce Format for Transforms Based on the "Magma" Cipher
	For transforms based on "Magma" cipher (ENCR_MAGMA_MGM_KTREE and		For transforms based on the "Magma" cipher (ENCR_MAGMA_MGM_KTREE and
	ENCR_MAGMA_MGM_MAC_KTREE) the ICN consists of a zero octet, a 24-bit		ENCR_MAGMA_MGM_MAC_KTREE), the ICN consists of a "zero" octet; a
	message counter and a 32-bit secret salt, that is fixed for SA and is		24-bit message counter; and a 32-bit secret salt, which is fixed for
	not transmitted.		the SA and is not transmitted.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Nonce format for "Magma" based transforms		Figure 3: Nonce Format for Transforms Based on the "Magma" Cipher
	where:		where:
	* zero (1 octet) - set to 0		zero (1 octet): set to 0
	* pnum (3 octets) - the counter for the messages protected by the		pnum (3 octets): the counter for the messages protected by the given
	given leaf key; this field MUST be equal to the pnum field in the		leaf key; this field MUST be equal to the pnum field in the IV
	IV
	* salt (4 octets) - secret salt		salt (4 octets): secret salt. The salt is a string of bits that are
			formed when the SA is created (see Section 4.4 for details). The
			salt does not change during the SA's lifetime and is not
			transmitted on the wire. Every SA will have its own salt.
	4.4. Keying Material		4.4. Keying Material
	We'll refer as "transform key" to a string of bits that are used to		We'll call a string of bits that is used to initialize the transforms
	initialize the transforms defined in this specification. The		defined in this specification a "transform key". The transform key
	transform key is a composite entity consisting of the root key for		is a composite entity consisting of the root key for the tree and the
	the tree and the secret salt.		secret salt.
	The transform key for ENCR_KUZNYECHIK_MGM_KTREE and		The transform key for the ENCR_KUZNYECHIK_MGM_KTREE and
	ENCR_KUZNYECHIK_MGM_MAC_KTREE transforms consists of 352 bits (44		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		octets), of which the first 256 bits is a root key for the tree
	(denoted as K in Section 4.1) and the remaining 96 bits is a secret		(denoted as K in Section 4.1) and the remaining 96 bits is a secret
	salt (see Section 4.3.1).		salt (see Section 4.3.1).
	The transform key for ENCR_MAGMA_MGM_KTREE and		The transform key for the ENCR_MAGMA_MGM_KTREE and
	ENCR_MAGMA_MGM_MAC_KTREE transforms consists of 288 bits (36 octets),		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		of which the first 256 bits is a root key for the tree (denoted as K
	in Section 4.1) and the remaining 32 bits is a secret salt (see		in Section 4.1) and the remaining 32 bits is a secret salt (see
	Section 4.3.2).		Section 4.3.2).
	In case of ESP the transform keys are extracted from the KEYMAT as		In the case of ESP, the transform keys are extracted from the KEYMAT
	defined in Section 2.17 of [RFC7296]. In case of IKEv2 the transform		as defined in Section 2.17 of [RFC7296]. In the case of IKEv2, the
	keys are either SK_ei or SK_er, which are generated as defined in		transform keys are either SK_ei or SK_er, which are generated as
	Section 2.14 of [RFC7296]. Note that since these transforms provide		defined in Section 2.14 of [RFC7296]. Note that since these
	authenticated encryption, no additional keys are needed for		transforms provide authenticated encryption, no additional keys are
	authentication. It means that in case of IKEv2 the keys SK_ai/SK_ar		needed for authentication. This means that, in the case of IKEv2,
	are not used and MUST be treated as having zero length.		the keys SK_ai/SK_ar are not used and MUST be treated as having zero
			length.
	4.5. Integrity Check Value		4.5. Integrity Check Value
	The length of the authentication tag that MGM can compute is in the		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.		range from 32 bits to the block size of the underlying cipher.
	Section 4 of the [RFC9058] states that the authentication tag length		Section 4 of [RFC9058] states that the authentication tag length MUST
	must be fixed for a particular protocol. For "Kuznyechik" based		be fixed for a particular protocol. For transforms based on the
	transforms (ENCR_KUZNYECHIK_MGM_KTREE and		"Kuznyechik" cipher (ENCR_KUZNYECHIK_MGM_KTREE and
	ENCR_KUZNYECHIK_MGM_MAC_KTREE) the resulting Integrity Check Value		ENCR_KUZNYECHIK_MGM_MAC_KTREE), the resulting Integrity Check Value
	(ICV) length is set to 96 bits. For "Magma" based transforms		(ICV) length is set to 96 bits. For transforms based on the "Magma"
	(ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE) the full ICV		cipher (ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE), the full
	length is set to the block size (64 bits).		ICV length is set to the block size (64 bits).
	4.6. Plaintext Padding		4.6. Plaintext Padding
	Transforms defined in this document don't require any plaintext		The transforms defined in this document don't require any plaintext
	padding, as specified in [RFC9058]. It means, that only those		padding, as specified in [RFC9058]. This means that only those
	padding requirements that are imposed by the protocol are applied (4		padding requirements that are imposed by the protocol are applied (4
	bytes for ESP, no padding for IKEv2).		bytes for ESP, no padding for IKEv2).
	4.7. AAD Construction		4.7. AAD Construction
	4.7.1. ESP AAD		4.7.1. ESP AAD
	Additional Authenticated Data (AAD) in ESP is constructed differently		Additional Authenticated Data (AAD) in ESP is constructed
	depending on the transform being used and whether Extended Sequence		differently, depending on the transform being used and whether the
	Number (ESN) is in use or not. The ENCR_KUZNYECHIK_MGM_KTREE and		Extended Sequence Number (ESN) is in use or not. The
	ENCR_MAGMA_MGM_KTREE provide confidentiality, so the content of the		ENCR_KUZNYECHIK_MGM_KTREE and ENCR_MAGMA_MGM_KTREE transforms provide
	ESP body is encrypted and AAD consists of the ESP SPI and (E)SN. The		confidentiality, so the content of the ESP body is encrypted and the
	AAD is constructed similarly to the one in [RFC4106].		AAD consists of the ESP Security Parameter Index (SPI) and (E)SN.
			The AAD is constructed similarly to the AAD in [RFC4106].
	On the other hand the ENCR_KUZNYECHIK_MGM_MAC_KTREE and		On the other hand, the ENCR_KUZNYECHIK_MGM_MAC_KTREE and
	ENCR_MAGMA_MGM_MAC_KTREE don't provide confidentiality, they provide		ENCR_MAGMA_MGM_MAC_KTREE transforms don't provide confidentiality;
	only message authentication. For this purpose the IV and the part of		they provide only message authentication. For this purpose, the IV
	ESP packet that is normally encrypted are included in the AAD. For		and the part of the ESP packet that is normally encrypted are
	these transforms encryption capability provided by MGM is not used.		included in the AAD. For these transforms, the encryption capability
	The AAD is constructed similarly to the one in [RFC4543].		provided by MGM is not used. The AAD is constructed similarly to the
			AAD in [RFC4543].
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: AAD for AEAD transforms with 32-bit SN		Figure 4: AAD for AEAD Transforms with 32-Bit SN
	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 |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: AAD for AEAD transforms with 64-bit ESN		Figure 5: AAD for AEAD Transforms with 64-Bit ESN
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: AAD for authentication only transforms with 32-bit SN		Figure 6: AAD for Authentication-Only Transforms with 32-Bit SN
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: AAD for authentication only transforms with 64-bit ESN		Figure 7: AAD for Authentication-Only Transforms with 64-Bit ESN
	4.7.2. IKEv2 AAD		4.7.2. IKEv2 AAD
	For IKEv2 the AAD consists of the IKEv2 Header, any unencrypted		For IKEv2, the AAD consists of the IKEv2 Header, any unencrypted
	payloads following it (if present) and the Encrypted (or the		payloads following it (if present), and either the Encrypted payload
	Encrypted Fragment) payload header. The AAD is constructed similar		header (Section 3.14 of [RFC7296]) or the Encrypted Fragment payload
	to the one in [RFC5282].		(Section 2.5 of [RFC7383]), depending on whether IKE fragmentation is
			used. The AAD is constructed similarly to the AAD in [RFC5282].
	1 2 3		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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: AAD for IKEv2		Figure 8: AAD for IKEv2 in the Case of the Encrypted Payload
			1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ IKEv2 Header ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ Unencrypted IKE Payloads ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Next Payload |C| RESERVED | Payload Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Fragment Number | Total Fragments |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 9: AAD for IKEv2 in the Case of the Encrypted Fragment Payload
	4.8. Using Transforms		4.8. Using Transforms
	When SA is established the i1, i2 and i3 parameters are set to 0 by		When the SA is established, the i1, i2, and i3 parameters are set to
	the sender and a leaf key is calculated. The pnum parameter starts		0 by the sender and a leaf key is calculated. The pnum parameter
	from 0 and is incremented with each message protected by the same		starts from 0 and is incremented with each message protected by the
	leaf key. When sender decides that the leaf should be changed, it		same leaf key. When the sender decides that the leaf should be
	increments i3 parameter and generates a new leaf key. The pnum		changed, it increments the i3 parameter and generates a new leaf key.
	parameter for the new leaf key is reset to 0 and the process		The pnum parameter for the new leaf key is reset to 0, and the
	continues. If the sender decides, that third-level key corresponding		process continues. If the sender decides that a third-level key
	to i3 is used enough times, it increments i2, resets i3 to 0 and		corresponding to i3 is used enough times, it increments i2, resets i3
	calculates a new leaf key. The pnum is reset to 0 (as with every new		to 0, and calculates a new leaf key. The pnum is reset to 0 (as with
	leaf key) and the process continues. Similar procedure is used when		every new leaf key), and the process continues. A similar procedure
	second-level key needs to be changed.		is used when a second-level key needs to be changed.
	A combination of i1, i2, i3 and pnum MUST NOT repeat for any		A combination of i1, i2, i3, and pnum MUST NOT repeat for any
	particular SA. This means that wrapping around of these counters is		particular SA. This means that the wrapping of these counters is not
	not allowed: when i2, i3 or pnum reach their maximum values, a		allowed: when i2, i3, or pnum reaches its respective maximum value, a
	procedure of changing a leaf key described above is executed, and if		procedure for changing a leaf key, described above, is executed, and
	all four parameters reach their maximum values, the IPsec SA becomes		if all four parameters reach their maximum values, the IPsec SA
	unusable.		becomes unusable.
	There may be other reasons to recalculate leaf keys beside reaching		There may be other reasons to recalculate leaf keys besides reaching
	maximum values for the counters. For example, as described in		maximum values for the counters. For example, as described in
	Section 5, it is RECOMMENDED that the sender count the number of		Section 5, it is RECOMMENDED that the sender count the number of
	octets protected by a particular leaf key and generate a new key when		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		some threshold is reached, and at the latest when reaching the octet
	limits stated in Section 5 for each of the ciphers.		limits stated in Section 5 for each of the ciphers.
	The receiver always uses i1, i2 and i3 from the received message. If		The receiver always uses i1, i2, and i3 from the received message.
	they differ from the values in previously received packets, a new		If they differ from the values in previously received packets, a new
	leaf key is calculated. The pnum parameter is always used from the		leaf key is calculated. The pnum parameter is always used from the
	received packet. To improve performance implementations may cache		received packet. To improve performance, implementations may cache
	recently used leaf key. When a new leaf key is calculated (based on		recently used leaf keys. When a new leaf key is calculated (based on
	the values from received message) the old key may be kept for some		the values from the received message), the old key may be kept for
	time to improve performance in case of possible packet reordering		some time to improve performance in the case of possible packet
	(when packets protected by the old leaf key are delayed and arrive		reordering (when packets protected by the old leaf key are delayed
	later).		and arrive later).
	5. Security Considerations		5. Security Considerations
	The most important security consideration for MGM is that the nonce		The most important security consideration for MGM is that the nonce
	MUST NOT repeat for a given key. For this reason the transforms		MUST NOT repeat for a given key. For this reason, the transforms
	defined in this document MUST NOT be used with manual keying.		defined in this document MUST NOT be used with manual keying.
	Excessive use of the same key can give an attacker advantages in		Excessive use of the same key can give an attacker advantages in
	breaking security properties of the transforms defined in this		breaking security properties of the transforms defined in this
	document. For this reason the amount of data any particular key is		document. For this reason, the amount of data that any particular
	used to protect should be limited. This is especially important for		key is used to protect should be limited. This is especially
	algorithms with 64-bit block size (like "Magma"), which currently are		important for algorithms with a 64-bit block size (like "Magma"),
	generally considered insecure after protecting relatively small		which currently are generally considered insecure after protecting a
	amount of data. For example, Section 3.4 of [SP800-67] limits the		relatively small amount of data. For example, Section 3.4 of
	number of blocks that are allowed to be encrypted with Triple DES		[SP800-67] limits the number of blocks that are allowed to be
	cipher by 2^20 (8 Mbytes of data). This document defines a rekeying		encrypted with the Triple DES cipher to 2^20 (8 MB of data). This
	mechanism that allows to mitigate a weak security of a 64-bit block		document defines a rekeying mechanism that allows the mitigation of
	cipher by frequent changing of encryption key.		weak security of a 64-bit block cipher by frequently changing the
			encryption key.
	For transforms defined in this document, [GOST-ESP] recommends		For transforms defined in this document, [GOST-ESP] recommends
	limiting the number of octets protected with a single Kmsg key by the		limiting the number of octets protected with a single K_msg key by
	following values:		the following values:
	* for transforms based on "Kuznyechik" cipher		* 2^41 octets for transforms based on the "Kuznyechik" cipher
	(ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE) -		(ENCR_KUZNYECHIK_MGM_KTREE and ENCR_KUZNYECHIK_MGM_MAC_KTREE)
	2^41 octets;
	* for transforms based on "Magma" cipher (ENCR_MAGMA_MGM_KTREE and		* 2^28 octets for transforms based on the "Magma" cipher
	ENCR_MAGMA_MGM_MAC_KTREE) - 2^28 octets;		(ENCR_MAGMA_MGM_KTREE and ENCR_MAGMA_MGM_MAC_KTREE)
	These values are based on combinatorial properties and may be further		These values are based on combinatorial properties and may be further
	restricted if side channels attacks are taken into considerations.		restricted if side-channel attacks are taken into consideration.
	Note that the limit for "Kuznyechik" based transforms is unreachable		Note that the limit for transforms based on the "Kuznyechik" cipher
	because due to transforms construction the number of protected		is unreachable because, due to the construction of the transforms,
	messages is limited to 2^24 and each message (either IKEv2 message or		the number of protected messages is limited to 2^24 and each message
	ESP datagram) is limited to 2^16 octets in size, giving 2^40 octets		(either IKEv2 messages or ESP datagrams) is limited to 2^16 octets in
	as the maximum amount of data that can be protected with a single		size, giving 2^40 octets as the maximum amount of data that can be
	Kmsg.		protected with a single K_msg.
	Section 4 of [RFC9058] discusses the possibility of truncating		Section 4 of [RFC9058] discusses the possibility of truncating
	authentication tags in MGM as a trade-off between message expansion		authentication tags in MGM as a trade-off between message expansion
	and the forgery probability. This specification truncates an		and the probability of forgery. This specification truncates an
	authentication tag length for "Kuznyechik" based transforms to 96		authentication tag length for transforms based on the "Kuznyechik"
	bits. This decreases message expansion still providing very low		cipher to 96 bits. This decreases message expansion while still
	forgery probability of 2^-96.		providing a very low probability of forgery: 2^-96.
	An attacker can send a lot of packets with arbitrary chosen i1, i2,		An attacker can send a lot of packets with arbitrarily chosen i1, i2,
	and i3 parameters. This will 1) force a recepient to recalculate the		and i3 parameters. This will 1) force a recipient to recalculate the
	leaf key for every received packet if i1, i2, and i3 are different		leaf key for every received packet if i1, i2, and i3 are different
	from the previous one, thus consuming CPU resources and 2) force a		from these values in previously received packets, thus consuming CPU
	recepient to make verification attempts (that would fail) on a large		resources and 2) force a recipient to make verification attempts
	amount of data, thus allowing the attacker for deeper analyzing of		(that would fail) on a large amount of data, thus allowing the
	the underlying cryptographic primitive (see		attacker a deeper analysis of the underlying cryptographic primitive
	[I-D.irtf-cfrg-aead-limits]). Implementations MAY initiate re-keying		(see [AEAD-USAGE-LIMITS]). Implementations MAY initiate rekeying if
	if they deem they receive too many packets with invalid ICV.		they deem that they receive too many packets with an invalid ICV.
	Security properties of MGM are discussed in [MGM-SECURITY].		Security properties of MGM are discussed in [MGM-SECURITY].
	6. IANA Considerations		6. IANA Considerations
	IANA maintains a registry of "Internet Key Exchange Version 2 (IKEv2)		IANA maintains a registry called "Internet Key Exchange Version 2
	Parameters" with a sub-registry of "Transform Type Values". IANA has		(IKEv2) Parameters" with a subregistry called "Transform Type
	assigned four Transform IDs in the "Transform Type 1 - Encryption		Values". IANA has added the following four Transform IDs to the
	Algorithm Transform IDs" registry and is requested to update their		"Transform Type 1 - Encryption Algorithm Transform IDs" subregistry.
	references to this document (where RFCXXXX is this document):
	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
	7. Acknowledgments		+========+===============================+===========+===========+
			| Number | Name | ESP | IKEv2 |
			| | | Reference | Reference |
			+========+===============================+===========+===========+
			| 32 | ENCR_KUZNYECHIK_MGM_KTREE | RFC 9227 | RFC 9227 |
			+--------+-------------------------------+-----------+-----------+
			| 33 | ENCR_MAGMA_MGM_KTREE | RFC 9227 | RFC 9227 |
			+--------+-------------------------------+-----------+-----------+
			| 34 | ENCR_KUZNYECHIK_MGM_MAC_KTREE | RFC 9227 | Not |
			| | | | allowed |
			+--------+-------------------------------+-----------+-----------+
			| 35 | ENCR_MAGMA_MGM_MAC_KTREE | RFC 9227 | Not |
			| | | | allowed |
			+--------+-------------------------------+-----------+-----------+
	Author wants to thank Adrian Farrel, Russ Housley, Yaron Sheffer and		Table 1: Transform IDs
	Stanislav Smyshlyaev for valuable input in the process of publication
	this document.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, DOI 10.17487/RFC4303, December 2005,		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.		<https://www.rfc-editor.org/info/rfc4303>.
	[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	Kivinen, "Internet Key Exchange Protocol Version 2		Kivinen, "Internet Key Exchange Protocol Version 2
	(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October		(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
	2014, <https://www.rfc-editor.org/info/rfc7296>.		2014, <https://www.rfc-editor.org/info/rfc7296>.
			[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
			(IKEv2) Message Fragmentation", RFC 7383,
			DOI 10.17487/RFC7383, November 2014,
			<https://www.rfc-editor.org/info/rfc7383>.
	[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:		[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
	Hash Function", RFC 6986, DOI 10.17487/RFC6986, August		Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
	2013, <https://www.rfc-editor.org/info/rfc6986>.		2013, <https://www.rfc-editor.org/info/rfc6986>.
	[RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher		[RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher
	"Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,		"Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016,
	<https://www.rfc-editor.org/info/rfc7801>.		<https://www.rfc-editor.org/info/rfc7801>.
	[RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015:		[RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015:
	Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891,		Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891,
	skipping to change at page 15, line 25 ¶		skipping to change at line 680 ¶
	DOI 10.17487/RFC9058, June 2021,		DOI 10.17487/RFC9058, June 2021,
	<https://www.rfc-editor.org/info/rfc9058>.		<https://www.rfc-editor.org/info/rfc9058>.
	[RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,		[RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V.,
	Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines		Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines
	on the Cryptographic Algorithms to Accompany the Usage of		on the Cryptographic Algorithms to Accompany the Usage of
	Standards GOST R 34.10-2012 and GOST R 34.11-2012",		Standards GOST R 34.10-2012 and GOST R 34.11-2012",
	RFC 7836, DOI 10.17487/RFC7836, March 2016,		RFC 7836, DOI 10.17487/RFC7836, March 2016,
	<https://www.rfc-editor.org/info/rfc7836>.		<https://www.rfc-editor.org/info/rfc7836>.
	8.2. Informative References		7.2. Informative References
	[GOST3411-2012]		[GOST3411-2012]
	Federal Agency on Technical Regulating and Metrology,		Federal Agency on Technical Regulating and Metrology,
	"Information technology. Cryptographic Data Security.		"Information technology. Cryptographic data security. Hash
	Hashing function", GOST R 34.11-2012, 2012. (In Russian)		function", GOST R 34.11-2012, August 2012. (In Russian)
	[GOST3412-2015]		[GOST3412-2015]
	Federal Agency on Technical Regulating and Metrology,		Federal Agency on Technical Regulating and Metrology,
	"Information technology. Cryptographic data security.		"Information technology. Cryptographic data security.
	Block ciphers", GOST R 34.12-2015, 2015. (In Russian)		Block ciphers", GOST R 34.12-2015, June 2015. (In
			Russian)
	[GOST-MGM] Federal Agency on Technical Regulating and Metrology,		[GOST-MGM] Federal Agency on Technical Regulating and Metrology,
	"Information technology. Cryptographic data security.		"Information technology. Cryptographic information
	Authenticated encryption block cipher operation modes",		security. Block Cipher Modes Implementing Authenticated
	R 1323565.1.026-2019, 2019. (In Russian)		Encryption", R 1323565.1.026-2019, September 2019. (In
			Russian)
	[GOST-ESP] Federal Agency on Technical Regulating and Metrology,		[GOST-ESP] Federal Agency on Technical Regulating and Metrology,
	"Information technology. Cryptographic data security.		"Information technology. Cryptographic information
	Using Russian cryptographic algorithms in data security		protection. The use of Russian cryptographic algorithms in
	protocol ESP", R 1323565.1.035-2021, 2021. (In Russian)		the ESP information protection protocol",
			R 1323565.1.035-2021, January 2021. (In Russian)
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
	DOI 10.17487/RFC2104, February 1997,		DOI 10.17487/RFC2104, February 1997,
	<https://www.rfc-editor.org/info/rfc2104>.		<https://www.rfc-editor.org/info/rfc2104>.
	[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode		[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
	(GCM) in IPsec Encapsulating Security Payload (ESP)",		(GCM) in IPsec Encapsulating Security Payload (ESP)",
	RFC 4106, DOI 10.17487/RFC4106, June 2005,		RFC 4106, DOI 10.17487/RFC4106, June 2005,
	<https://www.rfc-editor.org/info/rfc4106>.		<https://www.rfc-editor.org/info/rfc4106>.
	skipping to change at page 16, line 32 ¶		skipping to change at line 737 ¶
	Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019,		Keys", RFC 8645, DOI 10.17487/RFC8645, August 2019,
	<https://www.rfc-editor.org/info/rfc8645>.		<https://www.rfc-editor.org/info/rfc8645>.
	[MGM-SECURITY]		[MGM-SECURITY]
	Akhmetzyanova, L., Alekseev, E., Karpunin, G., and V.		Akhmetzyanova, L., Alekseev, E., Karpunin, G., and V.
	Nozdrunov, "Security of Multilinear Galois Mode (MGM)",		Nozdrunov, "Security of Multilinear Galois Mode (MGM)",
	2019, <https://eprint.iacr.org/2019/123.pdf>.		2019, <https://eprint.iacr.org/2019/123.pdf>.
	[SP800-67] National Institute of Standards and Technology,		[SP800-67] National Institute of Standards and Technology,
	"Recommendation for the Triple Data Encryption Algorithm		"Recommendation for the Triple Data Encryption Algorithm
	(TDEA) Block Cipher", November 2017,		(TDEA) Block Cipher", DOI 10.6028/NIST.SP.800-67r2,
			November 2017,
	<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-67r2.pdf>.		NIST.SP.800-67r2.pdf>.
	[I-D.irtf-cfrg-aead-limits]		[AEAD-USAGE-LIMITS]
	Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on		Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on
	AEAD Algorithms", Work in Progress, Internet-Draft, draft-		AEAD Algorithms", Work in Progress, Internet-Draft, draft-
	irtf-cfrg-aead-limits-03, 12 July 2021,		irtf-cfrg-aead-limits-04, 7 March 2022,
	<https://www.ietf.org/archive/id/draft-irtf-cfrg-aead-		<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
	limits-03.txt>.		aead-limits-04>.
	Appendix A. Test Vectors		Appendix A. Test Vectors
	In the following test vectors binary data is represented in		In the following test vectors, binary data is represented in
	hexadecimal format. The numbers in square bracket indicate the size		hexadecimal format. The numbers in square brackets indicate the size
	of the corresponding data in decimal format.		of the corresponding data in decimal format.
	1. ENCR_KUZNYECHIK_MGM_KTREE, example 1:		1. ENCR_KUZNYECHIK_MGM_KTREE (Example 1):
	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
	skipping to change at page 17, line 45 ¶		skipping to change at line 797 ¶
	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
	2. ENCR_KUZNYECHIK_MGM_KTREE, example 2:		2. ENCR_KUZNYECHIK_MGM_KTREE (Example 2):
	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
	skipping to change at page 18, line 45 ¶		skipping to change at line 839 ¶
	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
	3. ENCR_MAGMA_MGM_KTREE, example 1:		3. ENCR_MAGMA_MGM_KTREE (Example 1):
	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
	skipping to change at page 19, line 45 ¶		skipping to change at line 881 ¶
	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
	4. ENCR_MAGMA_MGM_KTREE, example 2:		4. ENCR_MAGMA_MGM_KTREE (Example 2):
	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
	skipping to change at page 20, line 45 ¶		skipping to change at line 923 ¶
	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
	5. ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 1:		5. ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 1):
	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
	skipping to change at page 21, line 41 ¶		skipping to change at line 961 ¶
	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
	6. ENCR_KUZNYECHIK_MGM_MAC_KTREE, example 2:		6. ENCR_KUZNYECHIK_MGM_MAC_KTREE (Example 2):
	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
	skipping to change at page 22, line 41 ¶		skipping to change at line 999 ¶
	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
	7. ENCR_MAGMA_MGM_MAC_KTREE, example 1:		7. ENCR_MAGMA_MGM_MAC_KTREE (Example 1):
	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
	skipping to change at page 23, line 41 ¶		skipping to change at line 1037 ¶
	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
	8. ENCR_MAGMA_MGM_MAC_KTREE, example 2:		8. ENCR_MAGMA_MGM_MAC_KTREE (Example 2):
	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
	skipping to change at page 24, line 41 ¶		skipping to change at line 1075 ¶
	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
			Acknowledgments
			The author wants to thank Adrian Farrel, Russ Housley, Yaron Sheffer,
			and Stanislav Smyshlyaev for valuable input during the publication
			process for this document.
	Author's Address		Author's Address
	Valery Smyslov		Valery Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	PO Box 81		PO Box 81
	Moscow (Zelenograd)		Moscow (Zelenograd)
	124460		124460
	Russian Federation		Russian Federation
	Phone: +7 495 276 0211		Phone: +7 495 276 0211
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 110 change blocks.
	330 lines changed or deleted		374 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/