< draft-smyslov-ike2-gost-07.txt		draft-smyslov-ike2-gost-08.txt >
	Network Working Group V. Smyslov		Network Working Group V. Smyslov
	Internet-Draft ELVIS-PLUS		Internet-Draft ELVIS-PLUS
	Intended status: Informational November 10, 2021		Intended status: Informational 4 May 2022
	Expires: May 14, 2022		Expires: 5 November 2022
	Using GOST algorithms in IKEv2		Using GOST Cryptographic Algorithms in the Internet Key Exchange
	draft-smyslov-ike2-gost-07		Protocol Version 2 (IKEv2)
			draft-smyslov-ike2-gost-08
	Abstract		Abstract
	This document defines a set of cryptographic transforms for use in		This document defines a set of cryptographic transforms for use in
	the Internet Key Exchange version 2 (IKEv2) protocol. The transforms		the Internet Key Exchange protocol version 2 (IKEv2). The transforms
	are based on Russian cryptographic standard algorithms (GOST).		are based on Russian cryptographic standard algorithms (GOST). Using
			GOST ciphers in IKEv2 was defined in RFC 9227, this document aims to
			define using GOST algorithms for the rest of cryptographic transforms
			used in IKEv2.
			This specification was developed to facilitate implementations that
			wish to support the GOST algorithms. This document does not imply
			IETF endorsement of the cryptographic algorithms used in this
			document.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 14, 2022.		This Internet-Draft will expire on 5 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 2		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. IKE SA Protection . . . . . . . . . . . . . . . . . . . . . . 3		4. IKE SA Protection . . . . . . . . . . . . . . . . . . . . . . 3
	5. Pseudo Random Function . . . . . . . . . . . . . . . . . . . 3		5. Pseudo Random Function . . . . . . . . . . . . . . . . . . . 4
	6. Shared Key Calculation . . . . . . . . . . . . . . . . . . . 3		6. Shared Key Calculation . . . . . . . . . . . . . . . . . . . 4
	6.1. Recipient Tests . . . . . . . . . . . . . . . . . . . . . 4		6.1. Recipient Tests . . . . . . . . . . . . . . . . . . . . . 5
	7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 4		7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Hash Functions . . . . . . . . . . . . . . . . . . . . . 4		7.1. Hash Functions . . . . . . . . . . . . . . . . . . . . . 5
	7.2. ASN.1 Objects . . . . . . . . . . . . . . . . . . . . . . 5		7.2. ASN.1 Objects . . . . . . . . . . . . . . . . . . . . . . 5
	7.2.1. id-tc26-signwithdigest-gost3410-12-256 . . . . . . . 5		7.2.1. id-tc26-signwithdigest-gost3410-12-256 . . . . . . . 6
	7.2.2. id-tc26-signwithdigest-gost3410-12-512 . . . . . . . 5		7.2.2. id-tc26-signwithdigest-gost3410-12-512 . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 5		8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10.1. Normative References . . . . . . . . . . . . . . . . . . 6		10.1. Normative References . . . . . . . . . . . . . . . . . . 7
	10.2. Informative References . . . . . . . . . . . . . . . . . 7		10.2. Informative References . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	This document defines a number of transforms for the Internet Key		The Internet Key Exchange protocol version 2 (IKEv2) defined in
	Exchange version 2 (IKEv2) [RFC7296]. These transforms are based on		[RFC7296] is an important part of the IP Security (IPsec)
	Russian cryptographic standard algorithms (often called "GOST"		architecture. It is used for the authenticated key exchange and for
	algorithms) for hash function, digital signature and key exchange		the negotiation of various protocol parameters and features.
	method. Along with transforms defined in [I-D.smyslov-esp-gost], the
	transforms defined in this specification allow using GOST		This document defines a number of transforms for IKEv2, based on
	cryptographic algorithms in IPsec protocols.		Russian cryptographic standard algorithms (often reffered to as
			"GOST" algorithms) for hash function, digital signature and key
			exchange method. These definitions are based on the recommendations
			[GOST-IKEv2] established by the Standardisation Technical Committee
			"Cryptographic information protection", which describe how Russian
			cryptographic standard algorithms are used in IKEv2. Along with the
			transforms defined in [RFC9227], the transforms defined in this
			specification allow using GOST cryptographic algorithms in IPsec
			protocols.
			This specification was developed to facilitate implementations that
			wish to support the GOST algorithms. This document does not imply
			IETF endorsement of the cryptographic algorithms used in this
			document.
	2. Terminology and Notation		2. Terminology and Notation
	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 BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Overview		3. Overview
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 27 ¶
	3. Overview		3. Overview
	Russian cryptographic standard (GOST) algorithms are a set of		Russian cryptographic standard (GOST) algorithms are a set of
	cryptographic algorithms of different types - ciphers, hash		cryptographic algorithms of different types - ciphers, hash
	functions, digital signatures etc. In particular, Russian		functions, digital signatures etc. In particular, Russian
	cryptographic standard [GOST3412-2015] defines block ciphers		cryptographic standard [GOST3412-2015] defines block ciphers
	"Kuznyechik" (also defined in [RFC7801]) and "Magma" (also defined in		"Kuznyechik" (also defined in [RFC7801]) and "Magma" (also defined in
	[RFC8891]). Cryptographic standard [GOST3410-2012] defines elliptic		[RFC8891]). Cryptographic standard [GOST3410-2012] defines elliptic
	curve digital signature algorithm (also defined in [RFC7091]), while		curve digital signature algorithm (also defined in [RFC7091]), while
	[GOST3411-2012] defines two cryptographic hash functions "Streebog",		[GOST3411-2012] defines two cryptographic hash functions "Streebog",
	with different output length (also defined in [RFC6986]). The		with different output length (also defined in [RFC6986]). The
	parameters for the elliptic curves used in GOST signature and key		parameters for the elliptic curves used in GOST signature and key
	exchange algorithms are defined in [RFC7836].		exchange algorithms are defined in [RFC7836].
	4. IKE SA Protection		4. IKE SA Protection
	Specification [I-D.smyslov-esp-gost] defines two transforms of type 1		[RFC9227] defines two transforms of type 1 (Encryption Algorithm
	(Encryption Algorithm Transform IDs) based on GOST block ciphers that		Transform IDs) based on GOST block ciphers that can be used for IKE
	may be used for IKE SA protection: ENCR_KUZNYECHIK_MGM_KTREE (32)		SA protection: ENCR_KUZNYECHIK_MGM_KTREE (32) based on "Kuznyechik"
	based on "Kuznyechik" block cipher and ENCR_MAGMA_MGM_KTREE (33)		block cipher and ENCR_MAGMA_MGM_KTREE (33) based on "Magma" block
	based on "Magma" block cipher. Since they are AEAD transforms and		cipher. Since these transforms use ciphers in Multilinear Galois
	provide both encryption and authentication, there is no need for new		Mode (MGM), which provides Authenticated Encryption with Associated
	transform type 3 (Integrity Algorithm Transform IDs), because it must		Data (AEAD) and thus provide both encryption and authentication,
	not be used with these transforms (or must have a value NONE).		there is no need for new transform type 3 (Integrity Algorithm
			Transform IDs) for use in IKEv2, because integrity transforms cannot
			be used with encryption transforms providing AEAD (see Section 3.3 of
			[RFC7296]).
	5. Pseudo Random Function		5. Pseudo Random Function
	This specification defines a new transform of type 2 (Pseudorandom		This specification defines a new transform of type 2 (Pseudorandom
	Function Transform IDs) - PRF_HMAC_STREEBOG_512 (9). This transform		Function Transform IDs) - PRF_HMAC_STREEBOG_512 (9). This transform
	uses PRF HMAC_GOSTR3411_2012_512 defined in Section 4.1.2 of		uses PRF HMAC_GOSTR3411_2012_512 defined in Section 4.1.2 of
	[RFC7836]. The PRF uses GOST R 34.11-2012 ("Streebog") hash-function		[RFC7836]. The PRF uses GOST R 34.11-2012 ("Streebog") hash-function
	with 512-bit output defined in [RFC6986][GOST3411-2012] with HMAC		with 512-bit output defined in [RFC6986][GOST3411-2012] with HMAC
	[RFC2104] construction. The PRF has a 512-bit block size and a		[RFC2104] construction. The PRF has a 512-bit block size and a
	512-bit output length.		512-bit output length.
	skipping to change at page 4, line 20 ¶		skipping to change at page 5, line 11 ¶
	is determined by the size of the used curve and is either 256 or 512		is determined by the size of the used curve and is either 256 or 512
	bits, so that the size of the Key Exchange Data field in the KE		bits, so that the size of the Key Exchange Data field in the KE
	payload is either 64 or 128 octets.		payload is either 64 or 128 octets.
	6.1. Recipient Tests		6.1. Recipient Tests
	Upon receiving peer's public key implementations MUST check that the		Upon receiving peer's public key implementations MUST check that the
	key is actually a point on the curve, otherwise the exchange fails.		key is actually a point on the curve, otherwise the exchange fails.
	Implementations MUST check that the calculated public value S is not		Implementations MUST check that the calculated public value S is not
	an identity element of the curve, in which case the exchange fails.		an identity element of the curve, in which case the exchange fails.
			The INVALID_SYNTAX notification MAY be sent in these cases.
	7. Authentication		7. Authentication
	GOST digital signatures algorithm GOST R 34.10-2012 is defined in		GOST digital signatures algorithm GOST R 34.10-2012 is defined in
	[RFC7091][GOST3410-2012]. There are two variants of GOST signature		[RFC7091][GOST3410-2012]. There are two variants of GOST signature
	algorithm - one over 256-bit elliptic curve and the other over		algorithm - one over 256-bit elliptic curve and the other over
	512-bit key elliptic curve.		512-bit key elliptic curve.
	When GOST digital signature is used in IKEv2 for authentication		When GOST digital signature is used in IKEv2 for authentication
	purposes, an Authentication Method "Digital Signature" (14) MUST be		purposes, an Authentication Method "Digital Signature" (14) MUST be
	skipping to change at page 5, line 11 ¶		skipping to change at page 5, line 50 ¶
	registry: STREEBOG_256 (6) for GOST hash function with 256-bit output		registry: STREEBOG_256 (6) for GOST hash function with 256-bit output
	length and STREEBOG_512 (7) for the 512-bit length output. These		length and STREEBOG_512 (7) for the 512-bit length output. These
	values MUST be included in the SIGNATURE_HASH_ALGORITHMS notify if a		values MUST be included in the SIGNATURE_HASH_ALGORITHMS notify if a
	corresponding GOST digital signature algorithm is supported by the		corresponding GOST digital signature algorithm is supported by the
	sender.		sender.
	7.2. ASN.1 Objects		7.2. ASN.1 Objects
	This section lists GOST signature algorithm ASN.1 AlgorithmIdentifier		This section lists GOST signature algorithm ASN.1 AlgorithmIdentifier
	objects in binary form. This objects are defined in		objects in binary form. This objects are defined in
	[I-D.deremin-rfc4491-bis][USING-GOST-IN-CERTS] and are provided here		[RFC9215][USING-GOST-IN-CERTS] and are provided here for convenience.
	for convenience.
	7.2.1. id-tc26-signwithdigest-gost3410-12-256		7.2.1. id-tc26-signwithdigest-gost3410-12-256
	id-tc26-signwithdigest-gost3410-12-256 OBJECT IDENTIFIER ::= { iso(1)		id-tc26-signwithdigest-gost3410-12-256 OBJECT IDENTIFIER ::= { iso(1)
	member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1)		member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1)
	signwithdigest(3) gost3410-12-256(2) }		signwithdigest(3) gost3410-12-256(2) }
	Parameters are absent.		Parameters are absent.
	Name = id-tc26-signwithdigest-gost3410-12-256		Name = id-tc26-signwithdigest-gost3410-12-256
	skipping to change at page 7, line 17 ¶		skipping to change at page 8, line 17 ¶
	(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>.
	[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>.
	[I-D.deremin-rfc4491-bis]		[RFC9215] Baryshkov, D., Ed., Nikolaev, V., and A. Chelpanov, "Using
	Baryshkov, D., Nikolaev, V., and A. Chelpanov, "Using GOST		GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with
	R 34.10-2012 and GOST R 34.11-2012 algorithms with the		the Internet X.509 Public Key Infrastructure", RFC 9215,
	Internet X.509 Public Key Infrastructure", draft-deremin-		DOI 10.17487/RFC9215, March 2022,
	rfc4491-bis-06 (work in progress), May 2020.		<https://www.rfc-editor.org/info/rfc9215>.
	[I-D.smyslov-esp-gost]		[RFC9227] Smyslov, V., "Using GOST Ciphers in the Encapsulating
	Smyslov, V., "Using GOST ciphers in ESP and IKEv2", draft-		Security Payload (ESP) and Internet Key Exchange Version 2
	smyslov-esp-gost-06 (work in progress), August 2021.		(IKEv2) Protocols", RFC 9227, DOI 10.17487/RFC9227, March
			2022, <https://www.rfc-editor.org/info/rfc9227>.
	10.2. Informative References		10.2. Informative References
	[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>.
	[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,
	September 2020, <https://www.rfc-editor.org/info/rfc8891>.		September 2020, <https://www.rfc-editor.org/info/rfc8891>.
	[GOST3410-2012]		[GOST3410-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.
	Signature and verification processes of [electronic]		Signature and verification processes of [electronic]
	digital signature", GOST R 34.10-2012, 2012.		digital signature", GOST R 34.10-2012, 2012. (In Russian)
	(In Russian)
	[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.
	Hashing function", GOST R 34.11-2012, 2012.		Hashing function", GOST R 34.11-2012, 2012. (In Russian)
	(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.		Block ciphers", GOST R 34.12-2015, 2015. (In Russian)
	(In Russian)		[GOST-IKEv2]
			Standardisation Technical Committee "Cryptographic
			information protection", "Information technology.
			Cryptographic information protection. The use of Russian
			cryptographic algorithms in the IKEv2 key exchange
			protocol", MR 26.2.001-22, 2022. (In Russian)
	[USING-GOST-IN-CERTS]		[USING-GOST-IN-CERTS]
	Federal Agency on Technical Regulating and Metrology,		Federal Agency on Technical Regulating and Metrology,
	"Information technology. Cryptographic data security.		"Information technology. Cryptographic data security.
	Using GOST R 34.10-2012 and GOST R 34.11-2012 algorithms		Using GOST R 34.10-2012 and GOST R 34.11-2012 algorithms
	in X.509 Certificates, CRLs and PKCS #10 Certificate		in X.509 Certificates, CRLs and PKCS #10 Certificate
	Requests", R 1323565.1.023-2018, 2018.		Requests", R 1323565.1.023-2018, 2018. (In Russian)
	(In Russian)
	[GOST-EC-SECURITY]		[GOST-EC-SECURITY]
	Alekseev, E., Nikolaev, V., and S. Smyshlyaev, "On the		Alekseev, E., Nikolaev, V., and S. Smyshlyaev, "On the
	security properties of Russian standardized elliptic		security properties of Russian standardized elliptic
	curves", https://doi.org/10.4213/mvk260, 2018.		curves", https://doi.org/10.4213/mvk260, 2018.
	[STREEBOG-SECURITY]		[STREEBOG-SECURITY]
	Wang, Z., Yu, H., and X. Wang, "Cryptanalysis of GOST R		Wang, Z., Yu, H., and X. Wang, "Cryptanalysis of GOST R
	hash function",		hash
	https://doi.org/10.1016/j.ipl.2014.07.007, 2014.		function", https://doi.org/10.1016/j.ipl.2014.07.007,
			2014.
	[STREEBOG-PREIMAGE]		[STREEBOG-PREIMAGE]
	Guo, J., Jean, J., Leurent, G., Peyrin, T., and L. Wang,		Guo, J., Jean, J., Leurent, G., Peyrin, T., and L. Wang,
	"The Usage of Counter Revisited: Second-Preimage Attack on		"The Usage of Counter Revisited: Second-Preimage Attack on
	New Russian Standardized Hash Function",		New Russian Standardized Hash
	https://eprint.iacr.org/2014/675, 2014.		Function", https://eprint.iacr.org/2014/675, 2014.
	Author's Address		Author's Address
	Valery Smyslov		Valery Smyslov
	ELVIS-PLUS		ELVIS-PLUS
	PO Box 81		PO Box 81
	Moscow (Zelenograd) 124460		Moscow (Zelenograd)
	RU		124460
			Russian Federation
	Phone: +7 495 276 0211		Phone: +7 495 276 0211
	Email: svan@elvis.ru		Email: svan@elvis.ru
End of changes. 26 change blocks.
	74 lines changed or deleted		99 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/