MAY"> MUST"> MUST NOT"> OPTIONAL"> RECOMMENDED"> NOT RECOMMENDED"> REQUIRED"> SHALL"> SHALL NOT"> SHOULD"> SHOULD NOT"> ]> &namegesp; "CRYPTO-PRO", LLC
18, Suschevsky Val str. Russian Federation 127018 Moscow +7 (916) 686 10 81 +74957804820 lse@cryptopro.ru http://www.cryptopro.ru
"CRYPTO-PRO", LLC
18, Suschevsky Val str. Russian Federation 127018 Moscow +7 (905) 540 88 60 +74957804820 pdn@cryptopro.ru http://www.cryptopro.ru
"S-Terra" LLC
Zelenograd, 6, driveway 4806 Russian Federation 124460 Moscow +74999409061 hell@s-terra.com http://www.s-terra.com/
Secutity Internet Engineering Task Force GOST 28147-89 IPsec ISAKMP ESP IKE IP This document defines the usage of GOST 28147-89 algorithm when providing data integrity and confidentiality in ESP protocol. The contents of this document is technically equivalent to its TC26 ROSSTANDART specification. This specification is maintained by TC26 ROSSTANDART and further updates are available at: http://www.tc26.ru/.
This document contains a technical specification approved by the Technical Committee #26 ("Cryptography and security mechanisms") of Federal Agency on Technical Regulating and Metrology of the Russian Federation (ROSSTANDART) . This memo describes implementation features and additional identification types of ESP protocol when used with GOST 28147-89 encryption algorithm. This document defines the following payload transforms in ESP protocol: combined mode transform ESP_GOST-4M-IMIT; combined mode transform ESP_GOST-1K-IMIT. This memo does not define GOST 28147-89 cryptographic algorithm and formats of a cryptographic data representation. The algorithm itself is defined in GOST 28147-89 national standard , the data and parameters representation corresponds , , and . The development objective of this document is to provide interoperability of IPsec protocol implementations, produced by Russian vendors.
This document operates with terms and definitions from IPsec and ESP standards, only additional definitions are described below.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
GOST 28147-89 encryption of data D in CNT mode with key K and initialization vector IV; GOST 28147-89 decryption of data D in CNT mode with key K and initialization vector IV; diversification of key K by diversification data D (), S-box identifiers are defined in , in this document diversification data is a sequence of 8 bytes, interpreted as a 64-bit unsigned integer in network byte order; generation of GOST 28147-89 MAC on data D with key K, initialization vector IV and inner zero padding to 8-byte boundary; associated data (AEAD in , according to GOST &MAY; contain address, timestamp, IV et al.); 64-bit packet number (if ESN is not negotiated, Seq# value always belongs to the range 1..2^32-1); upper portion of Seq#; lower portion of Seq#; initialization vector of Seq#-th packet; combined mode encryption algorithm key of Seq#-th packet; combined mode MAC algorithm key of Seq#-th packet; preliminary packet check key of Seq#-th packet and SA (only for ESP_GOST-1K-IMIT); base encryption key of SA; base MAC key of SA; key meshing algorithm as described in ; authentication code computed in the ISAKMP SA context (of IKE protocol or another key negotiation protocol) for given IPsec SA and intended for auditing and preliminary check of packet; bytes from byte s to byte f, coherently chosen from the sequence of "bytes" in network byte order.
ISAKMP protocol provides mechanisms of security attributes negotiation. The basic specification of ISAKMP protocol is defined in . In the framework of ISAKMP SA (IKE or another key negotiation protocol) for the given IPsec SA at least the following components are negotiated: 32-bit SPI authentication code (non-confidential); 256-bit symmetric key Kr_e; 256-bit symmetric key Kr_i (only for ESP_GOST-1K-IMIT); GOST 28147-89 parameters (S-box set); SA lifetime in kilobytes (SA Lifetime, Kbytes); SA lifetime in seconds (SA Lifetime, seconds); maximum number of invalid packets. Depending on the transform type, the amount of the negotiated keying material (KEYMAT) is: 36 bytes (Kr_e and SPI-Auth-Code); 68 bytes (Kr_e, Kr_i and SPI-Auth-Code).
ESP packet payload &MUST; meet the requirements to combined mode payload transform defined in . Encapsulating security payloads with GOST 28147-89 encryption algorithm &MUST; comply with the following requirements: Initialization Vector (IV) of 8 bytes is sent in the packet; ESP payload is padded to align on 8-byte boundary; in case of ESN usage, Seq#h value is not included in the transmitted packet; ICV is not explicitly padded; ICV of 4 bytes (for ESP_GOST-4M-IMIT transform) or 8 bytes (for ESP_GOST-1K-IMIT transform) is transmitted in the packet. For being negotiated IPsec SAs it is &RECOMMENDED; to: turn on an anti-replay service; limit the total number of ESP packets and the total size of the ESP payloads with same Seq# by applying additional organizational and technical measures in case of an anti-replay service is not used or partially applied.
Associated data involved in the ESP MAC generation &MUST; contain the following ancillary information: A = SPI | Seq#l | IV
The transforms use vector IV(Seq#), the format of this vector is shown below:
In this case: IVRandom - 4 random bytes IVCounter = (SPI-Auth-Code + SPI + Seq#l + IVRandom) mod 2^32 A receiver &MUST; control IVCounter value on the Seq# preliminary check phase and &MUST-NOT; perform any cryptographic operations in case of failure in preliminary check. If an ESP implementation supports audit logging, this failure &MAY; be classified as an error in Seq# checking. Particularly, packets with an incorrect IVCounter &MUST-NOT; cause changes in the counter of invalid packets and the counter of SA lifetime in kilobytes.
Outbound packet processing &MUST; comply with the requirements specified in with the following modifications: in addition to the checks specified in , it is &RECOMMENDED; to check the ESP payload length in accordance with SA parameters; MAC in the transforms is calculated as follows: substr(0..3, ICV) = gost28147IMIT(0, Kc_i(Seq#), A | Payload Data | Padding | Pad Length | Next Header [ | Seq#h ]) encryption in ESP_GOST-4M-IMIT transform is performed without a key meshing; encryption in ESP_GOST-1K-IMIT transform is performed with the key meshing mode id-Gost28147-89-CryptoPro-KeyMeshing; encryption in the transforms is performed by the formula: encryptCNT(IV(Seq#), Kc_e(Seq#), Payload Data | Padding | Pad Length | Next Header) additional MAC in ESP_GOST-1K-IMIT transform is calculated as follows: substr(4..7, ICV) = gost28147IMIT(0, Kc_i2(Seq#), A | Encrypted Payload [ | Seq#h ] | substr(0..3, ICV)) the sender is &RECOMMENDED; to increase the counter of SA lifetime in kilobytes and compare this value with the maximum of SA lifetime (in kilobytes) for this SA. In case of exceeding the maximum it is &RECOMMENDED; to disable this SA.
Inbound packet processing &MUST; comply with the requirements specified in with the following modifications: in addition to the checks specified in , it is &RECOMMENDED; to check the ESP payload length in accordance with SA parameters; during the preliminary check phase for ESP_GOST-4M-IMIT and ESP_GOST-1K-IMIT transforms it is &RECOMMENDED; to validate IV(Seq#) of the packet ( of this document); during the preliminary check phase for ESP_GOST-1K-IMIT transform ICVchk2 &MUST; be generated, if substr(4..7, ICV) does not match with ICVchk2, a receiver &MUST; abort the packet processing, and &MUST-NOT; change the state of the corresponding SA, and &MAY; not audit such events, and it is NOT &RECOMMENDED; to audit such events without specific requirements. ICVchk2 is calculated as follows: ICVchk2 = gost28147IMIT(0, Kc_i2(Seq#), A | Encrypted Payload [ | Seq#h ] | substr(0..3, ICV)) the receiver is &RECOMMENDED; to increase the counter of SA lifetime in kilobytes and compare them with the maximum value of SA lifetime (in kilobytes). In case of exceeding the maximum it is &RECOMMENDED; to disable this SA; encryption in ESP_GOST-1K-IMIT transform performed with the key meshing mode id-Gost28147-89-CryptoPro-KeyMeshing; decryption in ESP_GOST-4M-IMIT transform performed without a key meshing; decryption in ESP_GOST-1K-IMIT transform performed with the key meshing mode id-Gost28147-89-CryptoPro-KeyMeshing; decryption in the transforms performed by the formula: decryptCNT(IV(Seq#), Kc_e(Seq#), Encrypted Payload) during the MAC check phase for the transforms ICVchk &MUST; be generated, if substr(0..3, ICV) does not match with ICVchk, the receiver is &RECOMMENDED; to increase the counter of invalid packets of the SA and compare this value with the maximum number of invalid packets for this SA. In case of exceeding the maximum it is &RECOMMENDED; to disable this SA. ICVchk is calculated as follows: ICVchk = gost28147IMIT(0, Kc_i(Seq#), A | .. | Next Header [ | Seq#h])
In determining the MTU in the case of using ESP_GOST-4M-IMIT or ESP_GOST-1K-IMIT transform should be guided by the rules specified in , with the addition of 12 bytes for ESP GOST-4M-IMIT (8 bytes IV plus 4 bytes ICV) or 16 bytes for ESP_GOST-1K-IMIT (8 bytes IV and 8 bytes ICV), rounding the result to the higher multiple of 8.
Parameter values for ESP_GOST-4M-IMIT transform are shown below: KeyMeshing = id-Gost28147-89-None-KeyMeshing Kc_e(Seq#) = Divers(Divers(Divers(Kr_e, Seq#&0xffffffff00000000),                   Seq#&0xffffffffffff0000),                   Seq#&0xffffffffffffffc0) Kc_i(Seq#) = Kc_e(Seq#)
Parameter values for ESP_GOST-1K-IMIT transform are shown below: KeyMeshing = id-Gost28147-89-CryptoPro-KeyMeshing; Kc_e(Seq#) = Divers(Divers(Divers(Kr_e, Seq#&0xffffffff00000000),                   Seq#&0xffffffffffff0000),                   Seq#) Kc_i(Seq#) = Kc_e(Seq#) Kc_i2(Seq#) = Divers(Divers(Divers(Kr_i, Seq#&0xffffffff00000000),                   Seq#&0xffffffffffff0000),                   Seq#)
To match the attributes of transform using the protocol IKE both sides &MUST; negotiate the application ID, ESP_GOST_Vendor_ID. The format of this ID is shown below:
In this case ESP_GOST_BASE = { '\x03', '\x10', '\x17', '\xE0', '\x7F', '\x7A', '\x82', '\xE3', '\xAA', '\x69', '\x50', '\xC9', '\x99', '\x99' } (first 14 bytes of GOST R 34.11-94 hash function for "IKE/GOST" string). MJR and MNR bytes represent the values of the major and minor parts of version number for ESP_GOST transform, respectively (i.e. MJR = 1, MNR = 1). Parameter Attribute Value Format Default Value GOST 28147-89 Parameters 32401 B - Maximum packet size 32403 V 65536 Maximum number of invalid packets (SA Life Type) 64402 - 10^5
GOST-28147-89-SBOX Attribute Value id-Gost28147-89-CryptoPro-A-ParamSet 65403 id-Gost28147-89-CryptoPro-B-ParamSet 65404 id-Gost28147-89-CryptoPro-C-ParamSet 65405 id-Gost28147-89-CryptoPro-D-ParamSet 65406 IPsec implementations compliant with the requirements of this document &MUST; implement id-Gost28147-89-CryptoPro-B-ParamSet, which is &RECOMMENDED; for Internet usage. Other parameter sets are &OPTIONAL; and &MAY; be used in networks with specific requirements (e.g. for multilevel encryption usage).
In the case of SA-Life-Type = Max-Integrity-Fails when counter of invalid packets is reached SA-Life-Duration, it is &RECOMMENDED; to block packet processing for this SA and &RECOMMENDED; to start deletion procedure for this SA.
Attribute class: Max-Packet-Len (32403), attribute format: variable length (V) In case of using ESP protocol with IPv6 Jumbograms (sizes from 64 KB to 4 GB), it is &RECOMMENDED; to negotiate the maximum packet length parameter.
Integrity verification as a whole meets the requirements described in and which extends the basic integrity control method for case of combined mode algorithms. Key material derivation for ESP transforms performed in accordance with the , but integrity control keys of IKEv2 (SK_ai and SK_ar) are not used and their size &MUST; be treated as 0 octets. The size of the key material for SK_ei and SK_er keys complies with the size defined in , specifically, 36 or 68 bytes for each key when using ESP_GOST-4M-IMIT or ESP_GOST-1K-IMIT respectively. The required key material is derived iteratively by applying PRF function without alignment to the size of the hash function value.
Associated data involved in the IKEv2 MAC generation &MUST; contain the following ancillary information: A = IKEv2-Header | Unencrypted IKE Payloads | Payload Header | IV(Seq#)
The transforms use vector IV(Seq#), the format and recommendations for which are described in of this document with the following clarifications: Seq# = Message-ID*2 + R-flag SPI = SPIi#h + SPIi#l (for packets from Initiator) SPI = SPIr#h + SPIr#l (for packets from Responder) In the case of applying the requirements of it is &RECOMMENDED; either to avoid IKEV2_MESSAGE_ID_SYNC_SUPPORTED negotiation, or to limit the number of packets with Message-ID = 0 () and total size of that packets, starting from second packet.
The authors express their gratitude to Alex S. Kuzmin, a chairman of Rosstandart subcommittee on cryptography (TC26), who initiated a creation of IPsec Working Group, and not only infuse the initial impetus to the development of national standardized IPsec solution based on GOST 28147-89 algorithm but also constantly supported this work methodologically and practically. The authors would like to thank Russian representatives of CISCO and CheckPoint, as well as Gazprom, company, which initiates a process to ensure compatibility of IPsec products from different vendors. The authors express special thanks to Dmitry N. Zakharov (LLC "Factor-TS") for protocol implementation verification, Valery A. Smyslov (JSC "ELVIS-PLUS") and Andrew L. Chmora (JSC "InfoTeCS") for number of valuable suggestions and improvements in the protocol itself and its description, Viktor M. Timakov (JSC "Signal-COM") for productive discussions on the cryptographically strong GOST 28147-89 MAC generation mode.
TC26 Author's Addresses Vladimir O. Popov "CRYPTO-PRO", LLC 18, Suschevsky Val str. Moscow, 127018, Russian Federation Phone: +74957804820 EMail: vpopov@cryptopro.ru Mikhail M. Gruntovich "OKB SAPR", PJSC 8, 2nd Kozhevnichesky lane Moscow, 115114, Russian Federation Phone: +74952356265 EMail: gmm@accord.ru Dmitry M. Avramenko "R-alfa", LLC 4/1, Raspletina str. Moscow, 123060, Russian Federation EMail: info@alpha.ru Mark Y. Koshelev "ELVIS-PLUS", PJSC Zelenograd, 5/23, driveway 4806 Moscow, 124498, Russian Federation Phone: +74952760211 EMail: info@elvis.ru George O. Martanov Federal State Unital Enterprise "Scientific and Technical Centre Atlas" 38, Obraztsova str. Moscow, 127018, Russian Federation Phone: +74956892352 EMail: atlas@stcnet.ru Yury Y. Sidorin Federal State Unital Enterprise "Scientific and Technical Centre Atlas" 38, Obraztsova str. Moscow, 127018, Russian Federation Phone: +74956892352 EMail: atlas@stcnet.ru Valery A. Smyslov "ELVIS-PLUS", PJSC Zelenograd, 5/23, driveway 4806 Moscow, 124498, Russian Federation Phone: +74952760211 EMail: info@elvis.ru Stanislav V. Smyshlyaev "CRYPTO-PRO", LLC 18, Suschevsky Val str. Moscow, 127018, Russian Federation Phone: +74957804820 EMail: svs@cryptopro.ru Viktor M. Timakov "Signal-COM", PJSC 19, Usievicha str. Moscow, 125315, Russian Federation Phone: +74956632365 EMail: v.timakov@signal.ru Andrey V. Fedotov "Factor-TS", LLC 11A, 1st Magistralny lane Moscow, 123290, Russian Federation Phone: +74956443130 EMail: fedotov@factor-ts.ru Artem V. Chuprina "Сryptokom", LLC 1, Pionerskaya str., office 001 Vladivostok, 690001, Russian Federation Phone: +74232605201 EMail: kript225@gmail.com
IANA has assigned two numbers for ESP transforms: <TBD-3> for ESP_GOST-4M-IMIT; <TBD-4> for ESP_GOST-1K-IMIT.
Currently, preliminary implementations are using the following private numbers for transforms: 253 for ESP_GOST-4M-IMIT; 252 for ESP_GOST-1K-IMIT.
Private "magic numbers" used in this document: Class Value Type Reference GOST-28147-89-SBOX 32401 B Max-Packet-Len 32403 B Private values used in this document: Name Value Attribute Max-Integrity-Fails 64402 SA-Life-Type id-Gost28147-89-CryptoPro-A-ParamSet 65403 GOST-28147-89-SBOX id-Gost28147-89-CryptoPro-B-ParamSet 65404 GOST-28147-89-SBOX id-Gost28147-89-CryptoPro-C-ParamSet 65405 GOST-28147-89-SBOX id-Gost28147-89-CryptoPro-D-ParamSet 65406 GOST-28147-89-SBOX
Implementations are &RECOMMENDED; to examine for compliance with requirements specified by the Decree of the Government of the Russian Federation (#957). The parameters of cryptographic algorithm affect the strength of the encryption. The use of parameters not described in are &NOT-RECOMMENDED; for implementation, unless tested according to . GOST 28147-89 block length is 64-bit, so to ensure the confidentiality and integrity of data IPsec implementations are &RECOMMENDED; to use the following limitations: For ESP_GOST-4M-IMIT transform it is &RECOMMENDED; to process packets that do not exceed the size of 64 Kbytes. For IPv6 packets it is NOT &RECOMMENDED; to negotiate Max-Packet-Len value more than 64 Kbytes and it is NOT &RECOMMENDED; to use IPv6 Jumbograms () without appropriate research. It is &RECOMMENDED; to renegotiate keys for a new ESP SA after the transfer of maximum amount of data for SA (SA Lifetime, Kbytes) - 2^80 bytes; For ESP_GOST-1K-IMIT transform it is &RECOMMENDED; to renegotiate keys for a new ESP SA after the transfer of maximum amount of data for SA (SA Lifetime, Kbytes) - 2^80 bytes; For implementations it is &RECOMMENDED; to negotiate SA lifetime in kilobytes and seconds, ; It is &NOT-RECOMMENDED; to negotiate SA lifetime in seconds more than 86400 seconds (24 hours); It is &NOT-RECOMMENDED; to negotiate Max-Integrity-Fails value more than 10^5 without appropriate research.
The examples below use default settings. Encryption with id-Gost28147-89-CryptoPro-B-ParamSet.
ESP_GOST-4M-IMIT plaintext (length - 53. bytes):
ESP_GOST-4M-IMIT parameters:
ESP_GOST-4M-IMIT encrypted data (length - 76. bytes (== 8.+8.+53.+3.+4.)):
ESP_GOST-1K-IMIT plaintext (length - 1049. bytes):
ESP_GOST-1K-IMIT parameters:
ESP_GOST-1K-IMIT encrypted data (length - 1080. bytes (== 8.+8.+1049.+7.+4.+4.)):
&RFC2119; &RFC4303; &ESN; &RFC2407; &GOST28147; &RFC4357; Cryptographic Protection for Data Processing System, Technical specification Use GOST 28147-89 for Encapsulating Security Payload (ESP) IPsec protocol (In Russian) (in press) Technical committee #26 of Federal Agency on Technical Regulating and Metrology of the Russian Federation [TODO:XXX xml2rfc required abstract] Empty abstract &RFC2408; &RFC4301; &RFC6071; &RFC2409; &RFC5996; &RFC5282; &RFC5116; &RFC6311; &RFC2675; Cryptographic Protection for Data Processing System, Technical specification Use GOST 28147-89, GOST R 34.11-94, GOST R 34.10-2001, for IKE and ISAKMP (In Russian) (in press) <!-- СИСТЕМЫ ОБРАБОТКИ ИНФОРМАЦИИ ЗАЩИТА КРИПТОГРАФИЧЕСКАЯ ТЕХНИЧЕСКАЯ СПЕЦИФИКАЦИЯ ПО ИСПОЛЬЗОВАНИЮ ГОСТ 28147-89, ГОСТ Р 34.11-94 И ГОСТ Р 34.10-2001 ПРИ СОГЛАСОВАНИИ КЛЮЧЕЙ В ПРОТОКОЛАХ IKE И ISAKMP --> Technical committee #26 of Federal Agency on Technical Regulating and Metrology of the Russian Federation [TODO:XXX xml2rfc required abstract] Empty abstract &ENG-GOST28147; &RFC4490; &RFC4491;
Requirements for a transforms implementation: ESP_GOST-4M-IMIT - REQUIRED; ESP_GOST-1K-IMIT - &OPTIONAL;, it is required for applications that must be strictly robust to attacks based on timing and EMI analysis, and in case of usage very big IPv6 packets (more than 64 kilobytes); id-Gost28147-89-CryptoPro-B-ParamSet - &REQUIRED;.
Some IKEv1 implementations are incompatible with the recommendations , , , and do not support ICV implementation and ICV check in case of negotiation "NULL" integrity algorithm, i.e. a proposal doesn't have an "Authentication Algorithm" (5) attribute. Such IKEv1 protocol implementations &MAY; negotiate this attribute value for "Authentication Algorithm" (5): GOST-NULL-INTEGRITY-ALGORITHM - 65411. ESP SA behavior in such case &MUST; be the same as there is an absence of "Authentication Algorithm" (5) attribute.