idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-12.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 9 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 9, 2020) is 1478 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7250' is mentioned on line 491, but not defined == Missing Reference: 'RFC 8446' is mentioned on line 486, but not defined == Missing Reference: 'RFC 6507' is mentioned on line 104, but not defined == Missing Reference: 'RFC 5091' is mentioned on line 127, but not defined -- Looks like a reference, but probably isn't: '2' on line 293 == Missing Reference: 'RFC 5901' is mentioned on line 330, but not defined == Unused Reference: 'RFC2434' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'RFC5091' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'RFC5480' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'RFC6507' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC8216' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 817, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 3 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: Informational X. Kang 5 Expires: October 11, 2020 Huawei International Pte. Ltd. 6 Z. Cheng 7 Shenzhen Olym Info. Security Tech. Ltd. 8 M. Chen 9 China Mobile 10 April 9, 2020 12 Using Identity as Raw Public Key in Transport Layer Security (TLS) and 13 Datagram Transport Layer Security (DTLS) 14 draft-wang-tls-raw-public-key-with-ibc-12 16 Abstract 18 This document specifies the use of identity as a raw public key in 19 Transport Layer Security (TLS) and Datagram Transport Layer Security 20 (DTLS). The TLS protocol procedures are kept unchanged, but 21 signature algorithms are extended to support Identity-based signature 22 (IBS). A typical Identity-based signature algorithm, the ECCSI 23 signature algorithm defined in RFC 6507, is supported in the current 24 version. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 11, 2020. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Extension of RAW Public Key to IBC-based Public Key . . . . . 4 63 4. New Signature Algorithms for IBS . . . . . . . . . . . . . . 10 64 5. Identity Fromat and Key Revocation . . . . . . . . . . . . . 11 65 6. TLS Client and Server Handshake Behavior . . . . . . . . . . 12 66 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 7.1. TLS Client and Server Use IBS algorithm . . . . . . . . . 14 68 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 15 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 74 11.2. Informative References . . . . . . . . . . . . . . . . . 19 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 77 1. Introduction 79 DISCLAIMER: This is a personal draft and a limited security analysis 80 is provided. 82 Traditionally, TLS client and server exchange public keys endorsed by 83 PKIX [PKIX] certificates. It is considered complicated and may cause 84 security weaknesses with the use of PKIX certificates 85 [Defeating-SSL]. To simplify certificates exchange, using RAW public 86 key with TLS/DTLS has been specified in [RFC 7250] and has been 87 included in the TLS 1.3 [RFC 8446]. Instead of transmitting a full 88 certificate or a certificate chain in the TLS messages, only public 89 keys are exchanged between client and server. However, using RAW 90 public key requires out-of-band mechanisms to verify the purported 91 public key to the claimed entity. 93 Recently, 3GPP has adopted the EAP authentication framework for 5G 94 and EAP-TLS is considered as one of the candidate authentication 95 methods for private networks, especially for networks with a large 96 number of IoT devices [TS33.501]. For IoT networks, EAP-TLS with RAW 97 public key is particularly attractive, but binding identities with 98 public keys might be challenging. The cost to maintain a large table 99 for identity and public key mapping at server side incurs additional 100 cost, e.g. devices have to pre-register to the server. 102 To simplify the binding between the public key and the entity, a 103 better way could be using Identity-Based Cryptography(IBC), such as 104 ECCSI public key specified in [RFC 6507], for authentication. 105 Different from X.509 certificates and existing raw public keys, a 106 public key in IBC takes the form of the entity's identity. This 107 eliminates the necessity of binding between a public key and the 108 entity presenting the public key. 110 The concept of IBC was first proposed by Adi Shamir in 1984. As a 111 special class of public key cryptography, IBC uses a user's identity 112 as public key, avoiding the hassle of public key certification in 113 public key cryptosystems. IBC broadly includes IBE (Identity-based 114 Encryption) and IBS (Identity-based Signature). For an IBC system to 115 work, there exists a trusted third party, private key generator 116 (PKG), which is responsible for issuing private keys to the users. A 117 PKG has in possession a pair of Master Public Key and Master Secret 118 Key; a private key is generated based on the user's identity by using 119 the Master Secret key, while the Master Public key is used together 120 with the user's identities for encryption (in case of IBE) and 121 signature verification (in case of IBS). Another name of PKG is Key 122 Management System (KMS), which is also used in some IBC system. In 123 this document, the terms of PKG and KMS are interchangeable. 125 A number of IBE and IBS algorithms have been standardized by 126 different standardization bodies, such as IETF, IEEE, ISO, etc. For 127 example, IETF has specified several RFCs such as [RFC 5091], [RFC 128 6507] and [RFC6508] for both IBE and IBS algorithms. ISO and IEEE 129 also have a few standards on IBC algorithms, such as IBS1, IBS2, and 130 ChineseIBS. 132 RFC 7250 has specified the use of raw public key with TLS/DTLS 133 handshake. However, supporting of IBS algorithms has not been 134 included therein. Since IBS algorithms eliminate the binding between 135 public keys and identities, this further simplifiy the using of raw 136 public key with TLS. Therefore, in this document, an amendment is 137 added for supporting IBS algorithms as raw public key. 139 With IBS algorithms, a PKG generates private keys for entities based 140 on identities from requestors. Global parameters such as PKG's 141 Master Public Key (MPK) are provisioned to both client and server. 142 These parameters are not user specific, but PKG specific. 144 For a client, PKG specific parameters can be provisioned at the time 145 PKG provisions the private key to the client. For the server, how to 146 get the PKG specific parameters provisioned is out of the scope of 147 this document, and it is deployment dependent. 149 The document is organized as follows: Section 3 defines the data 150 structure required when identity is used as raw public key. 151 Section 4 defines the cipher suites required to support IBS algorithm 152 over TLS/DTLS. Section 5 explains how client and server authenticate 153 each other when using identity as raw public key. Section 6 gives 154 examples for using identity as raw public key over TLS/DTLS handshake 155 procedure. Section 7 discusses the security considerations. 157 2. Terms 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in BCP 162 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals. 165 3. Extension of RAW Public Key to IBC-based Public Key 167 To support the negotiation of using raw public between client and 168 server, a new certificate structure is defined in RFC 7250. It is 169 used by the client and server in the hello messages to indicate the 170 types of certificates supported by each side. 172 When RawPublicKey type is selected for authentication, a data 173 structure, subjectPublicKeyInfo, is used to carry the raw public key 174 and its cryptographic algorithm. Within the subjectPublicKeyInfo 175 structure, two fields, algorithm and subjectPublicKey, are defined. 176 The algorithm is a data structure that specifies the cryptographic 177 algorithm used with raw public key, which is represented by an object 178 Identifiers (OID); and the parameters field provides necessary 179 parameters associated with the algorithm. The subjectPublicKey field 180 within the subjectPublicKeyInfo carries the raw public itself. 182 subjectPublicKeyInfo ::= SEQUENCE { 183 algorithm AlgorithmIdentifier, 184 subjectPublicKey BIT STRING 185 } 187 AlgorithmIdentifier ::= SEQUENCE { 188 algorithm OBJECT IDENTIFIER, 189 parameters ANY DEFINED BY algorithm OPTIONAL 190 } 192 Figure 1: SubjectPublicKeyInfo ASN.1 Structure 194 With IBS algorithm, identity is used as the raw public key, which can 195 be converted to an BIT string and put into the subjectPublicKey 196 field. The algorithm field in AlgorithmIdentifier structure is the 197 object identifier of the IBS algorithm used. Specifically, for the 198 ECCSI signature algorithm supported in this draft, the OBJECT 199 IDENTIFIER is described with following data structure: 201 sa-eccsiWithSHA256 SIGNATURE-ALGORITHM ::= { 202 IDENTIFIER id-alg-eccsi-with-sha256 203 VALUE ECCSI-Sig-Value PARAMS TYPE NULL ARE absent 204 HASHES { mda-sha256 } 205 SMIME-CAPS { IDENTIFIED BY id-alg-eccsi-with-sha256 } 206 } 208 Figure 2: ECCSI Signature Algorithm ANSI.1 Structure 210 Note, in a real implementation, only IDENTIFIER part will be 211 transmitted over the TLS negotiation protocols. 213 Beside OID, it is necessary to tell the peer the set of global 214 parameters used by the signer. The information can be carried in the 215 payload of the parameters field in AlgorithmIdentifier. On the other 216 hand, when IBS algorithm is used for authentication, normally the 217 global parameters in use are known to client and server, hence, 218 instead of transmitting a full set of PKG public parameters, a hash 219 value of them is transmitted, which is put in the prameters field of 220 AlgorithmIdentifier data structure. 222 The data strcuture used to carry the hash value of public parameters 223 is defined as follows: 225 IBSPublicParametersHash ::= SEQUENCE { 226 HASHES { mda-sha256 } 227 } 229 Figure 3: IBS Global Parameters Hash ANSI.1 Structure 231 The hash value of the global parameters is generated by taking in the 232 DER encoded PKG public parameters of each individual IBS algorithms 233 as input. The data structure for each IBS algorithms supported in 234 this draft are defined in the following. 236 For the ECCSI IBS signature algorithms, its PKG public parameters is 237 specified in following Figure : 239 ECCSIPublicParameters ::= SEQUENCE { 240 version INTEGER { v2(2) }, 241 curve OBJECT IDENTIFIER, 242 hashfcn OBJECT IDENTIFIER, 243 pointP FpPOINT, 244 pointPpub FpPOINT 245 } 247 FpPoint ::= SEQUENCE { 248 x INTEGER, 249 y INTEGER 250 } 252 Figure 4: ECCSI Global Parameters ANSI.1 Structure 254 The structure to carry the ISO-IBS1/ISO-IBS2 PKG public parameters 255 are the same and is specified in followng Figure : 257 ISOIBSPublicParameters ::= SEQUENCE { 258 version INTEGER { v3(3) }, 259 curve OBJECT IDENTIFIER, 260 hashfcn OBJECT IDENTIFIER, 261 pairing PAIRING OPTIONAL, 262 p INTEGER OPTIONAL, 263 q INTEGER OPTIONAL, 264 pointP FpPoint, 265 pointPpub FpPoint 266 } 268 PAIRING ::= ENUMERATED{ 269 weil (1) --Weil pairing 270 tate (2) --Tate pairing 271 optimalAte (3) --Optimal Ate pairing 272 } 274 Figure 5: ISO-IBS1/IBS2 Global Parameters ANSI.1 Structure 276 The structure to carry the ISO-SM9 PKG public parameters is specified 277 in following Figure : 279 SM9PublicParameters ::= SEQUENCE { 280 version INTEGER { v3(3) }, 281 curve OBJECT IDENTIFIER, 282 hashfcn OBJECT IDENTIFIER, 283 pairing PAIRING OPTIONAL, 284 p INTEGER OPTIONAL, 285 q INTEGER OPTIONAL, 286 pointP2 FpxPoint, 287 pointP2pub FpxPoint, 288 y FpxElement 289 } 291 FpxPoint ::= CHOICE{ 292 fpPoint FpPoint, 293 fp2Point [2] EXPLICIT Fp2Point, 294 } 296 Fp2Point ::= SEQUENCE{ 297 x Fp2Element, 298 y Fp2Element 299 } 301 Fp2Element ::= SEQUENCE{ 302 a INTEGER, 303 b INTEGER 304 } 306 FpxElement ::= CHOICE{ 307 fp2Elemt Fp2Element, 308 fp12Elemt Fp12Element, 309 } 311 Fp12Element ::= SEQUENCE{ 312 a Fp6Element, 313 b Fp6Element 314 } 316 Fp6Element ::= SEQUENCE{ 317 a Fp2Element, 318 b Fp2Element, 319 c Fp2Element 320 } 322 Figure 6: ISO-ChineseIBS Global Parameters ANSI.1 Structure 324 For ECCSIPublicParameters data structure, pointP shall be G in RFC 325 6507 and pointPpub shall be KPAK in RFC 6507. For 326 ISOIBSPublicParameters data structure, pointP and pointPpub shall be 327 the same as defined in RFC 5091, and the pairing field shall be weil 328 (1) or tate (2). The pairing field in SM9PublicParameters should be 329 optimalAte (3) and the choice of v should be determined by the curve 330 identifier. For example, for supersingular curves [RFC 5901], v 331 shall be of type Fp2Element and for BN curves or BLS12-curves 332 [FST10], v shall be of type Fp12Element. 334 To support IBS algorithm over TLS protocol, a data structure for 335 signature value need to be defined. 337 Data structure for ECCSI is defined as follows(based RFC 6507): 339 ECCSI-Sig-Value ::= SEQUENCE { 340 r INTEGER, 341 s INTEGER, 342 PVT OCTET STRING 343 } 345 Figure 7: ECCSI Signature Value ANSI.1 Structure 347 where PVT (as defined in RFC 6507) is encoded as 0x04 || x-coordinate 348 of [v]G || y-coordinate of [v]G. 350 Data structure for ISO-IBS1 is defined as follows: 352 ISO-IBS1-Sig-Value ::= SEQUENCE { 353 r INTEGER, 354 s ECPoint 355 } 357 Figure 8: ISO-IBS1 Signature Value ANSI.1 Structure 359 Data structure for ISO-IBS2 is defined as follows: 361 ISO-IBS2-Sig-Value ::= SEQUENCE { 362 r INTEGER, 363 s ECPoint 364 } 366 Figure 9: ISO-IBS2 Signature Value ANSI.1 Structure 368 Data structure for ISO-ChineseIBS (SM9) is defined as follows: 370 SM9-Sig-Value ::= SEQUENCE { 371 r INTEGER, 372 s ECPoint 373 } 375 Figure 10: ISO-ChineseIBS Signature Value ANSI.1 Structure 377 The definition of ECPoint can be found in section 2.2 of RFC 5480. 379 To use a signature algorithm with TLS, OID for the signature 380 algorithm need be provided. For ECCSI algorithm, an OID has been 381 assigned by IANA recently. The following table shows the basic 382 information needed for the ECCSI signature algorithm to be used for 383 TLS. 385 +--------------------------+----------------+-----------------------+ 386 | Key Type | Document | OID | 387 +--------------------------+----------------+-----------------------+ 388 | ISO/IEC 14888-3 IBS-1 | ISO/IEC | 1.0.14888.3.0.7 | 389 | | 14888-3: IBS-1 | | 390 | | mechanism | | 391 +--------------------------+----------------+-----------------------+ 392 | ISO/IEC 14888-3 IBS-2 | ISO/IEC | 1.0.14888.3.0.8 | 393 | | 14888-3: IBS-2 | | 394 | | mechanism | | 395 +--------------------------+----------------+-----------------------+ 396 | ISO/IEC 14888-3 | ISO/IEC | 1.2.156.10197.1.302.1 | 397 | ChineseIBS(SM9) | 14888-3: | | 398 | | ChineseIBS | | 399 | | mechanism | | 400 +--------------------------+----------------+-----------------------+ 401 | Elliptic Curve-Based | Section 5.2 | 1.3.6.1.5.5.7.6.29 | 402 | Signatureless For | in RFC 6507 | | 403 | Identitiy-based | | | 404 | Encryption (ECCSI) | | | 405 +--------------------------+----------------+-----------------------+ 407 Table 1: Algorithm Object Identifiers 409 4. New Signature Algorithms for IBS 411 To using identity as raw public key, new signature algorithms 412 corresponding to the IBS need to be defined. With TLS 1.3, the value 413 for signature algorithm is defined in the SignatureScheme. This 414 document specifies how to support IBS algorithm. As a reult, the 415 SignatureScheme data structure has to be amended by including the 416 presented IBS algorithms. 418 enum { 419 ... 421 /* IBS ECCSI signature algorithm */ 422 eccsi_sha256 (TBD), 423 iso_ibs1 (TBD), 424 iso_ibs2 (TBD), 425 iso_chinese_ibs (TBD), 427 /* Reserved Code Points */ 428 private_use (0xFE00..0xFFFF), 429 (0xFFFF) 430 } SignatureScheme; 432 Figure 11: Include IBS in KeyExchangeAlgorithm 434 Note: The signature algorithm of eccsi_sha256 is defined in RFC6507. 436 Note: Other IBS signature algorithms can be added in the future. 438 5. Identity Fromat and Key Revocation 440 With the raw public scheme proposed in TLS 1.3 [RFC 8446], server 441 maintains a whitlist to bind raw public key and identity. When a raw 442 public key is revoked, then server removes the binding record from 443 the whitelist. On the other hand, when using IBS agorithm for raw 444 public key, there is no whitelist at server side. Instead, the 445 server need to maintain a blacklist, which is much shorter than the 446 whitelist, to support public key revoication. However, if we simply 447 using the identifier as raw public key, the revocation list may keep 448 on increasing with the time going on. Hence, to prevent the 449 revocation list from increasing continuously, it is recommended to 450 include a timestamp for automatic expiration of key material. With 451 the timestamp included in the identifier, i.e. the raw public key, 452 server can remove revoked raw public key from revocation list when it 453 is expired. 455 Based on the above anaysis, it is necessary to include expiration 456 time in the identifiers for the purpose of public key management. 457 Therefore, in this draft, we recommend both client and server take 458 following format for the identifiers used for TLS session setup: 460 Identifier ::= SEQUENCE { 461 version INTEGER {v1 (1)}, 462 identity String, 463 expiration UTCTime 464 } 466 Figure 12: Identifier Format ANSI.1 Structure 468 Both the client and server should check the validity of the 469 expiration field of the raw public key before verify the signature. 470 If the expiration time is invalid, the client or the server should 471 abort the handshake procedure. 473 The identities of client or server shall be unique within the domain 474 managed by one PKG. There are many different identities domains such 475 as email address, telephone number, Network Access Identifier (NAI), 476 International Mobile Subscriber Identity (IMSI) etc. It is up to 477 network operators's choice to determine which name domain the device 478 and server take. 480 6. TLS Client and Server Handshake Behavior 482 When IBS is used as RAW public for TLS, signature and hash algorithms 483 are negotiated during the handshake. 485 The handshake between the TLS client and server follows the 486 procedures defined in [RFC 8446], but with the support of the new 487 signature algorithms specific to the IBS algorithms. The high-level 488 message exchange in the following figure shows TLS handshake using 489 raw public keys, where the client_certificate_type and 490 server_certificate_type extensions added to the client and server 491 hello messages (see Section 4 of [RFC 7250]). 493 client_hello, 494 +key_share 495 +signature_algorithms 496 client_certificate_type, 497 server_certificate_type -> 499 <- server_hello, 500 + key_share 501 {EncryptyedExtensions} 502 {client_certificate_type} 503 {server_certificate_type} 504 {Certificate} 505 {CertificateVerify} 506 {CertificateRequest} 507 {Finished} 508 [Applicaiton Data] 509 {Certificate} 510 {CertificateVerify} 511 {Finished} --------> 512 [Application Data} <-------> [Application Data] 514 Figure 13: Basic Raw Public Key TLS Exchange 516 The client hello messages tells the server the types of certificate 517 or raw public key supported by the client, and also the certificate 518 types that client expects to receive from server. When raw public 519 with IBS algorithm from server is supported by the client, the client 520 includes desired IBS signature algorithm in the client hello message 521 based on the order of client preference. 523 After receiving the client hello message, server determines the 524 client and server certificate types for handshakes. When the 525 selected certificate type is RAW public key and IBS is the chosen 526 signature algorithm, server uses the SubjectPublicKeyInfo structure 527 to carry the raw public key, OID for IBS algorithm. Assuming that 528 ECCSI is selected, the ECCSIPublicParameters data strucutre is used 529 to carry global public parameters. With these information, the 530 client knows the signature algorithm and the public parameters that 531 should be used to verify the signature. The signature value is in 532 the CertificateVerify message and the format of signature value is 533 specified by the selected IBS algorithm. The data structures for PKG 534 public parameters and signature values have been specified in the 535 previous section of this document. 537 When sever specifies that RAW public key should be used by client to 538 authenticate with server, the client_certificate_type in the server 539 hello is set to RawPublicKey. Besides that, the server also sends 540 Certificate Request, indicating that client should use some specific 541 signature and hash algorithms. When IBS is chosen as signature 542 algorithm, the server need to indicate the required IBS signature 543 algorithms in the signature_algorithm extension within the 544 CertificateRequest. 546 After receiving the server hello, the client checks the 547 CertificateRequest for signature algorithms. If client wants to use 548 an IBS algorithm for signature, then the signature algorithm it 549 intended to use must be in the list of supported signature algorithms 550 specified by the server. Assume the IBS algorithm supported by the 551 client is in the list, then the client response with the IBS 552 signature algorithm and PKG information with SubjectPublicKeyInfo 553 structure in the certificate structure and provide signatures in the 554 certificate verify message. The format of signature in the 555 CertificateVerify message should be specified by each individual 556 signature algorithm. 558 The server verifies the signature based on the chosen IBS algorithm 559 and the relevant PKG parameters specified by the client. 561 7. Examples 563 In the following, examples of handshake exchange using IBS algorithm 564 under RawPublicKey are illustrated. 566 7.1. TLS Client and Server Use IBS algorithm 568 In this example, both the TLS client and server use ECCSI for 569 authentication, and they are restricted in that they can only process 570 ECCSI signature algorithm. As a result, the TLS client sets both the 571 server_certificate_type and the client_certificate_type extensions to 572 be raw public key; in addition, the client sets the signature 573 algorithm in the client hello message to be eccsi_sha256. 575 When the TLS server receives the client hello, it processes the 576 message. Since it has an ECCSI raw public key from the PKG, it 577 indicates in (2) that it agrees to use ECCSI and provides an ECCSI 578 key by placing the SubjectPublicKeyInfo structure into the 579 Certificate payload back to the client (3), including the OID, the 580 identity of server, ServerID, which is the public key of server also, 581 and hash value of PKG public parameters. The client_certificate_type 582 in (4) indicates that the TLS server accepts raw public key. The TLS 583 server demands client authentication, and therefore includes a 584 certificate_request(5), which requires the client to use eccsi_sha256 585 for signature. A signature value based on the eccsi_sha256 algorithm 586 is carried in the CertificateVerify (6). The client, which has an 587 ECCSI key, returns its ECCSI public key in the Certificate payload to 588 the server (7), which includes an OID for the ECCSI signature 589 algorithm, the PKGInfo for KMS parameters, and identity of client, 590 ClientID, which is the public key of client also. The client also 591 includes a signature value, ECCSI-Sig-Value, in the CertificateVerify 592 (8) message. 594 When client/server receive PKG public parameters from peer, it should 595 decide whether these parameters are acceptable or not. An exmaple 596 way to make decision is that a whitelist of acceptable PKG public 597 parameters are stored locally at client/server. They can simply make 598 a decision based on the white list stored locally. 600 client_hello, 601 +key_share //(1) 602 signature_algorithm = (eccsi_sha256) //(1) 603 client_certificate_type=(RawPublicKey) //(1) 604 server_certificate_type=(RawPublicKey) //(1) 605 -> 606 <- server_hello, 607 + key_share 608 { server_certificate_type = RawPublicKey} //(2) 609 {certificate=((1.3.6.1.5.5.7.6.29, hash 610 value of ECCSIPublicParameters), 611 serverID)} //(3) 612 {client_certificate_type = RawPublicKey //(4) 613 {certificate_request = (eccsi_sha256)} //(5) 614 {CertificateVerify = {ECCSI-Sig-Value} //(6) 615 {Finishaed} 617 {Certificate=( 618 (1.3.6.1.5.5.7.6.29, 619 hash value of ECCSIPublicParameters), 620 ClientID)} //(7) 621 {CertificatVerify = (ECCSI-Sig-Value)} //(8) 622 {Finished } 623 [Applicateion Data] ----> 624 [Application Data] <---> [Application Data] 626 Figure 14: Basic Raw Public Key TLS Exchange 628 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 630 This example combines the uses of an ECCSI key and an X.509 631 certificate. The TLS client uses an ECCSI key for client 632 authentication, and the TLS server provides an X.509 certificate for 633 server authentication. 635 The exchange starts with the client indicating its ability to process 636 a raw public key, or an X.509 certificate, if provided by the server. 638 It prefers a raw public key with ECCSI signature algorithm since 639 eccsi_sha256 preceeds the ecdsa_secp256r1_sha256. Furthermore, the 640 client indicates that it has a ECCSI-based raw public key for client- 641 side authentication. Client also indicate it supports server using 642 either ECCSI or ecdsa_secp256r1_sha256 for the certificate signature. 643 This further indicates that server can use ecdsa_secp256r1_sha256 to 644 sign the message. 646 With the received client_hello, the server chooses to provide its 647 X.509 certificate in (3) and indicates that choice in (2). For 648 client authentication, the server indicates in (4) that it has 649 selected the raw public key format and requests an ECCSI certificate 650 from the client in (4) and (5). The TLS client provides an ECSSI 651 certificate in (6) and signature value after receiving and processing 652 the TLS server hello message. 654 client_hello, 655 +key_share 656 signature_algorithms =(eccsi_sha256, 657 ecdsa_secp256r1_sha256) //(1) 658 signature_algorithms_cert = ( 659 eccsi_sha256, ecdsa_secp256r1_sha256) //(1) 660 {client_certificate_type= 661 (RawPublicKey)} //(1) 662 {server_certificate_type= 663 (RawPublicKey, X.509) //(1) 664 -> 665 <- server_hello, 666 +key_share 667 {server_certificate_type=X.509} //(2) 668 {Certificate = (x.509 certificate)} //(3) 669 {client_certificate_type = (RawPublicKey)}//(4) 670 {CertificateRequest} = (eccsi_sha256)} //(5) 671 {CertificateVerify} 672 {Finished} 673 certificate=( 674 (1.3.6.1.5.5.7.6.29, 675 ECCSIPublicParameters), 676 ClientID), //(6) 677 {CertificatVerify = 678 (ECCSI-Sig-Value)} //(7) 679 { Finished } 680 [Applicateion Data] ----> 681 [Application Data] <---> [Application Data] 683 Figure 15: Basic Raw Public Key TLS Exchange 685 Handshake for other IBS algorithms can be completed similarly by 686 including different data structures for public parameters and 687 signature values respectively. 689 8. Security Considerations 691 Using IBS-based raw public key in TLS/DTLS does not change the 692 message flows of TLS, hence, for the most part, the security 693 considerations involved in using the Transport Layer Security 694 protocol with raw public key also apply here. The additional 695 security of the resulting protocol rests on the security of the used 696 IBS algorithms. 698 IBS signature algorithm has been standardized for ten years and has 699 been adopted in real applications. However, we would like to point 700 out the difference between IBS signature algorithm and existing raw 701 public key: the private key of IBS used for signature generation is 702 generated by the PKG centre, while the private key for the existing 703 raw public key is generated locally. Therefore, IBS mechanism may 704 face a security risk of private key disclosure due to improper 705 management of KMS system. The entity using IBS with TLS protocol 706 shall be aware the above risk and an enforced key management system 707 shall be adopted by the organization. 709 When using IBS algorithm, key escrow is an concern as the private key 710 of user or devices normally is generated by PKG. PKG in the system 711 which could generate each device's private key. However, when IBS is 712 used in TLS1.3, passively attack to recover the session key is not 713 possible. Actively man-in-the-middle attack by replacing exchanged 714 DH tokens and signatures would certainly leave traces even 715 transiently. Similarly, a PKG could impersonate an entity to conduct 716 a TLS session, just as the KMS in the symmetric key solution, but 717 forensic traces could be also collected in this situation. It would 718 be hugely risky for a PKG, which would usually be a trusted party, to 719 launch such attacks. If such an attack is caught in red-handed, no 720 one would trust the PKG's service anymore. 722 Another worry of using IBS is about the compromising of PKG. The PKG 723 could become operationally compromised and an attacker may obtain 724 master secrets of a PKG. However, this security risk can be solved 725 by protect the PKG with HSM, which is often used by CA to protect the 726 root signning key. 728 Private key compromising is one security risk that need to be 729 considered when using public key technology. When using IBS for raw 730 public, as we have suggested in this document, a revocation list 731 shall be maintained at the server side. At the same time, a 732 timestamp shall be included in the public key to prevent the 733 revocation list from keeping on increasing. With the revocation 734 list, server can prevent following attacks: 736 1) when a device using a revoked identifier for authentication, which 737 has not been expired yet, then the server can reject the TLS session 738 by checking the revocation list maintained at the server side. As it 739 is in the list, then the server aborts the TLS handshake. 741 2) When a device using a identifier which has been expired, the 742 server can simply verify the timestamp contained in the identifier 743 and abort the handshake procedure immediately. 745 3) If the attacker changes the timestemp within the identifier, then 746 it will cause signature verification error when server verify the 747 siganture contained in the signature_verify from client. 749 9. IANA Considerations 751 IANA has assigned 4 code points from the TLS SignatureScheme registry 752 for the four IBS algorithms used in this document. The code poins 753 are listed as follows: 755 - eccsi_sha256 757 - iso_ibs1 759 - iso_ibs2 761 - iso_chinese_ibs 763 For all of these entries the Recommended field should be N, and the 764 Reference field should be this document. 766 10. Acknowledgements 768 11. References 770 11.1. Normative References 772 [PKIX] "Internet X.509 Public Key Infrastructure Certificate and 773 Certificate Revocation List(CRL) Profile", June 2008. 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, 777 DOI 10.17487/RFC2119, March 1997, 778 . 780 [RFC2434] "Guidelines for Writing an IANA Consideration Section in 781 RFCs", October 1998. 783 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 784 Standard (IBCS) #1: Supersingular Curve Implementations of 785 the BF and BB1 Cryptosystems", RFC 5091, 786 DOI 10.17487/RFC5091, December 2007, 787 . 789 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 790 "Elliptic Curve Cryptography Subject Public Key 791 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 792 . 794 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 795 Signatures for Identity-Based Encryption (ECCSI)", 796 RFC 6507, DOI 10.17487/RFC6507, February 2012, 797 . 799 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 800 RFC 6508, DOI 10.17487/RFC6508, February 2012, 801 . 803 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 804 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 805 Transport Layer Security (TLS) and Datagram Transport 806 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 807 June 2014, . 809 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 810 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 811 May 2017, . 813 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 814 RFC 8216, DOI 10.17487/RFC8216, August 2017, 815 . 817 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 818 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 819 . 821 11.2. Informative References 823 [Defeating-SSL] 824 "New Tricks for Defeating SSL in Practice", Feb 2009, 825 . 829 [FST10] "A Taxonomy of Pairing-Friendly Elliptic Curves. Journal 830 of Cryptology. Volume 23, Issue 2, pp 224-280,", Apr 2010. 832 [TS33.501] 833 "TS 33.501, Security architecture and procedures for 5G 834 System, v.g.0.0", Sept 2019, 835 . 838 Authors' Addresses 840 Haiguang Wang (editor) 841 Huawei International Pte. Ltd. 842 11 North Buona Vista Dr, #17-08 843 Singapore 138589 844 SG 846 Phone: +65 6825 4200 847 Email: wang.haiguang1@huawei.com 849 Yanjiang Yang 850 Huawei International Pte. Ltd. 851 11 North Buona Vista Dr, #17-08 852 Singapore 138589 853 SG 855 Phone: +65 6825 4200 856 Email: yang.yanjiang@huawei.com 858 Xin Kang 859 Huawei International Pte. Ltd. 860 11 North Buona Vista Dr, #17-08 861 Singapore 138589 862 SG 864 Phone: +65 6825 4200 865 Email: xin.kang@huawei.com 866 Zhaohui Cheng 867 Shenzhen Olym Info. Security Tech. Ltd. 868 Futong Haowangjiao Podium Building 869 Shenzhen, Guang Dong Province 518101 870 CN 872 Phone: +86 755 8618 2108 873 Email: chenzh@myibc.net 875 Meiling Chen 876 China Mobile 877 32, Xuanwumen West 878 BeiJing, BeiJing 100053 879 China 881 Email: 882 chenmeiling@chinamobile.com