idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 31 characters in excess of 72. ** The abstract seems to contain references ([RFC7250]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2018) is 2240 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 7250' is mentioned on line 311, but not defined == Missing Reference: 'RFC 6507' is mentioned on line 208, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' ** Downref: Normative reference to an Informational RFC: RFC 5091 ** Downref: Normative reference to an Informational RFC: RFC 6507 ** Downref: Normative reference to an Informational RFC: RFC 6508 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Wang, Ed. 3 Internet-Draft Y. Yang 4 Intended status: Standards Track X. Kang 5 Expires: September 2, 2018 Huawei Technology Pte. Ltd. 6 March 1, 2018 8 Using Identity as Raw Public Key in Transport Layer Security (TLS) and 9 Datagram Transport Layer Security (DTLS) 10 draft-wang-tls-raw-public-key-with-ibc-00 12 Abstract 14 This document specifies the use of identity as a raw public key in 15 Transport Layer Security (TLS) and Datagram Transport Layer Security 16 (DTLS). The protocol procedures are kept unchanged, but cipher 17 suites are extended to support Identity-based signature (IBS). The 18 example OID tables in the RFC 7250 [RFC7250] are expanded with OIDs 19 specific to the IBC-based signature algorithms. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 2, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Extension of RAW Public Key to IBC-based Identity . . . . . . 4 58 4. Parameters for Signature Verification . . . . . . . . . . . . 5 59 5. New Key Exchange Algorithms and Cipher Suites . . . . . . . . 6 60 6. TLS Client and Server Handshake Behavior . . . . . . . . . . 6 61 6.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7 62 6.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7 63 6.3. Client Authentication . . . . . . . . . . . . . . . . . . 8 64 6.4. Server Authentication . . . . . . . . . . . . . . . . . . 8 65 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. TLS Client and Server Use ECCSI . . . . . . . . . . . . . 9 67 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 11.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 DISCLAIMER: This is a personal draft and has not yet seen significant 80 security analysis. 82 Traditionally, TLS/DTLS client and server exchange public keys 83 endorsed by PKIX [PKIX] certificates. It is considered complicate 84 and may cause security weaknesses with the use of PKIX certificates 85 [Defeating-SSL]. To simplify certificates exchange, using RAW public 86 key in TLS/DTLS has been specified in RFC 7250. That is, instead of 87 transmitting a full certificate in the TLS messages, only public keys 88 are exchanged between client and server. However, an out-of-band 89 mechanism for public key and identity binding is assumed. 91 Recently, 3GPP has adopted the EAP authentication framework for 5G 92 and EAP-TLS is considered as one of candidate authentication methods 93 for private networks, especially for networks with a large number of 94 IOT devices. For IOT networks, TLS/DTLS with RAW public key is 95 particularly attractive, but binding identities with public keys 96 might be challenging. The cost to maintain a large table for 97 identity and public key mapping at server side incurrs additional 98 maintenance cost. e.g. devices have to pre-register to the server. 100 To simplify the binding between the public key and the entity 101 presenting the public key, a better way could be using Identity-Based 102 Cryptography(IBC), such as ECCSI public key specified in RFC 6507, 103 for authentication. Different from X.509 certificates and raw public 104 keys, a public key in IBC takes the form of the entity's identity. 105 This helps eliminate the necessity of binding between a public key 106 and the entity presenting the public key. 108 The concept of IBC was first proposed by Adi Shamir in 1984. As a 109 special class of public key cryptography, IBC uses a user's identity 110 as public key, avoiding the hassle of public key certification in 111 public key cryptosystems. IBC broadly includes IBE (Identity-based 112 Encryption) and IBS (Identity-based Signature). For an IBC system to 113 work, there exists a trusted third party, PKG (private key generator) 114 responsible for issuing private keys to the users. In particular, 115 the PKG has in possession a pair of Master Public Key and Master 116 Secret Key; a private key is generated based on the user's identity 117 by using the Master Secret key, while the Master Public key is used 118 together with the user's identities for encryption (in case of IBE) 119 and signature verification ( in case of IBS). 121 A number of IBE and IBS algorithms have been standardized by 122 different standardization bodies, such as IETF, IEEE, and ISO/IEC. 123 For example, IETF has specified several RFCs such as RFC 5091 124 [RFC5091], RFC 6507 [RFC6507] and RFC6508 [RFC6508] for both IBE and 125 IBS algorithms. ISO/JTC and IEEE also have a few standards on IBC 126 algorithms. 128 RFC 7250 has specified the use of raw public key with TLS/DTLS 129 protocol. Example OIDs for RSA, DSA, ECDSA algorithms have been 130 given. However, supporting of IBS algorithms has not been included 131 therein. Since IBC algorithms are efficient in public key 132 transmission and also eliminate the binding between public keys and 133 identities, in this document, an amendment to RFC 7250 is added for 134 supporting IBS algorithms. 136 The document is orgranized as follows: Section 3 explains the use of 137 identity as raw public key when IBS algorithms are chosen as the 138 underlying digital signature mechanism, and example OIDs for IBS 139 algorithms are given. Section 4 discusses provision of the global 140 parameters used with the IBS algorithms. Section 5 discusses the 141 security considerations. 143 2. Terms 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 3. Extension of RAW Public Key to IBC-based Identity 151 In RFC 7250, a new Certificate structure is defined with two types, 152 X.509 and RawPublicKey. When raw public key is used in TLS, 153 RawPublicKey type is selected and a data strucutre 154 subjectPublicKeyInfo is used to specify the raw public key and its 155 cryptographic algorithm. Within the subjectPublicKeyInfo structure, 156 two fields, algorithm and parameters, are defined. The algorithm 157 specifies the cryptographic algorithm used with raw public key, which 158 is represented by an object Identifiers (OID); and the parameters 159 field provides necessary parameters associated with the algorithm. 161 subjectPublicKeyInfo ::= SEQUENCE { 162 algorithm AlgorithmIdentifier, 163 subjectPublicKey BIT STRING } 165 AlgorithmIdentifier ::= SEQUENCE { 166 algorithm OBJECT IDENTIFIER, 167 parameters ANY DEFINED BY algorithm OPTIONAL } 169 Figure 1: SubjectECCSIPublicKeyInfo ASN.1 Structure 171 When using an IBS algorithm, an identity is used as raw public key, 172 which can be coverted to an OCTET string. Therefore, the Certificate 173 and subjectPublicKey structure can be reused without changes. No OID 174 for an IBS algorithm has been given as examples in [RFC 7250]. It is 175 known that there are a few standardized IBS algorithms, therefore, in 176 what follows several exmaples of OIDs for IBS algorithms are given. 178 The OIDs for some IBC-based Signature algorithmsare listed in the 179 following table. 181 +----------------------+--------------------+-----------------------+ 182 | Key Type | Document | OID | 183 +----------------------+--------------------+-----------------------+ 184 | ISO/IEC 14888-3 | ISO/IEC 14888-3: | 1.0.14888.3.0.7 | 185 | ibs-1 | IBS-1 mechansim | | 186 | | (Identity-Based | | 187 | | Signature) | | 188 +----------------------+--------------------+-----------------------+ 189 | ISO/IEC 14888-3 | ISO/IEC 14888-3: | 1.0.14888.3.0.8 | 190 | ibs-2 | IBS-2 mechansim | | 191 | | (Identity-Based | | 192 | | Signature) | | 193 +----------------------+--------------------+-----------------------+ 194 | SM9-1 Digital | SM9-1 Digital | 1.2.156.10197.1.302.1 | 195 | Signature Algorithm | Signature | | 196 | | Algorithm | | 197 +----------------------+--------------------+-----------------------+ 198 | Elliptic Curve-Based | Section 5.2 in RFC | 1.3.6.1.5.x (need to | 199 | Signatureless For | 6507 | apply) | 200 | Identitiy-based | | | 201 | Encryption (ECCSI) | | | 202 +----------------------+--------------------+-----------------------+ 204 Table 1: Algorithm Object Identifiers 206 In particular, ISO/IEC 14888-3 specifies two IBS algorithms, IBS-1 207 and IBS-2. The ECCSI is an IBS algorithm that is specified in IETF 208 [RFC 6507]. SM9-1 is a Chinese standard for an IBS algorithm. 209 Recently it has been accepted by ISO/IEC 14888-3 211 How are the paramters of AlgorithmIdentifier specified? 213 4. Parameters for Signature Verification 215 Using IBS algorithm in TLS/DTLS for raw public key exempts client and 216 server from public key certification and identity binding. This is 217 achieved by checking an entity's signatures and its identity against 218 the master public key of its PKG. With IBS algorithm, a PKG 219 generates private keys for entities based on their identities. 220 Global parameters such as PKG's Master Public Key (MPK) need be 221 provisioned to both client and server side. These parameters are not 222 user specific, but PKG specific. 224 For a client, PKG specific parameters can be provioned, at the time 225 PKG provisons the private key to the client. For the server, how to 226 get the PKG specific parameters provisioned is out of the scope of 227 this document, and it is depolyment dependent. 229 5. New Key Exchange Algorithms and Cipher Suites 231 To support identity as raw public key, new key exchange algorithms 232 corresponding to the IBS algorithms need to be defined. The signing 233 capability of the IBS algorithms is to be exploited, thus existing 234 key exchange algorithms making use of ephemeral DH are extended to 235 accomodate the support of the IBS algorithms. Considering the 236 performance and the compatibility with the use of ECDSA in TLS (see 237 RFC 4492), this specification proposes to support the IBS algorithm, 238 ECCSI, defined in RFC 6507 [RFC6507]. As a reult, the table below 239 summarizes the new key exchange algorithm, which mimics ECDHE_ECDSA 240 (see RFC 4492). 242 +-------------------------+---------------------------------------+ 243 | Key Exchange Algorithm | Description | 244 +-------------------------+---------------------------------------+ 245 | ECDHE_ECCSI | Ephemeral ECDH with ECCSI signatures | 246 +-------------------------+---------------------------------------+ 248 Table 2: Algorithm Object Identifiers 250 Note: The specification of ECDHE_ECCSI can follow ECHDE_ECDSA by 251 substituting ECDSA with ECCSI. The detailed specification will be 252 provided in the future 254 Note: Other key exchange algorithm with other IBS algorithm may be 255 added in the future. 257 Accordingly, below defines the new cipher suites that use the above 258 new key exchange algorithms. 260 CipherSuite TLS_ECDHE_ECCSI_WITH_AES_128_CBC_SHA256 = { 0xC0, 0x80 } 262 CipherSuite TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256 = { 0xC0, 0x8A } 264 6. TLS Client and Server Handshake Behavior 266 The handshake between the TLS client and server follows that defined 267 in RFC 7250 [RFC7250], but with the support of the new key exchange 268 algorithm and cipher suites due to the introducton of ECCSI. The 269 high-level message exchange in the below figure shows TLS handshake 270 using raw public keys, where the client_certificate_type and 271 server_certificate_type extensions added to the client and server 272 hello messages (see Section 4 of RFC 7250). 274 client_hello, 275 client_certificate_type, 276 server_certificate_type -> 278 <- server_hello, 279 client_certificate_type, 280 server_certificate_type, 281 certificate, 282 server_key_exchange, 283 certificate_request, 284 server_hello_done 285 certificate, 286 client_key_exchange, 287 certificate_verify, 288 change_cipher_spec, 289 finished -> 291 <- change_cipher_spec, 292 finished 294 Application Data <-------> Application Data 296 Figure 2: Basic Raw Public Key TLS Exchange 298 6.1. Client Hello 300 If the TLS client wants to use ECCSI, then the 301 client_certificate_type is set to be RawPublicKey. If the TLS client 302 prefers accepting the server to use ECCSI, then the the 303 server_certificate_type is set to be RawPublicKey, and the 304 CipherSuite element of the client hello message is set to be the 305 cipher suite(s) supporting ECCSI. 307 6.2. Server Hello 309 If the server receives a client hello that contains the 310 client_certificate_type extension and/or the server_certificate_type 311 extension, then three outcomes are possible [RFC 7250]: 313 1. The server does not support the extension defined in this 314 document. In this case, the server returns the server hello without 315 the extensions defined in this document. 317 2. The server supports the extension defined in this document, but 318 it does not have any certificate type in common with the client. 319 Then, the server terminates the session with a fatal alert of type 320 "unsupported_certificate". 322 3. The server supports the extensions defined in this document and 323 has at least one certificate type in common with the client. In this 324 case, the processing rules described below are followed. 326 The client_certificate_type extension in the client hello indicates 327 the certificate types the client is able to provide to the server, 328 when requested using a certificate_request message. If the TLS 329 server wants to request a certificate from the client (via the 330 certificate_request message), it MUST include the 331 client_certificate_type extension in the server hello. This 332 client_certificate_type extension in the server hello then indicates 333 the type of certificates the client is requested to provide in a 334 subsequent certificate payload. The value conveyed in the 335 client_certificate_type extension MUST be selected from one of the 336 values provided in the client_certificate_type extension sent in the 337 client hello. The server MUST also include a certificate_request 338 payload in the server hello message. 340 If the server does not send a certificate_request payload or none of 341 the certificates supported by the client match the server-supported 342 certificate types, then the client_certificate_type payload in the 343 server hello MUST be omitted. 345 If the server_certificate_type extension in the client hello is set 346 be RawPublicKey and the CipherSuite element of the client hello 347 message is set to be the cipher suite(s) supporting ECCSI, and the 348 server chooses to use ECCSI, then the TLS server MUST place the 349 SubjectPublicKeyInfo structure containing the ECCSI key into the 350 Certificate payload. With the server_certificate_type extension in 351 the server hello, the TLS server indicates the certificate type 352 carried in the Certificate payload. 354 6.3. Client Authentication 356 When the TLS server has specified RawPublicKey as the 357 client_certificate_type, and the TLS client sends the 358 SubjectPublicKeyInfo structure containing an ECCSI key in the client 359 certificate, authentication of the TLS client to the TLS server is 360 achieved. 362 6.4. Server Authentication 364 When the TLS server has specified RawPublicKey as the 365 server_certificate_type, and sends the SubjectPublicKeyInfo structure 366 containing an ECCSI key in the server certificate, authentication of 367 the TLS server to the TLS client is achieved. 369 7. Examples 371 In the following, examples of handshake exchages using ECCSI under 372 RawPublicKey are illustrated. 374 7.1. TLS Client and Server Use ECCSI 376 In this example, both the TLS client and the TLS server use ECCSI, 377 and they are restricted in that they can only process ECCSI keys. As 378 a result, the TLS client sets the server_certificate_type extension 379 to be raw public key while omits the client_certificate_type 380 extension; in addition, the TLS client sets the ciphersuites in the 381 client hellow messag to be TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256, 382 as shown in (1). 384 When the TLS server receives the client hello, it processes the 385 message. Since it has an ECCSI key, it indicates in (2) that it 386 agreed to use ECCSI and provided an ECCSI key by placing the 387 SubjectPublicKeyInfo structure into the Certificate payload back to 388 the client (3). The TLS server demands client authentication, and 389 therefore includes a certificate_request (4). The 390 client_certificate_type payload in (5) indicates that the TLS server 391 accepts a raw public key. The TLS client, which has an ECCSI key, 392 returns its ECCSI key in the Certificate payload (6) to the server. 394 client_hello, 395 cipher_suites=(TLS_ECDHE_ECCSI_WITH_AES_256_CBC_SHA256) // (1) 396 client_certificate_type=(RawPublicKey) // (1) 397 server_certificate_type=(RawPublicKey) // (1) 398 -> 399 <- server_hello, 400 server_certificate_type=RawPublicKey // (2) 401 certificate, // (3) 402 client_certificate_type=RawPublicKey // (5) 403 certificate_request, // (4) 404 server_key_exchange, 405 server_hello_done 407 certificate, // (6) 408 client_key_exchange, 409 change_cipher_spec, 410 finished -> 412 <- change_cipher_spec, 413 finished 415 Application Data <-------> Application Data 417 Figure 3: Basic Raw Public Key TLS Exchange 419 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 421 This example combines the uses of an ECCSI key and an X.509 422 certificate. The TLS client uses an ECCSI key for client 423 authentication, and the TLS server provides an X.509 certificate. 424 This exchange starts with the client indicating its ability to 425 process a raw public key, or an X.509 certificate, if provided by the 426 server. It prefers a raw public key, since the RawPublicKey value 427 precedes the other value in the server_certificate_type vector. 428 Furthermore, the client indicates that it has a raw public key for 429 client-side authentication (see (1)). The server chooses to provide 430 its X.509 certificate in (3) and indicates that choice in (2). For 431 client authentication, the server indicates in (4) that it has 432 selected the raw public key format and requests a certificate from 433 the client in (5). The TLS client provides an ECSSI key in (6) after 434 receiving and processing the TLS server hello message. 436 client_hello, 437 cipher_suites=(TLS_ECDHE_ECSSI_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA256) // (1) 438 server_certificate_type=(RawPublicKey, X.509) // (1) 439 client_certificate_type=(RawPublicKey) // (1) 440 -> 441 <- server_hello, 442 server_certificate_type=X.509 // (2) 443 certificate, // (3) 444 client_certificate_type=RawPublicKey // (4) 445 certificate_request, // (5) 446 server_key_exchange, 447 server_hello_done 448 certificate, // (6) 449 client_key_exchange, 450 change_cipher_spec, 451 finished -> 453 <- change_cipher_spec, 454 finished 456 Application Data <-------> Application Data 458 Figure 4: Basic Raw Public Key TLS Exchange 460 8. Security Considerations 462 Using IBS-enabled raw public key in TLS/DTLS will not change the 463 handshake flows of TLS, so the security of the resulting protocol 464 rests on the security of the used IBS algorithms. The example IBS 465 algorithms mentioned above are all standardized and open, and thus 466 the security of these algorithms is supposed to have gone through 467 wide scrutinization. 469 9. IANA Considerations 471 This document describes new OIDs for IBS algorithms (Section 4), new 472 key exchange algorithm (Section 5) and the corresponding new cipher 473 suites (Section 5). 475 10. Acknowledgements 477 11. References 479 11.1. Normative References 481 [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 482 Housley, R., and W. Polk, "Internet X.509 Public Key 483 Infrastructure Certificate and Certificate Revocation 484 List(CRL) Profile", June 2008. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 492 Standard (IBCS) #1: Supersingular Curve Implementations of 493 the BF and BB1 Cryptosystems", RFC 5091, 494 DOI 10.17487/RFC5091, December 2007, 495 . 497 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 498 Signatures for Identity-Based Encryption (ECCSI)", 499 RFC 6507, DOI 10.17487/RFC6507, February 2012, 500 . 502 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 503 RFC 6508, DOI 10.17487/RFC6508, February 2012, 504 . 506 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 507 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 508 Transport Layer Security (TLS) and Datagram Transport 509 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 510 June 2014, . 512 11.2. Informative References 514 [Defeating-SSL] 515 Marlinspike, M.,, "New Tricks for Defeating SSL in 516 Practice", Feb 2009, 517 . 521 Appendix A. Examples 523 Authors' Addresses 524 Haiguang Wang (editor) 525 Huawei Technology Pte. Ltd. 526 20 Secience Park Road, #3-30/31 527 Singapore 117687 528 SG 530 Phone: +65 6825 4200 531 Email: wang.haiguang1@huawei.com 533 Yanjiang Yang 534 Huawei Technology Pte. Ltd. 535 20 Secience Park Road, #3-30/31 536 Singapore 117687 537 SG 539 Phone: +65 6825 4200 540 Email: yang.yanjiang@huawei.com 542 Xin Kang 543 Huawei Technology Pte. Ltd. 544 20 Secience Park Road, #3-30/31 545 Singapore 117687 546 SG 548 Phone: +65 6825 4200 549 Email: xin.kang@huawei.com