Internet Engineering Task Force S. Leontiev, Ed. Internet-Draft D. Pichulin, Ed. Intended status: Informational CRYPTO-PRO Expires: January 31, 2015 A. Fedchenko, Ed. S-Terra July 30, 2014 Using GOST 28147-89 with IPsec Encapsulating Security Payload (ESP) draft-fedchenko-ipsecme-cpesp-gost-03 Abstract 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/. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 31, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Leontiev, et al. Expires January 31, 2015 [Page 1] Internet-Draft GOST for IPsec ESP July 2014 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Terminology . . . . . . . . . . . . . . . . . 3 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Establishing of ESP Security Association (SA) . . . . . . . . 5 4. Encapsulating Security Payloads . . . . . . . . . . . . . . . 5 4.1. Using GOST 28147-89 for ESP Payloads . . . . . . . . . . . 6 4.2. Outbound Packet Processing . . . . . . . . . . . . . . . . 7 4.3. Inbound Packet Processing . . . . . . . . . . . . . . . . 8 4.4. MTU Calculation . . . . . . . . . . . . . . . . . . . . . 9 4.5. ESP_GOST-4M-IMIT Transform . . . . . . . . . . . . . . . . 9 4.6. ESP_GOST-1K-IMIT Transform . . . . . . . . . . . . . . . . 9 5. Additional ESP SA Parameters and Attributes . . . . . . . . . 10 5.1. GOST 28147-89 Parameters . . . . . . . . . . . . . . . . . 11 5.2. Maximum Value of Invalid Packets Counter . . . . . . . . . 11 5.3. Maximum Packet Length . . . . . . . . . . . . . . . . . . 11 6. IKEv2 Encrypted Payloads . . . . . . . . . . . . . . . . . . . 11 6.1. Using GOST 28147-89 for IKEv2 Payloads . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Remove After IANA Consideration . . . . . . . . . . . . . 15 8.2. Not Subject for IANA Consideration . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. ESP_GOST-4M-IMIT Example . . . . . . . . . . . . . . . . . 17 10.2. ESP_GOST-1K-IMIT Example . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 22 A. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 24 B. Compatibility with Older IKEv1 Implementations . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Leontiev, et al. Expires January 31, 2015 [Page 2] Internet-Draft GOST for IPsec ESP July 2014 1. Introduction 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) [TC26-ESP]. This memo describes implementation features and additional identification types of ESP protocol [RFC4303] when used with GOST 28147-89 encryption algorithm. This document defines the following payload transforms in ESP protocol: o combined mode transform ESP_GOST-4M-IMIT; o 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 [GOST28147] [RFC5830], the data and parameters representation corresponds [RFC4357], [RFC4491], [RFC4490] and [TC26-IKE]. The development objective of this document is to provide interoperability of IPsec protocol implementations, produced by Russian vendors. 2. Terms and Definitions This document operates with terms and definitions from IPsec [RFC4301] and ESP [RFC4303] standards, only additional definitions are described below. 2.1. Requirements Terminology 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 [RFC2119]. 2.2. Notation encryptCNT(IV, K, D): GOST 28147-89 encryption of data D in CNT mode with key K and initialization vector IV; Leontiev, et al. Expires January 31, 2015 [Page 3] Internet-Draft GOST for IPsec ESP July 2014 decryptCNT(IV, K, D): GOST 28147-89 decryption of data D in CNT mode with key K and initialization vector IV; Divers(K, D): diversification of key K by diversification data D (Section 7 of [RFC4357]), S-box identifiers are defined in Section 5.1, in this document diversification data is a sequence of 8 bytes, interpreted as a 64-bit unsigned integer in network byte order; gost28147IMIT(IV, K, D): generation of GOST 28147-89 MAC on data D with key K, initialization vector IV and inner zero padding to 8-byte boundary; A: associated data (AEAD in Section 2.1 of [RFC5116], according to GOST MAY contain address, timestamp, IV et al.); Seq#: 64-bit packet number (if ESN [RFC4304] is not negotiated, Seq# value always belongs to the range 1..2^32-1); Seq#h: upper portion of Seq#; Seq#l: lower portion of Seq#; IV(Seq#): initialization vector of Seq#-th packet; Kc_e(Seq#): combined mode encryption algorithm key of Seq#-th packet; Kc_i(Seq#): combined mode MAC algorithm key of Seq#-th packet; Kc_i2(Seq#): preliminary packet check key of Seq#-th packet and SA (only for ESP_GOST-1K-IMIT); Kr_e: base encryption key of SA; Kr_i: base MAC key of SA; KeyMeshing: key meshing algorithm as described in [RFC4357]; SPI-Auth-Code: 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; substr(s..f, bytes): bytes from byte s to byte f, coherently chosen from the sequence of "bytes" in network byte order. Leontiev, et al. Expires January 31, 2015 [Page 4] Internet-Draft GOST for IPsec ESP July 2014 3. Establishing of ESP Security Association (SA) ISAKMP protocol provides mechanisms of security attributes negotiation. The basic specification of ISAKMP protocol is defined in [RFC2408]. In the framework of ISAKMP SA (IKE or another key negotiation protocol) for the given IPsec SA at least the following components are negotiated: o 32-bit SPI authentication code (non-confidential); o 256-bit symmetric key Kr_e; o 256-bit symmetric key Kr_i (only for ESP_GOST-1K-IMIT); o GOST 28147-89 parameters (S-box set); o SA lifetime in kilobytes (SA Lifetime, Kbytes); o SA lifetime in seconds (SA Lifetime, seconds); o maximum number of invalid packets. Depending on the transform type, the amount of the negotiated keying material (KEYMAT) is: For ESP_GOST-4M-IMIT: 36 bytes (Kr_e and SPI-Auth-Code); For ESP_GOST-1K-IMIT: 68 bytes (Kr_e, Kr_i and SPI-Auth-Code). 4. Encapsulating Security Payloads ESP packet payload MUST meet the requirements to combined mode payload transform defined in Section 2 of [RFC4303]. Encapsulating security payloads with GOST 28147-89 encryption algorithm MUST comply with the following requirements: o Initialization Vector (IV) of 8 bytes is sent in the packet; o ESP payload is padded to align on 8-byte boundary; o in case of ESN usage, Seq#h value is not included in the transmitted packet; o ICV is not explicitly padded; Leontiev, et al. Expires January 31, 2015 [Page 5] Internet-Draft GOST for IPsec ESP July 2014 o 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: o turn on an anti-replay service; o 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. 4.1. Using GOST 28147-89 for ESP Payloads Associated data involved in the ESP MAC generation MUST contain the following ancillary information: A = SPI | Seq#l | IV 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq#l | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV(Seq#) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Associated data (A) for ESP The transforms use vector IV(Seq#), the format of this vector is shown below: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IVRandom | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IVCounter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Leontiev, et al. Expires January 31, 2015 [Page 6] Internet-Draft GOST for IPsec ESP July 2014 Figure 2: IV for ESP_GOST-4M-IMIT and ESP_GOST-1K-IMIT 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. 4.2. Outbound Packet Processing Outbound packet processing MUST comply with the requirements specified in Section 3.3 of [RFC4303] with the following modifications: o in addition to the checks specified in Section 3.3.1 of [RFC4303], it is RECOMMENDED to check the ESP payload length in accordance with SA parameters; o 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 ]) o encryption in ESP_GOST-4M-IMIT transform is performed without a key meshing; o encryption in ESP_GOST-1K-IMIT transform is performed with the key meshing mode id-Gost28147-89-CryptoPro-KeyMeshing; o encryption in the transforms is performed by the formula: encryptCNT(IV(Seq#), Kc_e(Seq#), Payload Data | Padding | Pad Length | Next Header) o 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)) Leontiev, et al. Expires January 31, 2015 [Page 7] Internet-Draft GOST for IPsec ESP July 2014 o 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. 4.3. Inbound Packet Processing Inbound packet processing MUST comply with the requirements specified in Section 3.4 of [RFC4303] with the following modifications: o in addition to the checks specified in Section 3.4.2 of [RFC4303], it is RECOMMENDED to check the ESP payload length in accordance with SA parameters; o 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 (Section 4.1 of this document); o 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)) o 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; o encryption in ESP_GOST-1K-IMIT transform performed with the key meshing mode id-Gost28147-89-CryptoPro-KeyMeshing; o decryption in ESP_GOST-4M-IMIT transform performed without a key meshing; o decryption in ESP_GOST-1K-IMIT transform performed with the key meshing mode id-Gost28147-89-CryptoPro-KeyMeshing; o decryption in the transforms performed by the formula: decryptCNT(IV(Seq#), Kc_e(Seq#), Encrypted Payload) Leontiev, et al. Expires January 31, 2015 [Page 8] Internet-Draft GOST for IPsec ESP July 2014 o 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 | Payload Data | Padding | Pad Length | Next Header [ | Seq#h ]) 4.4. MTU Calculation 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 Section 2 of [RFC4303], 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. 4.5. ESP_GOST-4M-IMIT Transform 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#) 4.6. ESP_GOST-1K-IMIT Transform 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#) Leontiev, et al. Expires January 31, 2015 [Page 9] Internet-Draft GOST for IPsec ESP July 2014 5. Additional ESP SA Parameters and Attributes To match the attributes of transform using the protocol IKE [RFC2409] both sides MUST negotiate the application ID, ESP_GOST_Vendor_ID. The format of this ID is shown below: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |M|M| | ESP_GOST_BASE |J|N| | |R|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ESP_GOST_Vendor_ID 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 | Format | Default | | | Value | | Value | +---------------------------------+------------+--------+-----------+ | GOST 28147-89 Parameters | 32401 | B | - | | Maximum packet size | 32403 | V | 65536 | | Maximum number of invalid | 64402 | - | 10^5 | | packets (SA Life Type) | | | | +---------------------------------+------------+--------+-----------+ Table 1: ESP_GOST SA Parameters Leontiev, et al. Expires January 31, 2015 [Page 10] Internet-Draft GOST for IPsec ESP July 2014 5.1. GOST 28147-89 Parameters +--------------------------------------+-----------------+ | 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 | | id-tc26-gost-28147-param-Z | 65407 | +--------------------------------------+-----------------+ Table 2: GOST 28147-89 Parameters The id-tc26-gost-28147-param-Z parameter set is RECOMMENDED for Internet usage by TC26 ROSSTANDART ([TC26UZ] and [rus-popov-esp-sbox-00-rb]). 5.2. Maximum Value of Invalid Packets Counter 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. 5.3. Maximum Packet Length Attribute class: Max-Packet-Len (32403), attribute format: variable length (V) In case of using ESP protocol with IPv6 Jumbograms [RFC2675] (sizes from 64 KB to 4 GB), it is RECOMMENDED to negotiate the maximum packet length parameter. 6. IKEv2 Encrypted Payloads Integrity verification as a whole meets the requirements described in Section 5 of [RFC5282] and [RFC5116] which extends the basic integrity control method [RFC5996] for case of combined mode algorithms. Key material derivation for ESP transforms performed in accordance with the Section 2.14 of [RFC5996], 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 Leontiev, et al. Expires January 31, 2015 [Page 11] Internet-Draft GOST for IPsec ESP July 2014 the size defined in Section 2.14 of [RFC5996], 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. 6.1. Using GOST 28147-89 for IKEv2 Payloads Associated data involved in the IKEv2 MAC generation MUST contain the following ancillary information: A = IKEv2-Header | Unencrypted IKE Payloads | Payload Header | IV(Seq#) 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKE_SA Initiator's SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IKE_SA Responder's SPI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | MjVer | MnVer | Exchange Type | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Unencrypted IKE Payloads ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV(Seq#) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Associated data (A) for IKEv2 payloads The transforms use vector IV(Seq#), the format and recommendations for which are described in Section 4.1 of this document with the following clarifications: Leontiev, et al. Expires January 31, 2015 [Page 12] Internet-Draft GOST for IPsec ESP July 2014 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 [RFC6311] it is RECOMMENDED either to avoid IKEV2_MESSAGE_ID_SYNC_SUPPORTED negotiation, or to limit the number of packets with Message-ID = 0 (Section 12 of [RFC6311]) and total size of that packets, starting from second packet. 7. Acknowledgements 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 Leontiev, et al. Expires January 31, 2015 [Page 13] Internet-Draft GOST for IPsec ESP July 2014 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 Leontiev, et al. Expires January 31, 2015 [Page 14] Internet-Draft GOST for IPsec ESP July 2014 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 "Nryptokom", LLC 1, Pionerskaya str., office 001 Vladivostok, 690001, Russian Federation Phone: +74232605201 EMail: kript225@gmail.com 8. IANA Consideration IANA has assigned two numbers for ESP transforms: for ESP_GOST-4M-IMIT; for ESP_GOST-1K-IMIT. 8.1. Remove After IANA Consideration Currently, preliminary implementations are using the following private numbers for transforms: 253 for ESP_GOST-4M-IMIT; 252 for ESP_GOST-1K-IMIT. Leontiev, et al. Expires January 31, 2015 [Page 15] Internet-Draft GOST for IPsec ESP July 2014 8.2. Not Subject for IANA Consideration Private "magic numbers" used in this document: +--------------------+-------+------+-------------+ | Class | Value | Type | Reference | +--------------------+-------+------+-------------+ | GOST-28147-89-SBOX | 32401 | B | Section 5.1 | | Max-Packet-Len | 32403 | B | Section 5.3 | +--------------------+-------+------+-------------+ Table 3: ESP_GOST "magic numbers" Private values used in this document: +--------------------------------------+-------+--------------------+ | Name | Value | Attribute | +--------------------------------------+-------+--------------------+ | Max-Integrity-Fails | 64402 | SA-Life-Type | | | | [RFC2407] | | id-Gost28147-89-CryptoPro-A-ParamSet | 65403 | GOST-28147-89-SBOX | | | | Section 5.1 | | id-Gost28147-89-CryptoPro-B-ParamSet | 65404 | GOST-28147-89-SBOX | | | | Section 5.1 | | id-Gost28147-89-CryptoPro-C-ParamSet | 65405 | GOST-28147-89-SBOX | | | | Section 5.1 | | id-Gost28147-89-CryptoPro-D-ParamSet | 65406 | GOST-28147-89-SBOX | | | | Section 5.1 | | id-tc26-gost-28147-param-Z | 65407 | GOST-28147-89-SBOX | | | | Section 5.1 | +--------------------------------------+-------+--------------------+ Table 4: ESP_GOST private values 9. Security Considerations 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 [RFC4357] are NOT RECOMMENDED for implementation, unless tested according to Section 9 of [RFC4357]. 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: Leontiev, et al. Expires January 31, 2015 [Page 16] Internet-Draft GOST for IPsec ESP July 2014 o 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 ([RFC2675]) 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; o 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; o For implementations it is RECOMMENDED to negotiate SA lifetime in kilobytes and seconds, Section 4.4.2.1 of [RFC4301]; o It is NOT RECOMMENDED to negotiate SA lifetime in seconds more than 86400 seconds (24 hours); o It is NOT RECOMMENDED to negotiate Max-Integrity-Fails value more than 10^5 without appropriate research. 10. Examples The examples below use default settings. Encryption with id- Gost28147-89-CryptoPro-B-ParamSet. 10.1. ESP_GOST-4M-IMIT Example ESP_GOST-4M-IMIT plaintext (length - 53. bytes): 4500001d 04050607 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34 Leontiev, et al. Expires January 31, 2015 [Page 17] Internet-Draft GOST for IPsec ESP July 2014 ESP_GOST-4M-IMIT parameters: SPI 31323334 Seq#l 0000007d ESN not negotiated Padding | Pad Length | Next Header 000104 SPI-Auth-Code cb4e1a7f Kr_e b63d156f 7aac0dc7 cd915c35 63f61b9d 5c730a74 e331bc8c 3fc24a36 06463893 Kr_e2 = Divers(Kr_e, Seq# & 0xffffffff00000000) 3a742e54 a9e8a3a1 1f4af5f7 c92fdac1 55142bee 86766e8c 03fad68d 35baf3d7 Kr_e1 = Divers(Kr_e2, Seq# & 0xffffffffffff0000) 752bdd27 99dcde7b 92c04591 40fac2cb 974f39dc cf589d45 00a67c75 99ff9fcc Kc_e = Divers(Kr_e1, Seq# & 0xffffffffffffffc0) 0772fe26 c770590f 22902ad2 1a919eee ccab5396 baf2f1b5 54366c30 27a38614 ESP_GOST-4M-IMIT encrypted data (length - 76. bytes (== 8.+8.+53.+3.+4.)): 31323334 0000007d 05060708 01865538 fa104495 3cd50f2b cca22b90 f4f36257 8f4c2435 f04ada62 d0abc8b3 099e0473 d1ccd142 1586d564 a5e3d1c2 34e529ff fe652e24 caad891c 0bd8ba08 10.2. ESP_GOST-1K-IMIT Example Leontiev, et al. Expires January 31, 2015 [Page 18] Internet-Draft GOST for IPsec ESP July 2014 ESP_GOST-1K-IMIT plaintext (length - 1049. bytes): 4500001d 04050607 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 38393a3b 3c3d3e3f 40414243 44454647 48494a4b 4c4d4e4f 50515253 54555657 58595a5b 5c5d5e5f 60616263 64656667 68696a6b 6c6d6e6f 70717273 74757677 78797a7b 7c7d7e7f 80818283 84858687 88898a8b 8c8d8e8f 90919293 94959697 98999a9b 9c9d9e9f a0a1a2a3 a4a5a6a7 a8a9aaab acadaeaf b0b1b2b3 b4b5b6b7 b8b9babb bcbdbebf c0c1c2c3 c4c5c6c7 c8c9cacb cccdcecf d0d1d2d3 d4d5d6d7 d8d9dadb dcdddedf e0e1e2e3 e4e5e6e7 e8e9eaeb ecedeeef f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff 00010203 04050607 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 38393a3b 3c3d3e3f 40414243 44454647 48494a4b 4c4d4e4f 50515253 54555657 58595a5b 5c5d5e5f 60616263 64656667 68696a6b 6c6d6e6f 70717273 74757677 78797a7b 7c7d7e7f 80818283 84858687 88898a8b 8c8d8e8f 90919293 94959697 98999a9b 9c9d9e9f a0a1a2a3 a4a5a6a7 a8a9aaab acadaeaf b0b1b2b3 b4b5b6b7 b8b9babb bcbdbebf c0c1c2c3 c4c5c6c7 c8c9cacb cccdcecf d0d1d2d3 d4d5d6d7 d8d9dadb dcdddedf e0e1e2e3 e4e5e6e7 e8e9eaeb ecedeeef f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff 00010203 04050607 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 38393a3b 3c3d3e3f 40414243 44454647 48494a4b 4c4d4e4f 50515253 54555657 58595a5b 5c5d5e5f 60616263 64656667 68696a6b 6c6d6e6f 70717273 74757677 78797a7b 7c7d7e7f 80818283 84858687 88898a8b 8c8d8e8f 90919293 94959697 98999a9b 9c9d9e9f a0a1a2a3 a4a5a6a7 a8a9aaab acadaeaf b0b1b2b3 b4b5b6b7 b8b9babb bcbdbebf c0c1c2c3 c4c5c6c7 c8c9cacb cccdcecf d0d1d2d3 d4d5d6d7 d8d9dadb dcdddedf e0e1e2e3 e4e5e6e7 e8e9eaeb ecedeeef f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff 00010203 04050607 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 38393a3b 3c3d3e3f 40414243 44454647 48494a4b 4c4d4e4f 50515253 54555657 58595a5b 5c5d5e5f 60616263 64656667 68696a6b 6c6d6e6f 70717273 74757677 78797a7b 7c7d7e7f 80818283 84858687 88898a8b 8c8d8e8f 90919293 94959697 98999a9b 9c9d9e9f a0a1a2a3 a4a5a6a7 a8a9aaab acadaeaf b0b1b2b3 b4b5b6b7 b8b9babb bcbdbebf c0c1c2c3 c4c5c6c7 c8c9cacb cccdcecf d0d1d2d3 d4d5d6d7 d8d9dadb dcdddedf e0e1e2e3 e4e5e6e7 e8e9eaeb ecedeeef f0f1f2f3 f4f5f6f7 f8f9fafb fcfdfeff 00010203 04050607 08090a0b 0c0d0e0f 10111213 14151617 18 Leontiev, et al. Expires January 31, 2015 [Page 19] Internet-Draft GOST for IPsec ESP July 2014 ESP_GOST-1K-IMIT parameters: SPI 31323334 Seq#l 0000007d ESN negotiated Seq#h 0000000b Padding | Pad Length | Next Header 00000000 000504 SPI-Auth-Code c4c08a66 Kr_e b63d156f 7aac0dc7 cd915c35 63f61b9d 5c730a74 e331bc8c 3fc24a36 06463893 Kr_e2 = Divers(Kr_e, Seq# & 0xffffffff00000000) 59f1548e a0b38639 c546fb94 2164d780 f075460a cb72e4cf f3068a03 a184d544 Kr_e1 = Divers(Kr_e2, Seq# & 0xffffffffffff0000) c210c1fc 6988bb00 6ed69111 9d63a619 6c4cee21 799786db 2af3bda9 c77f9e20 Kc_i = Kc_e = Divers(Kr_e1, Seq#) fdcd7812 74018a14 5aee2da7 f21a1581 148378b9 272e3d88 0585ac2e 94b4bbe2 Kr_i cb4e1a7f 2d61710d f264423c ad4384de ce01d676 90556865 f1cb7f7f ab4103c0 Kr_i2 = Divers(Kr_i, Seq# & 0xffffffff00000000) 52aa9784 2ee74f7a 5c3c7436 9fe4f415 5a4bc218 05fc6263 2a1ef408 4d8de3a2 Kr_i1 = Divers(Kr_i2, Seq# & 0xffffffffffff0000) 7ea6c8f3 209ac480 f181aa61 5c38d07b fd680717 16581ff9 c2963646 6094cc3a Kc_i2 = Divers(Kr_i1, Seq#) 138309a0 5813c2bf d3bfb2a9 aff9b511 555c2088 ababcac7 f21f0871 1036aff8 Leontiev, et al. Expires January 31, 2015 [Page 20] Internet-Draft GOST for IPsec ESP July 2014 ESP_GOST-1K-IMIT encrypted data (length - 1080. bytes (== 8.+8.+ 1049.+7.+4.+4.)): 31323334 0000007d 05060708 faf8c51f 85bc7a31 676f1453 c167d042 1e87a0d1 a23cbb97 cefbd7fe e95c3d1a b9f3fa9e 144dc92a 97e6de75 5b1fda97 8436c90b 289c222f 80de286b bdf190b3 be7f6abb f627c56d 25ecc471 9bc9a5f3 403f1852 67b43b70 a860b606 625ab17b 839078dd a55c9e76 78388625 27f17ef8 da3c964f 0e320c68 6e71c9bb e17381d0 321fdfb5 8092f205 2df6d199 90ec758d 31eb6eeb 3e152d43 89d4d402 9ab77fb4 09fcf757 b4086948 cf9d8843 5a2b21f2 6c41aa5f 6b881623 be08b64e 4aeaba95 706598f3 5d56ee18 0feafff4 32b35a54 b37a7c77 6e408d09 65aa2aa4 41f69040 03cec18a e1529416 88afe127 1c0fd90b c9699020 9a98527f e8d4a285 de2f1d09 3b0f6779 a2391f71 d12d1219 c98b74ce 30b35b04 381896c5 205ca00b ed4df571 d24ecfd3 7134b910 7c8eeb2d 6e3dedf3 ffab4af1 1e69b296 fb4a9d0d 3dc364e0 4f0c6ab9 925322e4 0a8ff71e 4281d099 87260500 bdfbdaf2 7669db9e 5b6021c7 91e77aa9 e7e4fe4a c6cafefc 80ff180b e3ec8d33 6fb8172f 460daaf0 1f407230 bc282c25 9f14bc46 2d8d972e d27bf894 29696abb 03d37ff0 f4ff8c0b c1f62112 eba15368 218a94ca 16847d57 55522e27 60913848 50e84cbb 75438c26 9d216dee 67f82392 4f90a745 1b62b561 badadf9e d9bd481f 6c8d1152 307e5b3b ead13bea 6b3d0b8b 20c0e17e 84109d55 3c431bb3 20ce8ea1 c69e7cfb d720e186 dd4bbdb0 00008b23 f7271bcd ab1f10f2 009d98d1 66af8d49 bf41d101 7aec62b3 1c4ad813 f3508887 d626f23d 387e5398 0ac70ddb 2a5688b4 97f16918 b75f52ca d70751ce 3df694ff 7a07f6ba c1de8abd 6ff88df4 c48299b5 c3e056ec 28ab6d6b 7cd16a59 4f41617b 8cb3bdff a5819619 348cb287 6bf4dcdd 4985141b 2dd6f25a 49fce6cb b43a3dc3 8ca7dfcc fb3b4eca 4b1750eb 0d9da228 80bedd9a 56d1768e 5e883cb1 282c6746 792a9fe9 2a2eabfd 9e48f25c 25ee1f6e f75c0d05 8ea213a4 f355cac0 608625f1 d78bc810 7d382ef3 0e87240a 4a4c1b87 0c0714a5 7ddd9d09 e12eaf2d 032a1264 cdaf6feb 52b4f3ea 3abb0304 518a11ec 3086d016 cc81461a 34fe9c5a 112a213d ffee305a 7133184c e05df5aa eabd1d9f 341c2951 a126eabf aad3fd0c 6f81faa4 1ccea61e 9a654dec 266147e4 cf14fed7 17656776 781ac09c 6b1e5650 e0a37e3d 98c7a384 3f3c001f e8e5db0f d9c03490 9775bf74 25cf5f63 5befb502 af14595a 56517525 5c3752d9 2f6c7de7 7e80fb37 b6c7d772 d117e4aa e6b1f3a3 1215889f 02111e63 93bd59cb b263a914 275efa37 8069f230 994564af 9f340363 293286ac 6a97d66b 8045fba9 41f41575 6f52d018 162d445c 2f8e6d47 99d00bf7 f419207f bfc51477 7c217b7d bfe9f660 acdd2c43 b6fcb8fc 37db0f6d 78e29e58 88f35340 18217600 cbae06d1 1f24f66c e3c876b6 5157a1e1 356aeed2 e5f4f5c9 3e4784c2 22678beb a7113bc2 e2de9439 382395c6 9c4d0e84 b900f9e1 88f6ec28 651d9462 bb3465d8 eb50af47 11. References 11.1. Normative References [GOST28147] Government Committee of the USSR for Standards, Leontiev, et al. Expires January 31, 2015 [Page 21] Internet-Draft GOST for IPsec ESP July 2014 "Cryptographic Protection for Data Processing System, Gosudarstvennyi Standard of USSR, GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms (In Russian)", 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005. [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", RFC 4357, January 2006. [TC26-ESP] Technical committee #26 of Federal Agency on Technical Regulating and Metrology of the Russian Federation, "Cryptographic Protection for Data Processing System, Technical specification Use GOST 28147-89 for Encapsulating Security Payload (ESP) IPsec protocol. (In Russian) (in press)", 2013. [TC26UZ] Technical committee #26 of Federal Agency on Technical Regulating and Metrology of the Russian Federation, "Methodical recommendations for S-box parameters assignment in GOST 28147-89. (In Russian)", 2014. [rus-popov-esp-sbox-00-rb] Technical committee #26 of Federal Agency on Technical Regulating and Metrology of the Russian Federation, "Using additional S-box parameters in GOST 28147-89 for payload encryption in IPsec ESP. (Work in progress)", 2014. 11.2. Informative References [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. Leontiev, et al. Expires January 31, 2015 [Page 22] Internet-Draft GOST for IPsec ESP July 2014 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4490] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)", RFC 4490, May 2006. [RFC4491] Leontiev, S. and D. Shefanovski, "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 4491, May 2006. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. [RFC5830] Dolmatov, V., "GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms", RFC 5830, March 2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, February 2011. [RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. Zhang, "Protocol Support for High Availability of IKEv2/ IPsec", RFC 6311, July 2011. [TC26-IKE] Technical committee #26 of Federal Agency on Technical Regulating and Metrology of the Russian Federation, "Cryptographic Protection for Data Processing System, Leontiev, et al. Expires January 31, 2015 [Page 23] Internet-Draft GOST for IPsec ESP July 2014 Technical specification Use GOST 28147-89, GOST R 34.11-94, GOST R 34.10-2001, for IKE and ISAKMP. (In Russian) (in press)", 2013. Appendix A. Compatibility Requirements for a transforms implementation: o ESP_GOST-4M-IMIT - REQUIRED; o 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); o id-Gost28147-89-CryptoPro-B-ParamSet - REQUIRED; o id-tc26-gost-28147-param-Z - REQUIRED. Appendix B. Compatibility with Older IKEv1 Implementations Some IKEv1 implementations are incompatible with the recommendations [RFC4301], [RFC4303], [RFC6071], 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. Leontiev, et al. Expires January 31, 2015 [Page 24] Internet-Draft GOST for IPsec ESP July 2014 Authors' Addresses Serguei E. Leontiev (editor) "CRYPTO-PRO", LLC 18, Suschevsky Val str. Moscow 127018 Russian Federation Phone: +7 (916) 686 10 81 Fax: +74957804820 Email: lse@cryptopro.ru URI: http://www.cryptopro.ru Dmitry N. Pichulin (editor) "CRYPTO-PRO", LLC 18, Suschevsky Val str. Moscow 127018 Russian Federation Phone: +7 (905) 540 88 60 Fax: +74957804820 Email: pdn@cryptopro.ru URI: http://www.cryptopro.ru Andrey A. Fedchenko (editor) "S-Terra" LLC Zelenograd, 6, driveway 4806 Moscow 124460 Russian Federation Fax: +74999409061 Email: hell@s-terra.com URI: http://www.s-terra.com/ Leontiev, et al. Expires January 31, 2015 [Page 25]