Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2)

Introduction This document describes a number of new transforms and a new authentication method using SM2 signature and SM3 hash function for IKEv2 (), based on ISO and Chinese cryptographic standard algorithms ("SM" algorithms) for encryption, hash function, digital signature, and key exchange method. With the definition in this document, the SM algorithms can be used to implement IPSec protocols. For a more detailed introduction to SM cryptographic algorithms, please see Section 1.1. These transforms follow the IKEv2 requirements. Specifically, all the encryption transforms use SM4 in different encryption mode (e.g. CBC mode, Galois/Counter (GCM) mode or Counter with CBC-MAC (CCM) mode) . The key exchange mechanism utilizes Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) over the SM2 elliptic curve, and the signature algorithm combines the SM3 hash function and the SM2 elliptic curve signature scheme.

The SM Algorithms Several different SM cryptographic algorithms are used to integrate with IKEv2, including SM2 for key exchange and authentication, SM4 for encryption, and SM3 as the hash function. SM2 is a set of cryptographic algorithms based on elliptic curve cryptography, including a digital signature, public key encryption and key exchange scheme. In this document, only the SM2 digital signature algorithm and basic key exchange scheme are involved, which have already been added to ISO/IEC 14888-3:2018 (as well as to ). The parameter definition of SM2 is described in . SM4 is a block cipher defined in and now is being standardized by ISO to ISO/IEC 18033-3:2010 . SM3 is a hash function that produces an output of 256 bits. SM3 has already been accepted by ISO in ISO/IEC 10118-3:2018 and has also been described by .

Conventions and Definitions 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.

Transforms Description

Encryption Transforms The new encryption transforms introduced in this document add three encryption algorithms: ENCR_SM4_CBC, ENCR_SM4_GCM and ENCR_SM4_CCM. ENCR_SM4_CBC is encryption transform based on SM4 for SM4 and encryption algorithm using CBC mode. ENCR_SM4_GCM (Transform ID XX) and ENCR_SM4_CCM (Transform ID XX) are AEAD transforms based on SM4 cipher in Galois/Counter mode and SM4 cipher in Counter with CBC-MAC mode, respectively. The hash function for both cipher suites is SM3 ().

ENCR_SM4_CBC The specification of ENCR_SM4_CBC is as follows: The CBC (Cipher Block Chaining) mode is defined in and utilized with the SM4 algorithm in the following sections. The input plaintext of SM4-CBC MUST be a multiple of the block size, which is 128-bits in SM4. SM4-CBC requires an additional input, the IV, that is unpredictable for a particular execution of the encryption process. The IV does not have to be secret. The IV itself, or criteria enough to determine it, MAY be transmitted with ciphertext. A simple test vector of ENCR _SM4_CBC is given in Appendix A of this document.

ENCR_SM4_GCM The ENCR_SM4_GCM authenticated encryption algorithm is defined in , using SM4 as the block cipher, by providing the key, nonce, plaintext, and additional associated data to that mode of operation. An authentication tag conforming to the requirements of IKEv2 as specified in MUST be constructed using the partial contents of the IKEv2 message, starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (i.e., the fourth octet of the Encrypted Payload). This includes any payloads that are between the Fixed IKE Header and the Encrypted Payload. The additional data input that forms the authentication tag MUST be the partial contents of the IKEv2 message, starting from the first octet of the Fixed IKE Header through the last octet of the Payload Header of the Encrypted Payload (i.e., the fourth octet of the Encrypted Payload). This includes any payloads that are between the Fixed IKE Header and the Encrypted Payload. The ENCR_SM4_GCM has four inputs: an SM4 key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). ENCR_SM4_GCM generates two outputs: a ciphertext and message authentication code. The input and output lengths are as follows: The SM4 key length is 16 octets. The max plaintext length is $2^{36} - 31$ octets. The max AAD length is $2^{61} - 1$ octets. The nonce length is 12 octets. The authentication tag length is 16 octets. The max ciphertext length is $2^{36} - 15$ octets. The nonce is generated by the party performing the authenticated encryption operation. Within the scope of any authenticated encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicates. Using the same nonce for two different messages encrypted with the same key destroys the security properties of GCM mode.

ENCR_SM4_CCM The ENCR_SM4_CCM authenticated encryption algorithm is defined in using SM4 as the block cipher. The generation of the authentication tag MUST conform to IKEv2 (See ) as described in the above paragraph. ENCR_SM4_CCM has four inputs: an SM4 key, a nonce, a plaintext, and optional additional authenticated data (AAD). ENCR_SM4_CCM generates two outputs: a ciphertext and a message authentication code. The input and output lengths are as follows: The SM4 key length is 16 octets. The max plaintext length is $2^{24} - 1$ octets. The max AAD length is $2^{64} - 1$ octets. The max ciphertext length is $2^{24} + 15$ octets To have a common set of terms for ENCR _SM4_GCM and ENCR _SM4_CCM, the ENCR _SM4_GCM IV is referred to as a nonce in the remainder of this document. A simple test vector of ENCR _SM4_GCM and ENCR _SM4_CCM is given in Appendix A of this document.

