idnits 2.17.1 draft-yang-tls-tls13-sm-suites-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2019) is 1674 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS P. Yang 3 Internet-Draft Ant Financial 4 Intended status: Informational September 19, 2019 5 Expires: March 22, 2020 7 SM Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 8 draft-yang-tls-tls13-sm-suites-01 10 Abstract 12 This draft specifies a set of cipher suites for the Transport Layer 13 Security (TLS) protocol version 1.3 to support SM cryptographic 14 algorithms. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 22, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. The SM Algorithms . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Proposed Cipher Suites . . . . . . . . . . . . . . . . . . . 3 54 3. Cipher Suites Definitions . . . . . . . . . . . . . . . . . . 4 55 3.1. TLS Versions . . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 4 57 3.2.1. SM2 Signature Scheme . . . . . . . . . . . . . . . . 4 58 3.3. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 5 59 3.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 5 60 3.3.2. CertificateRequest . . . . . . . . . . . . . . . . . 6 61 3.3.3. Certificate . . . . . . . . . . . . . . . . . . . . . 7 62 3.3.4. CertificateVerify . . . . . . . . . . . . . . . . . . 7 63 3.4. Key Scheduling . . . . . . . . . . . . . . . . . . . . . 7 64 3.5. Cipher . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.5.1. AEAD_SM4_GCM . . . . . . . . . . . . . . . . . . . . 7 66 3.5.2. AEAD_SM4_CCM . . . . . . . . . . . . . . . . . . . . 8 67 3.6. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 6.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12 74 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 12 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 This document describes two new cipher suites for the Transport Layer 80 Security (TLS) protocol version 1.3 (a.k.a TLSv1.3, [RFC8446]). The 81 new cipher suites are listed as follows (or Section 2): 83 CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 }; 84 CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 }; 86 These new cipher suites contains several SM cryptographic algorithms 87 that provide both authentication and confidentiality. For the more 88 detailed introduction to SM cryptographic algorithms, please read 89 Section 1.1. These cipher suites follow what TLSv1.3 requires. For 90 instance, all the cipher suites mentioned in this draft use ECDHE as 91 the key exchange scheme and use SM4 in either GCM mode or CCM mode to 92 meet the need of TLSv1.3 to have an AEAD capable encryption 93 algorithm. 95 For the details about how these new cipher suites negotiate shared 96 encryption key and protect the record structure, please read 97 Section 3. 99 1.1. The SM Algorithms 101 The new cipher suites defined in this draft use several different SM 102 cryptographic algorithms including SM2 for authentication, SM4 for 103 encryption and SM3 as the hash function. 105 SM2 is a set of elliptic curve based cryptographic algorithms 106 including digital signature, public key encryption and key exchange 107 scheme. In this draft, only the SM2 digital signature algorithm is 108 involved, which has now already been added to ISO/IEC 14888-3:2018 109 [ISO-SM2] (as well as in [GBT.32918.2-2016]). SM4 is a block cipher 110 defined in [GBT.32907-2016] and now is being standardized by ISO to 111 ISO/IEC 18033-3:2010 [ISO-SM4]. SM3 is a hash function which 112 produces an output of 256 bits. SM3 has already been accepted by ISO 113 in ISO/IEC 10118-3:2018 [ISO-SM3], and also been described by 114 [GBT.32905-2016]. 116 1.2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119, BCP 14 121 [RFC2119] and indicate requirement levels for compliant TLSv1.3 122 implementations. 124 2. Proposed Cipher Suites 126 The cipher suites defined here have the following identifiers: 128 CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 }; 129 CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 }; 131 To accomplish a TLSv1.3 handshake, more objects have been introduced 132 along with the cipher suites as follows. 134 The SM2 signature algorithm and SM3 hash function used in the 135 Signature Algorithm extension defined in appendix-B.3.1.3 of 136 [RFC8446]: 138 SignatureScheme sm2sig_sm3 = { 0x0708 }; 140 The SM2 elliptic curve ID used in the Supported Groups extension 141 defined in appendix-B.3.1.4 of [RFC8446]: 143 NamedGroup curveSM2 = { 41 }; 145 3. Cipher Suites Definitions 147 3.1. TLS Versions 149 The only capable version for the new cipher suites defined in this 150 document is TLSv1.3. Implementations of this document MUST NOT apply 151 these cipher suites into any TLS protocols that have an older version 152 than 1.3. 154 3.2. Authentication 156 3.2.1. SM2 Signature Scheme 158 All cipher suites defined in this document use SM2 signature 159 algorithm as the authentication method when doing a TLSv1.3 160 handshake. 162 SM2 signature is defined in [ISO-SM2]. In general, SM2 is a 163 signature algorithm based on elliptic curves. SM2 signature 164 algorithm uses a fixed elliptic curve parameter set defined in 165 [GBT.32918.5-2016]. This curve has the name curveSM2 and IANA is 166 requested to assign a value for it. Unlike other elliptic curve 167 based public key algorithm like ECDSA, SM2 cannot select other 168 elliptic curves in practice, but it's allowed to write test cases by 169 using other elliptic curve parameter sets for SM2, take Annex F.14 of 170 [ISO-SM2] as a reference. 172 Implementations of the cipher suites defined in this document SHOULD 173 conform to what [GBT.32918.5-2016] requires, that is to say, the only 174 valid elliptic curve parameter for SM2 signature algorithm (a.k.a 175 curveSM2) is defined as follows: 177 curveSM2: a prime field of 256 bits 179 y^2 = x^3 + ax + b 181 p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 182 FFFFFFFF 00000000 FFFFFFFF FFFFFFFF 183 a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 184 FFFFFFFF 00000000 FFFFFFFF FFFFFFFC 185 b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 186 F39789F5 15AB8F92 DDBCBD41 4D940E93 187 n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 188 7203DF6B 21C6052B 53BBF409 39D54123 189 Gx = 32C4AE2C 1F198119 5F990446 6A39C994 190 8FE30BBF F2660BE1 715A4589 334C74C7 191 Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153 192 D0A9877C C62A4740 02DF32E5 2139F0A0 194 SM2 signature algorithm requests an identifier value when generate 195 the signature, as well as when verifying an SM2 signature. 196 Implementations of this document MUST use the following ASCII string 197 value as the SM2 identifier when doing a TLSv1.3 key exchange: 199 TLSv1.3+GM+Cipher+Suite 201 Except if either a client or a server needs to verify the peer's SM2 202 certificate contained in the Certificate message, the following ASCII 203 string value SHOULD be used as the SM2 identifier according to 204 [GMT.0009-2012]: 206 1234567812345678 208 In the octet presentation, it should be: 210 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 211 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38 213 In practice, the SM2 identifier used in a certificate signature 214 depends on the CA who signs that certificate. CAs may choose other 215 values rather than the one mentioned above. Implementations of this 216 document SHOULD confirm this information by themselves. 218 3.3. Key Exchange 220 3.3.1. Hello Messages 222 The new cipher suites defined in this document update the key 223 exchange information in the Hello messages. Implementations of these 224 new ciphers suites MUST conform to the new requirements. 226 3.3.1.1. ClientHello 228 A TLSv1.3 client is REQUIRED to include the new cipher suites in its 229 'cipher_suites' array of the ClientHello structure defined in 230 Section 4.1.2 of [RFC8446]. 232 Other requirements on the extensions of ClientHello message are: 234 o For supported_groups extension, 'curveSM2' MUST be included; 236 o For signature_algorithms extension, 'sm2sig_sm3' MUST be included; 238 o For signature_algorithms_cert extension (if presented), 239 'sm2sig_sm3' MUST be included; 241 o For key_share extension, a KeyShareEntry with SM2 related values 242 MUST be added if the client wants to start a TLSv1.3 key 243 negotiation using SM cipher suites. 245 3.3.1.2. ServerHello 247 If a TLSv1.3 server receives a ClientHello message containing the new 248 cipher suites defined in this document, it MAY choose to use the new 249 cipher suites. If so, then the server MUST put one of the new cipher 250 suites defined in this document into its ServerHello's 251 'cipher_suites' array and eventually sends it to the client side. 253 The following extensions MUST conform to the new requirements: 255 o For key_share extension, a KeyShareEntry with SM2 related values 256 MUST be added if the server wants to start a TLSv1.3 key 257 negotiation using SM cipher suites. 259 3.3.2. CertificateRequest 261 If a CertificateRequest message is sent by the server to require the 262 client to send its certificate for authentication purpose, the 263 following requirements MUST be fulfilled: 265 o The only valid signature algorithm present in 266 'signature_algorithms' extension MUST be 'sm2sig_sm3'. That is to 267 say, if server finally chooses to use a SM cipher suite, the 268 signature algorithm for client's certificate SHOULD only be SM2 269 and SM3 capable ones. 271 3.3.3. Certificate 273 When server sends the Certificate message which contains the server 274 certificate to the client side, several new rules are added that will 275 affect the certificate selection: 277 o The public key in the certificate MUST be a valid SM2 public key. 279 o The signature algorithm used by the CA to sign current certificate 280 MUST be sm2sig_sm3. 282 o The certificate MUST be capable for signing, e.g., the 283 digitalSignature bit of X.509's Key Usage extension is set. 285 3.3.4. CertificateVerify 287 In the certificateVerify message, the signature algorithm MUST be 288 sm2sig_sm3, indicating the hash function MUST be SM3 and the 289 signature algorithm MUST be SM2 signature algorithm. 291 3.4. Key Scheduling 293 As described in Section 1.1, SM2 is actually a set of cryptographic 294 algorithms including one key exchange protocol which defines methods 295 such as key derivation function, etc. In this document, SM2 key 296 exchange protocol is not introduced and SHALL NOT be used in the key 297 exchange steps defined in Section 3.3. Implementations of this 298 document SHOULD always conform to what TLSv1.3 [RFC8446] and its 299 successors require about the key derivation and related methods. 301 3.5. Cipher 303 The new cipher suites introduced in this document add two new AEAD 304 encryption algorithms, AEAD_SM4_GCM and AEAD_SM4_CCM, which stand for 305 SM4 cipher in Galois/Counter mode and SM4 cipher [GBT.32907-2016] in 306 Counter with CBC-MAC mode, respectively. 308 This section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AEAD 309 algorithms in a style of what [RFC5116] has used to define AEAD 310 ciphers based on AES cipher. 312 3.5.1. AEAD_SM4_GCM 314 The AEAD_SM4_GCM authenticated encryption algorithm works as 315 specified in [GCM], using SM4 as the block cipher, by providing the 316 key, nonce, and plaintext, and associated data to that mode of 317 operation. An authentication tag conformed to what Section 5.2 of 318 TLSv1.3 [RFC8446] requires is used, which in details SHOULD be 319 constructed by the TLS record header. The AEAD_SM4_GCM ciphertext is 320 formed by appending the authentication tag provided as an output to 321 the GCM encryption operation to the ciphertext that is output by that 322 operation. The input and output lengths are as follows: 324 K_LEN is 16 octets, 326 P_MAX is 2^36 - 31 octets, 328 A_MAX is 2^61 - 1 octets, 330 N_MIN and N_MAX are both 12 octets, and 332 C_MAX is 2^36 - 15 octets. 334 To generate the nonce, implementations of this document MUST conform 335 to what TLSv1.3 specifies (See [RFC8446], Section 5.3). 337 A security analysis of GCM is available in [MV04]. 339 3.5.2. AEAD_SM4_CCM 341 The AEAD_SM4_CCM authenticated encryption algorithm works as 342 specified in [CCM], using SM4 as the block cipher, by providing the 343 key, nonce, associated data, and plaintext to that mode of operation. 344 The formatting and counter generation function are as specified in 345 Appendix A of that reference, and the values of the parameters 346 identified in that appendix are as follows: 348 the nonce length n is 12, 350 the tag length t is 16, and 352 the value of q is 3. 354 An authentication tag conformed to what Section 5.2 of TLSv1.3 355 [RFC8446] requires is used, which in details SHOULD be constructed by 356 the TLS record header. The AEAD_SM4_CCM ciphertext is formed by 357 appending the authentication tag provided as an output to the CCM 358 encryption operation to the ciphertext that is output by that 359 operation. The input and output lengths are as follows: 361 K_LEN is 16 octets, 363 P_MAX is 2^24 - 1 octets, 365 A_MAX is 2^64 - 1 octets, 367 N_MIN and N_MAX are both 12 octets, and 369 C_MAX is 2^24 + 15 octets. 371 To generate the nonce, implementations of this document MUST conform 372 to what TLSv1.3 specifies (See [RFC8446], Section 5.3). 374 A security analysis of CCM is available in [J02]. 376 3.6. Hash 378 SM3 is defined by ISO as [ISO-SM3]. During a TLSv1.3 handshake with 379 SM cipher suites, the hash function is REQUIRED to be SM3. 380 Implementations MUST use SM3 for digest, key derivation, Transcript- 381 Hash and other purposes during a TLSv1.3 key exchange process. 383 4. IANA Considerations 385 IANA has assigned the values {0x00, 0xC6} and {0x00, 0xC7} with the 386 names TLS_SM4_GCM_SM3, TLS_SM4_CCM_SM3, to the "TLS Cipher Suite" 387 registry with this document as reference, as shown below. 389 +-----------+-----------------+---------+-------------+-----------+ 390 | Value | Description | DTLS-OK | Recommended | Reference | 391 +-----------+-----------------+---------+-------------+-----------+ 392 | 0x00,0xC6 | TLS_SM4_GCM_SM3 | No | No | this RFC | 393 | | | | | | 394 | 0x00,0xC7 | TLS_SM4_CCM_SM3 | No | No | this RFC | 395 +-----------+-----------------+---------+-------------+-----------+ 397 IANA has assigned the value 0x0708 with the name sm2sig_sm3, to the 398 "TLS SignatureScheme" registry, as shown below. 400 +--------+-------------+---------+-------------+-----------+ 401 | Value | Description | DTLS-OK | Recommended | Reference | 402 +--------+-------------+---------+-------------+-----------+ 403 | 0x0708 | sm2sig_sm3 | No | No | this RFC | 404 +--------+-------------+---------+-------------+-----------+ 406 IANA has assigned the value 41 with the name curveSM2, to the "TLS 407 Supported Groups" registry, as shown below. 409 +-------+-------------+---------+-------------+-----------+ 410 | Value | Description | DTLS-OK | Recommended | Reference | 411 +-------+-------------+---------+-------------+-----------+ 412 | 41 | curveSM2 | No | No | this RFC | 413 +-------+-------------+---------+-------------+-----------+ 415 5. Security Considerations 417 At the time of writing this draft, there are no known weak keys for 418 SM cryptographic algorithms SM2, SM3 and SM4, and no security problem 419 has been found on those algorithms. 421 o The cipher suites described in this document _MUST NOT_ be used 422 with TLSv1.2 or earlier. 424 6. References 426 6.1. Normative References 428 [CCM] Dworkin, M, ., "NIST Special Publication 800-38C: The CCM 429 Mode for Authentication and Confidentiality", May 2004, 430 . 433 [GCM] Dworkin, M, ., "NIST Special Publication 800-38D: 434 Recommendation for Block Cipher Modes of Operation: 435 Galois/Counter Mode (GCM) and GMAC.", November 2007, 436 . 439 [ISO-SM2] International Organization for Standardization, "IT 440 Security techniques -- Digital signatures with appendix -- 441 Part 3: Discrete logarithm based mechanisms", ISO ISO/IEC 442 14888-3:2018, November 2018, 443 . 445 [ISO-SM3] International Organization for Standardization, "IT 446 Security techniques -- Hash-functions -- Part 3: Dedicated 447 hash-functions", ISO ISO/IEC 10118-3:2018, October 2018, 448 . 450 [ISO-SM4] International Organization for Standardization, "IT 451 Security techniques -- Encryption algorithms -- Part 3: 452 Block ciphers", ISO ISO/IEC 18038-3:2010, December 2010, 453 . 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 460 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 461 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 462 . 464 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 465 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 466 . 468 6.2. Informative References 470 [GBT.32905-2016] 471 Standardization Administration of China, "Information 472 security technology --- SM3 cryptographic hash algorithm", 473 GB/T 32905-2016, March 2017, . 476 [GBT.32907-2016] 477 Standardization Administration of China, "Information 478 security technology --- SM4 block cipher algorithm", GB/ 479 T 32907-2016, March 2017, . 482 [GBT.32918.2-2016] 483 Standardization Administration of China, "Information 484 security technology --- Public key cryptographic algorithm 485 SM2 based on elliptic curves --- Part 2: Digital signature 486 algorithm", GB/T 32918.2-2016, March 2017, 487 . 490 [GBT.32918.5-2016] 491 Standardization Administration of China, "Information 492 security technology --- Public key cryptographic algorithm 493 SM2 based on elliptic curves --- Part 5: Parameter 494 definition", GB/T 32918.5-2016, March 2017, 495 . 498 [GMT.0009-2012] 499 State Cryptography Administration of China, "SM2 500 cryptography algorithm application specification", GM/ 501 T 0009-2016, November 2012, . 504 [J02] Jonsson, J, ., "On the Security of CTR + CBC-MAC", 2002, < 505 http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/propo 506 sedmodes/ccm/ccm-ad1.pdf>. 508 [MV04] Viega, McGrew,., "The Security and Performance of the 509 Galois/Counter Mode (GCM)", December 2004, 510 . 512 Appendix A. Contributors 514 Wuqiong Pan 515 Ant Financial 516 wuqiong.pwq@antfin.com 518 Qin Long 519 Ant Financial 520 zhuolong.lq@antfin.com 522 Kepeng Li 523 Ant Financial 524 kepeng.lkp@antfin.com 526 Appendix B. Acknowledgments 528 To be determined. 530 Author's Address 532 Paul Yang 533 Ant Financial 534 No. 77 Xueyuan Road 535 Hangzhou 310000 536 China 538 Phone: +86-571-2688-8888 539 Fax: +86-571-8643-2811 540 Email: kaishen.yy@antfin.com