idnits 2.17.1 draft-yang-tls-tls13-sm-suites-00.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 (August 15, 2019) is 1715 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 August 15, 2019 5 Expires: February 16, 2020 7 SM Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 8 draft-yang-tls-tls13-sm-suites-00 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 February 16, 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 . . . . . . . . . . . . . . . . . . . . . 6 62 3.3.4. CertificateVerify . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 6.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 74 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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 = {TBD1, TBD1}; 84 CipherSuite TLS_SM4_CCM_SM3 = {TBD2, TBD2}; 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]. SM4 is a block cipher and now is being standardized by 110 ISO to ISO/IEC 18033-3:2010 [ISO-SM4]. SM3 is a hash function which 111 produces an output of 256 bits. SM3 has already been accepted by ISO 112 in ISO/IEC 10118-3:2018 [ISO-SM3]. 114 1.2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119, BCP 14 119 [RFC2119] and indicate requirement levels for compliant TLSv1.3 120 implementations. 122 2. Proposed Cipher Suites 124 The cipher suites defined here have the following identifiers: 126 CipherSuite TLS_SM4_GCM_SM3 = { TBD1, TBD1 }; 127 CipherSuite TLS_SM4_CCM_SM3 = { TBD2, TBD2 }; 129 To accomplish a TLSv1.3 handshake, more objects have been introduced 130 along with the cipher suites as follows. 132 The SM2 signature algorithm and SM3 hash function used in the 133 Signature Algorithm extension defined in appendix-B.3.1.3 of 134 [RFC8446]: 136 SignatureScheme sm2sig_sm3 = { TBD3 }; 138 The SM2 elliptic curve ID used in the Supported Groups extension 139 defined in appendix-B.3.1.4 of [RFC8446]: 141 NamedGroup curveSM2 = { TBD4 }; 143 3. Cipher Suites Definitions 145 3.1. TLS Versions 147 The only capable version for the new cipher suites defined in this 148 document is TLSv1.3. Implementations of this document MUST NOT apply 149 these cipher suites into any TLS protocols that have an older version 150 than 1.3. 152 3.2. Authentication 154 3.2.1. SM2 Signature Scheme 156 All cipher suites defined in this document use SM2 signature 157 algorithm as the authentication method when doing a TLSv1.3 158 handshake. 160 SM2 signature is defined in [ISO-SM2]. In general, SM2 is a 161 signature algorithm based on elliptic curves. SM2 signature 162 algorithm uses a fixed elliptic curve parameter set defined in 163 [GBT.32918.5-2016]. This curve has the name curveSM2 and IANA is 164 requested to assign a value for it. Unlike other elliptic curve 165 based public key algorithm like ECDSA, SM2 cannot select other 166 elliptic curves in practice, but it's allowed to write test cases by 167 using other elliptic curve parameter sets for SM2, take Annex F.14 of 168 [ISO-SM2] as a reference. 170 Implementations of the cipher suites defined in this document SHOULD 171 conform to what [GBT.32918.5-2016] requires, that is to say, the only 172 valid elliptic curve parameter for SM2 signature algorithm (a.k.a 173 curveSM2) is defined as follows: 175 curveSM2: a prime field of 256 bits 177 y^2 = x^3 + ax + b 179 p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 180 FFFFFFFF 00000000 FFFFFFFF FFFFFFFF 181 a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 182 FFFFFFFF 00000000 FFFFFFFF FFFFFFFC 183 b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 184 F39789F5 15AB8F92 DDBCBD41 4D940E93 185 n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 186 7203DF6B 21C6052B 53BBF409 39D54123 187 Gx = 32C4AE2C 1F198119 5F990446 6A39C994 188 8FE30BBF F2660BE1 715A4589 334C74C7 189 Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153 190 D0A9877C C62A4740 02DF32E5 2139F0A0 192 SM2 signature algorithm requests an identifier value when generate 193 the signature, as well as when verifying an SM2 signature. 194 Implementations of this document MUST use the following ASCII string 195 value as the SM2 identifier when doing a TLSv1.3 key exchange: 197 TLSv1.3+GM+Cipher+Suite 199 Except if either a client or a server needs to verify the peer's SM2 200 certificate contained in the Certificate message, the following ASCII 201 string value SHOULD be used as the SM2 identifier according to 202 [GMT.0009-2012]: 204 1234567812345678 206 In practice, the SM2 identifier used in a certificate signature 207 depends on the CA who signs that certificate. CAs may choose other 208 values rather than the one mentioned above. Implementations of this 209 document SHOULD confirm this information by themselves. 211 3.3. Key Exchange 213 3.3.1. Hello Messages 215 The new cipher suites defined in this document update the key 216 exchange information in the Hello messages. Implementations of these 217 new ciphers suites MUST conform to the new requirements. 219 3.3.1.1. ClientHello 221 A TLSv1.3 client is REQUIRED to include the new cipher suites in its 222 'cipher_suites' array of the ClientHello structure defined in 223 Section 4.1.2 of [RFC8446]. 225 Other requirements on the extensions of ClientHello message are: 227 o For supported_groups extension, 'curveSM2' MUST be included; 229 o For signature_algorithms extension, 'sm2sig_sm3' MUST be included; 231 o For signature_algorithms_cert extension (if presented), 232 'sm2sig_sm3' MUST be included; 234 o For key_share extension, a KeyShareEntry with SM2 related values 235 MUST be added if the client wants to start a TLSv1.3 key 236 negotiation using SM cipher suites. 238 3.3.1.2. ServerHello 240 If a TLSv1.3 server receives a ClientHello message containing the new 241 cipher suites defined in this document, it MAY choose to use the new 242 cipher suites. If so, then the server MUST put one of the new cipher 243 suites defined in this document into its ServerHello's 244 'cipher_suites' array and eventually sends it to the client side. 246 The following extensions MUST conform to the new requirements: 248 o For key_share extension, a KeyShareEntry with SM2 related values 249 MUST be added if the server wants to start a TLSv1.3 key 250 negotiation using SM cipher suites. 252 3.3.2. CertificateRequest 254 If a CertificateRequest message is sent by the server to require the 255 client to send its certificate for authentication purpose, the 256 following requirements MUST be fulfilled: 258 o The only valid signature algorithm present in 259 'signature_algorithms' extension MUST be 'sm2sig_sm3'. That is to 260 say, if server finally chooses to use a SM cipher suite, the 261 signature algorithm for client's certificate SHOULD only be SM2 262 and SM3 capable ones. 264 3.3.3. Certificate 266 When server sends the Certificate message which contains the server 267 certificate to the client side, several new rules are added that will 268 affect the certificate selection: 270 o The public key in the certificate MUST be a valid SM2 public key. 272 o The signature algorithm used by the CA to sign current certificate 273 MUST be sm2sig_sm3. 275 o The certificate MUST be capable for signing, e.g., the 276 digitalSignature bit of X.509's Key Usage extension is set. 278 3.3.4. CertificateVerify 280 In the certificateVerify message, the signature algorithm MUST be 281 sm2sig_sm3, indicating the hash function MUST be SM3 and the 282 signature algorithm MUST be SM2 signature algorithm. 284 3.4. Key Scheduling 286 As described in Section 1.1, SM2 is actually a set of cryptographic 287 algorithms including one key exchange protocol which defines methods 288 such as key derivation function, etc. In this document, SM2 key 289 exchange protocol is not introduced and SHALL NOT be used in the key 290 exchange steps defined in Section 3.3. Implementations of this 291 document SHOULD always conform to what TLSv1.3 [RFC8446] and its 292 successors require about the key derivation and related methods. 294 3.5. Cipher 296 The new cipher suites introduced in this document add two new AEAD 297 encryption algorithms, AEAD_SM4_GCM and AEAD_SM4_CCM, which stand for 298 SM4 cipher in Galois/Counter mode and SM4 cipher in Counter with CBC- 299 MAC mode, respectively. 301 This section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AEAD 302 algorithms in a style of what [RFC5116] has used to define AEAD 303 ciphers based on AES cipher. 305 3.5.1. AEAD_SM4_GCM 307 The AEAD_SM4_GCM authenticated encryption algorithm works as 308 specified in [GCM], using SM4 as the block cipher, by providing the 309 key, nonce, and plaintext, and associated data to that mode of 310 operation. An authentication tag conformed to what Section 5.2 of 311 TLSv1.3 [RFC8446] requires is used, which in details SHOULD be 312 constructed by the TLS record header. The AEAD_SM4_GCM ciphertext is 313 formed by appending the authentication tag provided as an output to 314 the GCM encryption operation to the ciphertext that is output by that 315 operation. The input and output lengths are as follows: 317 K_LEN is 16 octets, 319 P_MAX is 2^36 - 31 octets, 321 A_MAX is 2^61 - 1 octets, 323 N_MIN and N_MAX are both 12 octets, and 325 C_MAX is 2^36 - 15 octets. 327 To generate the nonce, implementations of this document MUST conform 328 to what TLSv1.3 specifies (See [RFC8446], Section 5.3). 330 A security analysis of GCM is available in [MV04]. 332 3.5.2. AEAD_SM4_CCM 334 The AEAD_SM4_CCM authenticated encryption algorithm works as 335 specified in [CCM], using SM4 as the block cipher, by providing the 336 key, nonce, associated data, and plaintext to that mode of operation. 337 The formatting and counter generation function are as specified in 338 Appendix A of that reference, and the values of the parameters 339 identified in that appendix are as follows: 341 the nonce length n is 12, 343 the tag length t is 16, and 345 the value of q is 3. 347 An authentication tag conformed to what Section 5.2 of TLSv1.3 348 [RFC8446] requires is used, which in details SHOULD be constructed by 349 the TLS record header. The AEAD_SM4_CCM ciphertext is formed by 350 appending the authentication tag provided as an output to the CCM 351 encryption operation to the ciphertext that is output by that 352 operation. The input and output lengths are as follows: 354 K_LEN is 16 octets, 356 P_MAX is 2^24 - 1 octets, 358 A_MAX is 2^64 - 1 octets, 360 N_MIN and N_MAX are both 12 octets, and 362 C_MAX is 2^24 + 15 octets. 364 To generate the nonce, implementations of this document MUST conform 365 to what TLSv1.3 specifies (See [RFC8446], Section 5.3). 367 A security analysis of CCM is available in [J02]. 369 3.6. Hash 371 SM3 is defined by ISO as [ISO-SM3]. During a TLSv1.3 handshake with 372 SM cipher suites, the hash function is REQUIRED to be SM3. 373 Implementations MUST use SM3 for digest, key derivation, Transcript- 374 Hash and other purposes during a TLSv1.3 key exchange process. 376 4. IANA Considerations 378 IANA is requested to assign the values for TBD1 and TBD2 with the 379 names TLS_SM4_GCM_SM3, TLS_SM4_CCM_SM3, to the "TLS Cipher Suite" 380 registry with this document as reference, as shown below. 382 +-------+-----------------+---------+-----------+ 383 | Value | Description | DTLS-OK | Reference | 384 +-------+-----------------+---------+-----------+ 385 | TBD1 | TLS_SM4_GCM_SM3 | No | this RFC | 386 | | | | | 387 | TBD2 | TLS_SM4_CCM_SM3 | No | this RFC | 388 +-------+-----------------+---------+-----------+ 390 IANA is requested to assign the value for TBD3 with the name sm2sig, 391 to the "TLS SignatureScheme" registry, as shown below. 393 +-------+-------------+---------+-----------+ 394 | Value | Description | DTLS-OK | Reference | 395 +-------+-------------+---------+-----------+ 396 | TBD3 | sm2sig_sm3 | No | this RFC | 397 +-------+-------------+---------+-----------+ 399 IANA is requested to assign the value for TBD4 with the name 400 curveSM2, to the "TLS HashAlgorithm" registry, as shown below. 402 +-------+-------------+---------+-------------+-----------+ 403 | Value | Description | DTLS-OK | Recommended | Reference | 404 +-------+-------------+---------+-------------+-----------+ 405 | TBD4 | curveSM2 | No | No | this RFC | 406 +-------+-------------+---------+-------------+-----------+ 408 5. Security Considerations 410 At the time of writing this draft, there are no known weak keys for 411 SM cryptographic algorithms SM2, SM3 and SM4, and no security problem 412 has been found on those algorithms. 414 o The cipher suites described in this document _MUST NOT_ be used 415 with TLSv1.2 or earlier. 417 6. References 419 6.1. Normative References 421 [CCM] Dworkin, M, ., "NIST Special Publication 800-38C: The CCM 422 Mode for Authentication and Confidentiality", May 2004, 423 . 426 [GCM] Dworkin, M, ., "NIST Special Publication 800-38D: 427 Recommendation for Block Cipher Modes of Operation: 428 Galois/Counter Mode (GCM) and GMAC.", November 2007, 429 . 432 [ISO-SM2] International Organization for Standardization, "IT 433 Security techniques -- Digital signatures with appendix -- 434 Part 3: Discrete logarithm based mechanisms", ISO ISO/IEC 435 14888-3:2018, November 2018, 436 . 438 [ISO-SM3] International Organization for Standardization, "IT 439 Security techniques -- Hash-functions -- Part 3: Dedicated 440 hash-functions", ISO ISO/IEC 10118-3:2018, October 2018, 441 . 443 [ISO-SM4] International Organization for Standardization, "IT 444 Security techniques -- Encryption algorithms -- Part 3: 445 Block ciphers", ISO ISO/IEC 18038-3:2010, December 2010, 446 . 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, 450 DOI 10.17487/RFC2119, March 1997, 451 . 453 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 454 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 455 . 457 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 458 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 459 . 461 6.2. Informative References 463 [GBT.32918.5-2016] 464 Standardization Administration of China, "Information 465 security technology --- Public key cryptographic algorithm 466 SM2 based on elliptic curves --- Part 5: Parameter 467 definition", GB/T 32918.5-2016, March 2017, 468 . 471 [GMT.0009-2012] 472 State Cryptography Administration of China, "SM2 473 cryptography algorithm application specification", GM/ 474 T 0009-2016, November 2012, . 477 [J02] Jonsson, J, ., "On the Security of CTR + CBC-MAC", 2002, < 478 http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/propo 479 sedmodes/ccm/ccm-ad1.pdf>. 481 [MV04] Viega, McGrew,., "The Security and Performance of the 482 Galois/Counter Mode (GCM)", December 2004, 483 . 485 Appendix A. Contributors 487 Wuqiong Pan 488 Ant Financial 489 wuqiong.pwq@antfin.com 491 Qin Long 492 Ant Financial 493 zhuolong.lq@antfin.com 495 Kepeng Li 496 Ant Financial 497 kepeng.lkp@antfin.com 499 Appendix B. Acknowledgments 501 To be determined. 503 Author's Address 504 Paul Yang 505 Ant Financial 506 No. 77 Xueyuan Road 507 Hangzhou 310000 508 China 510 Phone: +86-571-2688-8888 511 Fax: +86-571-8643-2811 512 Email: kaishen.yy@antfin.com