Pseudorandom Function Transform This specification defines a new transform of Type 2 (Pseudorandom Function Transform IDs): PRF_HMAC_SM3 (Transform ID XX). The PRF uses the SM3 hash function with a 256-bit output defined in and and with HMAC construction. The PRF has a 256-bit block size and a 256-bit output length. PRF_ HMAC_SM3 is hash-based message authentication code (or HMAC), which is defined in , using SM3 as the hash function. The PRF_ HMAC_SM3 has two inputs: HMAC key and the plaintext. The output of PRF_ HMAC_SM3 is 256 bits.

Integrity Algorithm Transform This specification defines a new transform of Type 3 (Integrity Algorithm Transform IDs): AUTH_HMAC_SM3 (Transform ID XX). The MAC uses the SM3 hash function with a 256-bit output defined in and and with HMAC construction. AUTH_HMAC_SM3 is specified as described in 2.2. While no fixed key length is specified in , this specification requires that when used as an integrity/authentication algorithm, a fixed key length equal to the output length of the hash functions MUST be supported, and key lengths other than the output length of the associated hash function MUST NOT be supported. These key length restrictions are the same with HMAC-SHA-256 (see Sec2.1.1).

Key Exchange Method Transform This specification defines one new transform of Type 4 (Key Exchange Method Transform IDs): curveSM2. This transform uses a fixed elliptic curve parameter set defined in . The specification of curveSM2 is defined in clause 3.2 of RFC 8998 as ”curveSM2”, which is used to define new cipher suites for TLS 1.3 protocol. Implementations of the key exchange mechanism defined in this document MUST conform to what requires; that is to say, the only valid elliptic curve parameter set for the ”curveSM2” key exchange is defined as follows: curveSM2: A prime field of 256 bits. $y^2 = x^3+ ax + b$ p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFF a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFC b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93 n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 7203DF6B 21C6052B 53BBF409 39D54123 Gx = 32C4AE2C 1F198119 5F990446 6A39C994 8FE30BBF F2660BE1 715A4589 334C74C7 Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0

Authentication Method This section specifies the use of the SM2 signature algorithm as the authentication method for IKEv2 protocol. The SM2 signature algorithm is defined in . The SM2 signature algorithm is based on elliptic curves. The SM2 signature algorithm uses a fixed elliptic curve parameter set defined in . This curve is named "curveSM2" as defined in section 2.4. Implementations of the signature scheme mechanism defined in this document MUST conform to what requires.

Hash Algorithms The SM2 digital signature algorithm uses the SM3 hash functions defined in and . This specification defines one new value for the "IKEv2 Hash Algorithms" registry: SM3 (value XX) for the SM3 hash function with a 256-bit output length. The specification of SM3 is defined as follows: The SM3 algorithm is intended to address multiple use cases for commercial cryptography, including, but not limited to: - the use of digital signatures and their verification; - the generation and verification of message authenticity codes; as well as - the generation of random numbers. SM3 has a Merkle-Damgard construction and is similar to SHA-2 of the MD4 family, with the addition of several strengthening features including a more complex step function and stronger message dependency than SHA-256 . SM3 produces an output hash value of 256 bits long, based on 512-bit input message blocks, on input lengths up to 2^(m) . This details the SM3 algorithm and its internal steps can be find in .

IANA Considerations IANA maintains a registry called "Internet Key Exchange Version 2 (IKEv2) Parameters" with subregistries like "Transform Type Values", “IKEv2 Authentication Method” and “IKEv2 Hash Algorithms”. This document describes 3 new encryption transforms, 1 pseudorandom function transform, 1 integrity algorithm transform, 1 key exchange method transform and a new authentication method using SM2 signature and SM3 hash function for IKEv2 (). IANA is requested to assign 3 new Transform IDs to the "Transform Type 1 - Encryption Algorithm Transform IDs" subregistry,

Number	Name	ESP Reference	IKEv2 Reference
TBD	ENCR_SM4_CBC	TBD	TBD
TBD	ENCR_SM4_GCM	TBD	TBD
TBD	ENCR_SM4_CCM	TBD	TBD

1 Transform ID to the “Transform Type 2 - Pseudorandom Function Transform IDs” subregistry,

Number	Name	ESP Reference	IKEv2 Reference
TBD	PRF_HMAC_SM3	TBD	TBD

1 Transform ID to the “Transform Type 3 - Integrity Algorithm Transform IDs” subregistry,

