Using GOST Cryptographic Algorithms in the Internet Key Exchange Protocol Version 2 (IKEv2)ELVIS-PLUSPO Box 81Moscow (Zelenograd)124460Russian Federation+7 495 276 0211svan@elvis.ruStreebogKuznyechikMagmaMGM This document defines a set of cryptographic transforms for use in the Internet Key Exchange protocol version 2 (IKEv2).
The transforms are based on Russian cryptographic standard algorithms (GOST). Use of 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.
The Internet Key Exchange protocol version 2 (IKEv2) defined in is an important part
of the IP Security (IPsec) architecture. It is used for the authenticated key exchange and for the negotiation of various protocol
parameters and features.
This document defines a number of transforms for IKEv2, based on 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 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 ,
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted
as described in BCP 14 when, and only when,
they appear in all capitals, as shown here.
Russian cryptographic standard (GOST) algorithms are a set of cryptographic algorithms of different types -
ciphers, hash functions, digital signatures etc. In particular, Russian cryptographic standard defines
block ciphers "Kuznyechik" (also defined in ) and "Magma" (also defined in ).
Cryptographic standard defines elliptic curve digital signature algorithm
(also defined in ), while defines two cryptographic hash functions "Streebog",
with different output length (also defined in ).
The parameters for the elliptic curves used in GOST signature and key exchange algorithms are defined in .
IKE SA protection using GOST algorithms is defined in .
In particular, two transforms of type 1 (Encryption Algorithm Transform IDs)
can be used for IKE SA protection: ENCR_KUZNYECHIK_MGM_KTREE (32) based on "Kuznyechik"
block cipher and ENCR_MAGMA_MGM_KTREE (33) based on "Magma" block cipher, both in
Multilinear Galois Mode (MGM).
The information here is provided for convenience. For full details, please see .
This specification defines a new transform of type 2 (Pseudorandom Function Transform IDs) - PRF_HMAC_STREEBOG_512 (9).
This transform uses PRF HMAC_GOSTR3411_2012_512 defined in Section 4.1.2 of .
The PRF uses GOST R 34.11-2012 ("Streebog") hash-function with 512-bit output defined in
with HMAC construction.
The PRF has a 512-bit block size and a 512-bit output length.
This specification defines two new transforms of type 4 (Diffie-Hellman Group Transform IDs): GOST3410_2012_256 (33) and
GOST3410_2012_512 (34). These transforms uses Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm over Twisted Edwards curves.
The parameters for these curves are defined in Section A.2 of . In particular, transform GOST3410_2012_256
uses id-tc26-gost-3410-2012-256-paramSetA parameter set and GOST3410_2012_512 uses id-tc26-gost-3410-2012-512-paramSetC
parameter set (both defined in ).
Shared secret is computed as follows. The initiator randomly selects its private key d_i from {1,..,q - 1}, where q is the subgroup order
and is a parameter of the selected curve. Then a public key Q_i is computed as a point on the curve:
Q_i = d_i * G
where G is the generator for the selected curve, and then is sent to the responder. The responder makes the same calculations to get d_r and Q_r and sends Q_r to the initiator.
After peers exchange Q_i and Q_R both sides can compute a point on the curve:
S = ((m / q) * d_i) * Q_r = ((m / q) * d_r) * Q_i
where m is the group order and is a parameter of the selected curve. The shared secret K is an x coordinate of S in a little-endian representation.
The size of K is determined by the size of used curve and is either 256 or 512 bit.
When GOST public key is transmitted in the KE payload, it MUST be represented as x coordinate immediately followed by y coordinate,
each in a little-endian representation. The size of each coordinate 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 payload is either 64 or 128 octets.
Upon receiving peer's public key, implementations MUST check that the key is actually a point on the curve. Otherwise the exchange fails.
Implementations MUST check that the calculated public value S is not an identity element of the curve. If S appears to be the identity element of the curve,
the exchange fails. The INVALID_SYNTAX notification MAY be sent in these cases.
IKEv2 allows various authentication methods to be used for IKE SA establishment. Some methods are tied
to a particular algorithm, while others may be used with different algorithms. This specification
makes no restrictions on using the latter ones with the GOST algorithms. In particular,
"Shared Key Message Integrity Code" (2), defined in , and "NULL Authentication" (13),
defined in , can be used with GOST algorithms with no changes
to the process of the AUTH payload content calculation.
When GOST digital signature is used in IKEv2 for authentication purposes, an Authentication Method "Digital Signature" (14),
defined in , MUST be specified in the AUTH payload.
GOST digital signature algorithm GOST R 34.10-2012 is defined in . There are
two variants of GOST signature algorithm - one over 256-bit elliptic curve and the other over 512-bit key elliptic curve.
The signature value, as defined in , consists of two integers r and s.
The size of each integer is either 256 bit or 512 bit depending on the used elliptic curve.
The content of the Signature Value field in the AUTH payload MUST consist of s immediately followed by r, each in a big-endian representation,
so that the size of the field is either 64 or 128 octets. The AlgorithmIdentifier ASN.1 objects
for GOST digital signature algorithm are defined in .
GOST digital signature algorithm uses GOST hash functions GOST R 34.11-2012 ("Streebog") defined in
. There are two "Streebog" hash functions -
one with 256-bit output length and the other with 512-bit output length. The former is used with
GOST digital signature algorithm over a 256-bit elliptic curve and the latter - over a 512-bit key elliptic curve.
This specification defines two new values for IKEv2 Hash Algorithms registry: STREEBOG_256 (6)
for GOST hash function with 256-bit output length and STREEBOG_512 (7) for the 512-bit length output.
These values MUST be included in the SIGNATURE_HASH_ALGORITHMS notify
if a corresponding GOST digital signature algorithm is supported by the sender
and its local policy allows using this algorithm (see Section 4 of for details).
This section lists GOST signature algorithm ASN.1 AlgorithmIdentifier objects in binary form.
With GOST algorithms, optional parameters in AlgorithmIdentifier objects are always omitted.
This objects are defined in and are provided here for convenience.
id-tc26-signwithdigest-gost3410-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-12-256(2) }
Parameters are absent.
id-tc26-signwithdigest-gost3410-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-12-512(3) }
Parameters are absent.
The security considerations of and apply accordingly.
The security of GOST elliptic curves is discussed in . The security
of "Streebog" hash function is discussed in .
A second preimage attack on "Streebog" is described in
if message size exceeds 2^259 blocks. This attack is not relevant to how "Streebog" is used in IKEv2.
IANA has assigned one Transform ID in the "Transform Type 2 - Pseudorandom Function Transform IDs" registry
(where RFCXXXX is this document):
IANA has assigned two Transform IDs in the "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry
(where RFCXXXX is this document):
IANA has assigned two values in the "IKEv2 Hash Algorithms" registry
(where RFCXXXX is this document):
Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signatureFederal Agency on Technical Regulating and Metrology(In Russian)Information technology. Cryptographic data security. Hashing functionFederal Agency on Technical Regulating and Metrology(In Russian)Information technology. Cryptographic data security. Block ciphersFederal Agency on Technical Regulating and Metrology(In Russian)Information technology. Cryptographic information protection. The use of Russian cryptographic algorithms in the IKEv2 key exchange protocolStandardisation Technical Committee "Cryptographic information protection"(In Russian)Information technology. Cryptographic information protection. The test vectors for the use of Russian cryptographic algorithms in the IKEv2 key exchange protocolStandardisation Technical Committee "Cryptographic information protection"(In Russian)Information technology. Cryptographic data security. Using GOST R 34.10-2012 and GOST R 34.11-2012 algorithms
in X.509 Certificates, CRLs and PKCS #10 Certificate RequestsFederal Agency on Technical Regulating and Metrology(In Russian)On the security properties of Russian standardized elliptic curvesCryptanalysis of GOST R hash functionThe Usage of Counter Revisited: Second-Preimage Attack on New Russian Standardized Hash Function This Appendix contains test vectors for two scenarios. The test vectors were borrowed from .
In both scenarios peers establish, rekey and delete IKE SA and ESP SAs.
The IP addresses of the peers used in both scenarios are the same:
initiator's IP address is 10.111.10.171
responder's IP address is 10.111.10.45
The test vectors also cover IKE message protection for transforms defined in .
The keys SK_ei, SK_er are transform keys (see Section 4.4 of )
and the keys K1i, K2i K3i, K1r, K2r, and K3r represent nodes in the key tree for the initiator and responder correspondently.
The leaf keys K3i and K3r are effectively message protection keys (K_msg in terms of ).
MGM nonces (also known as Initial Counter Nonces) are defined in Section 4.3 of .
IV format is defined in Section 4.2 of and AAD format is defined in Section 4.7 of .
All other keys and entities used in the test vectors are defined in .
With this scenario peers establish, rekey and delete IKE SA and ESP SAs using the following prerequisites:
Peers authenticate each other using preshared key
Initiator's ID is "IKE-Initiator" of type ID_FQDN
Responder's ID is "IKE-Responder" of type ID_FQDN
No NAT is present between the peers
IKE fragmentation is not used
IKE SA is created with the following transforms:
ENCR_KUZNYECHIK_MGM_KTREE
PRF_HMAC_STREEBOG_512
GOST3410_2012_512
ESP SAs are created with the following transforms:
ENCR_KUZNYECHIK_MGM_KTREE
ESN off
The 256-bit preshared key (PSK) used for authentication:
This scenario includes four sub-scenarios.
Establishing of IKE and ESP SAs using the IKE_SA_INIT and the IKE_AUTH exchanges.
<--- HDR, SAr1, KEr, Nr [,N+]
HDR, SK {IDi, [IDr,] [N+,]
AUTH, SAi2, TSi, TSr} --->
<--- HDR, SK {IDr, [N+,]
AUTH, SAr2, TSi, TSr}
]]>
Decrypts ciphertext and verifies ICV using K3i as K_msg, resulted in plaintext
Parses received message
R[61]
E[33]{
D[8](IKE)}
]]>
Creates message
Uses previously computed key K3r
Composes MGM nonce
Composes AAD
Composes plaintext
Encrypts plaintext using K3r as K_msg, resulted in ciphertext
Computes ICV using K3r as K_msg
Composes IV
Sends message, peer receives message
Initiator's actions:
Extracts IV from message
Uses previously computed key K3r
Composes MGM nonce
Extracts ICV from message
Extracts AAD from message
Extracts ciphertext from message
Decrypts ciphertext and verifies ICV using K3r as K_msg, resulted in plaintext
Parses received message
I[53]
E[25]{}
]]>
With this scenario peers establish, rekey and delete IKE SA and ESP SAs using the following prerequisites:
Peers authenticate each other using digital signatures
Initiator's ID is "CN=IKE Interop Test Client, O=ELVIS-PLUS, C=RU" of type ID_DER_ASN1_DN:
Responder's ID is "CN=IKE Interop Test Server, O=ELVIS-PLUS, C=RU" of type ID_DER_ASN1_DN:
No NAT is present between the peers, but using UDP encapsulation is forced by the initiator
by setting NAT_DETECTION_SOURCE_IP notify to all zeroes
IKE fragmentation is used in the IKE_AUTH exchange
IKE SA is created with the following transforms:
ENCR_MAGMA_MGM_KTREE
PRF_HMAC_STREEBOG_512
GOST3410_2012_256
ESP SAs are created with the following transforms:
ENCR_MAGMA_MGM_KTREE
ESN off
The certificates for this scenatio were obtained from the public testing CA service
The initiator's certificate private key (little endian):
The initiator's certificate:
The responder's certificate private key (little endian):
The responder's certificate:
CA certificate:
This scenario includes four sub-scenarios.
Establishing of IKE and ESP SAs using the IKE_SA_INIT and the IKE_AUTH exchanges.
<--- HDR, N(INVALID_KE_PAYLOAD)
HDR, SAi1, KEi, Ni [,N+] --->
<--- HDR, SAr1, KEr, Nr
[,CERTREQ] [,N+]
HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,] [N+,]
AUTH, SAi2, TSi, TSr} --->
<--- HDR, SK {IDr, [CERT,] [N+,]
AUTH, SAr2, TSi, TSr}
]]>