Number	Name	ESP Reference	IKEv2 Reference
TBD	AUTH_HMAC_SM3	TBD	TBD

1 Transform ID to the “Transform Type 4 - Key Exchange Method Transform IDs” subregistry,

Number	Name	ESP Reference	IKEv2 Reference
TBD	curveSM2	TBD	TBD

1 new Authentication Method to the “IKEv2 Authentication Method” subregistry,

Value	Authentication Method	Reference
TBD	curveSM2	TBD

and 1 new Hash function to the “IKEv2 Hash Algorithms” subregistry.

Value	Hash Algorithm	Reference
TBD	SM3	TBD

Security Considerations At the time of writing, there are no known weak keys for SM cryptographic algorithms SM2, SM3 and SM4, and no security issues have been found for these algorithms. A related work analyzed the security of SM2 algorithm , and the cryptanalysis results shows that SM2 is existentially unforgeable against adaptively chosen-message attacks in the generic group model if the underlying hash function is uniform and collision-resistant and the underlying conversion function is almost-invertible. Besides, SM2 is secure against the generalized key substitution attacks if the underlying hash functions H and h are modeled as non-programmable random oracles (NPROs) . As a result of the increasing prevalence and exploitation of side-channel attacks (, , ), the SM4 algorithm is now confronted with significant threats when utilized in smart cards and other cryptographic devices. However, these attacks can be mitigated through the implementation of side-channel protection. On the other hand, the classic cryptanalysis techniques are not applicable to the entire cipher and are impractical, do not compromise the overall security of SM4.

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet Key Exchange Protocol Version 2 (IKEv2) This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms International Organization for Standardization Information technology -- Security techniques -- Encryption algorithms -- Part 3: Block ciphers International Organization for Standardization IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions International Organization for Standardization NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation --Methods and Techniques NIST Special Publication 800-38A Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC NIST Special Publication 800-38D Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality NIST Special Publication 800-38C Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. [STANDARDS-TRACK] HMAC: Keyed-Hashing for Message Authentication This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK] ShangMi (SM) Cipher Suites for TLS 1.3 This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3. The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations. Secure Hash Standard (SHS) NIST FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION MD4 to Historic Status This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status. This document is not an Internet Standards Track specification; it is published for informational purposes. US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) Federal Information Processing Standard, FIPS Informative References Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 2: Digital signature algorithm Standardization Administration of the People's Republic of China Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 5: Parameter definition Standardization Administration of the People's Republic of China Information security technology -- SM4 block cipher algorithm Standardization Administration of the People's Republic of China Information security technology --- SM3 cryptographic hash algorithm Standardization Administration of China Security on SM2 and GOST signatures against related key attacks IEEE Security of the SM2 signature scheme against generalized key substitution attacks Springer International Publishing. Improved differential fault attack for SM4 cipher Journal of Cryptologic Research Chosen-plaintext algorithm for chosen-plaintext power analysis against SM4 Journal of Cryptologic Research Research on trace driven Cache analysis on SM4 Journal of Cryptologic Research

Appendix A. Test Vectors All values are in hexadecimal and are in network byte order (big endian).

SM4_CBC Test Vectors key:0123456789ABCDEFFEDCBA9876543210 iv：FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF in：0123456789ABCDEFFEDCBA9876543210 out：F0A2B07E64DD2C2590F93E4EDD90FBB4

SM4_GCM Test Vectors Initialization Vector：00001234567800000000ABCD Key：0123456789ABCDEFFEDCBA9876543210 Plaintext：AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA Associated Data：FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2 CipherText：17F399F08C67D5EE19D0DC9969C4BB7D 5FD46FD3756489069157B282BB200735 D82710CA5C22F0CCFA7CBF93D496AC15 A56834CBCF98C397B4024A2691233B8D Authentication Tag：83DE3541E4C2B58177E065A9BF7B62EC

SM4_CCM Test Vectors Initialization Vector：00001234567800000000ABCD Key：0123456789ABCDEFFEDCBA9876543210 Plaintext：AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA Associated Data：FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2 CipherText：48AF93501FA62ADBCD414CCE6034D895 DDA1BF8F132F042098661572E7483094 FD12E518CE062C98ACEE28D95DF4416B ED31A2F04476C18BB40C84A74B97DC5B Authentication Tag：16842D4FA186F56AB33256971FA110F4

SM3 Test Vectors in: 616263 out: 66c7f0f462eeedd9d1f2d46bdc10e4e24167c4875cf2f7a2297da02b8f4ba8e0

AUTH_HMAC_SM3 Test Vectors Key: 00112233445566778899AABBCCDDEEFF in: abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq out: DC813339153491AD81477754EB3DF00DBB3CC3E6A69F9CACCE737DB7E61342FF

Acknowledgments TBD