idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-10.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 16, 2019) is 1837 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 492, but not defined == Missing Reference: 'RFC 8446' is mentioned on line 487, but not defined == Missing Reference: 'RFC 6507' is mentioned on line 102, but not defined == Missing Reference: 'RFC 5091' is mentioned on line 125, but not defined -- Looks like a reference, but probably isn't: '2' on line 294 == Missing Reference: 'RFC 5901' is mentioned on line 331, 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 18, 2019 Huawei International Pte. Ltd. 6 Z. Cheng 7 Shenzhen Olym Info. Security Tech. Ltd. 8 April 16, 2019 10 Using Identity as Raw Public Key in Transport Layer Security (TLS) and 11 Datagram Transport Layer Security (DTLS) 12 draft-wang-tls-raw-public-key-with-ibc-10 14 Abstract 16 This document specifies the use of identity as a raw public key in 17 Transport Layer Security (TLS) and Datagram Transport Layer Security 18 (DTLS). The TLS protocol procedures are kept unchanged, but 19 signature algorithms are extended to support Identity-based signature 20 (IBS). A typical Identity-based signature algorithm, the ECCSI 21 signature algorithm defined in RFC 6507, is supported in the current 22 version. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 18, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Extension of RAW Public Key to IBC-based Public Key . . . . . 4 61 4. New Signature Algorithms for IBS . . . . . . . . . . . . . . 10 62 5. Identity Fromat and Key Revocation . . . . . . . . . . . . . 11 63 6. TLS Client and Server Handshake Behavior . . . . . . . . . . 12 64 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 7.1. TLS Client and Server Use IBS algorithm . . . . . . . . . 14 66 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 15 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 72 11.2. Informative References . . . . . . . . . . . . . . . . . 19 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 75 1. Introduction 77 DISCLAIMER: This is a personal draft and a limited security analysis 78 is provided. 80 Traditionally, TLS client and server exchange public keys endorsed by 81 PKIX [PKIX] certificates. It is considered complicated and may cause 82 security weaknesses with the use of PKIX certificates Defeating-SSL 83 [Defeating-SSL]. To simplify certificates exchange, using RAW public 84 key with TLS/DTLS has been specified in [RFC 7250] and has been 85 included in the TLS 1.3 [RFC 8446]. With RAW public key, instead of 86 transmitting a full certificate or a certificate chain in the TLS 87 messages, only public keys are exchanged between client and server. 88 However, using RAW public key requires out-of-band mechanisms to 89 verify the purported public key to the claimed entity. 91 Recently, 3GPP has adopted the EAP authentication framework for 5G 92 and EAP-TLS is considered as one of the candidate authentication 93 methods for private networks, especially for networks with a large 94 number of IoT devices. For IoT networks, TLS/DTLS with RAW public 95 key is particularly attractive, but binding identities with public 96 keys might be challenging. The cost to maintain a large table for 97 identity and public key mapping at server side incurs 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, a 101 better way could be using Identity-Based Cryptography(IBC), such as 102 ECCSI public key specified in [RFC 6507], for authentication. 103 Different from X.509 certificates and raw public keys, a public key 104 in IBC takes the form of the entity's identity. This eliminates the 105 necessity of binding between a public key and the entity presenting 106 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). Another name of PKG is 120 Key Management System (KMS), which is also used in some IBC system. 121 In this document, the terms of PKG and KMS are interchangeable. 123 A number of IBE and IBS algorithms have been standardized by 124 different standardization bodies, such as IETF, IEEE, ISO, etc. For 125 example, IETF has specified several RFCs such as [RFC 5091], [RFC 126 6507] and [RFC6508] for both IBE and IBS algorithms. ISO and IEEE 127 also have a few standards on IBC algorithms, such as IBS1, IBS2, and 128 ChineseIBS. 130 RFC 7250 has specified the use of raw public key with TLS/DTLS 131 handshake. However, supporting of IBS algorithms has not been 132 included therein. Since IBS algorithms are efficient in public key 133 transmission and also eliminate the binding between public keys and 134 identities, in this document, an amendment is added for supporting 135 IBS algorithms as raw public key. 137 IBS algorithm exempts client and server from public key certification 138 and identity binding by checking an entity's signatures and its 139 identity against the master public key of its PKG. With an IBS 140 algorithm, a PKG generates private keys for entities based on their 141 identities. Global parameters such as PKG's Master Public Key (MPK) 142 need be provisioned to both client and server. These parameters are 143 not user specific, but PKG specific. 145 For a client, PKG specific parameters can be provisioned at the time 146 PKG provisions the private key to the client. For the server, how to 147 get the PKG specific parameters provisioned is out of the scope of 148 this document, and it is deployment dependent. 150 The document is organized as follows: Section 3 defines the data 151 structure required when identity is used as raw public key. 152 Section 4 defines the cipher suites required to support IBS algorithm 153 over TLS/DTLS. Section 5 explains how client and server authenticate 154 each other when using identity as raw public key. Section 6 gives 155 examples for using identity as raw public key over TLS/DTLS handshake 156 procedure. Section 7 discusses the security considerations. 158 2. Terms 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals. 166 3. Extension of RAW Public Key to IBC-based Public Key 168 To support the negotiation of using raw public between client and 169 server, a new certificate structure is defined in RFC 7250. It is 170 used by the client and server in the hello messages to indicate the 171 types of certificates supported by each side. 173 When RawPublicKey type is selected for authentication, a data 174 structure, subjectPublicKeyInfo, is used to carry the raw public key 175 and its cryptographic algorithm. Within the subjectPublicKeyInfo 176 structure, two fields, algorithm and subjectPublicKey, are defined. 177 The algorithm is a data structure that specifies the cryptographic 178 algorithm used with raw public key, which is represented by an object 179 Identifiers (OID); and the parameters field provides necessary 180 parameters associated with the algorithm. The subjectPublicKey field 181 within the subjectPublicKeyInfo carries the raw public itself. 183 subjectPublicKeyInfo ::= SEQUENCE { 184 algorithm AlgorithmIdentifier, 185 subjectPublicKey BIT STRING 186 } 188 AlgorithmIdentifier ::= SEQUENCE { 189 algorithm OBJECT IDENTIFIER, 190 parameters ANY DEFINED BY algorithm OPTIONAL 191 } 193 Figure 1: SubjectPublicKeyInfo ASN.1 Structure 195 With IBS algorithm, identity is used as the raw public key, which can 196 be converted to an BIT string and put into the subjectPublicKey 197 field. The algorithm field in AlgorithmIdentifier structure is the 198 object identifier of the IBS algorithm used. Specifically, for the 199 ECCSI signature algorithm supported in this draft, the OBJECT 200 IDENTIFIER is described with following data structure: 202 sa-eccsiWithSHA256 SIGNATURE-ALGORITHM ::= { 203 IDENTIFIER id-alg-eccsi-with-sha256 204 VALUE ECCSI-Sig-Value PARAMS TYPE NULL ARE absent 205 HASHES { mda-sha256 } 206 SMIME-CAPS { IDENTIFIED BY id-alg-eccsi-with-sha256 } 207 } 209 Figure 2: ECCSI Signature Algorithm ANSI.1 Structure 211 Note, in a real implementation, only IDENTIFIER part will be 212 transmitted over the TLS negotiation protocols. 214 Beside OID, it is necessary to tell the peer the set of global 215 parameters used by the signer. The information can be carried in the 216 payload of the parameters field in AlgorithmIdentifier. On the other 217 hand, when IBS algorithm is used for authentication, normally the 218 global parameters in use are known to client and server, hence, 219 instead of transmitting a full set of PKG public parameters, a hash 220 value of them is transmitted, which is put in the prameters field of 221 AlgorithmIdentifier data structure. 223 The data strcuture used to carry the hash value of public parameters 224 is defined as follows: 226 IBSPublicParametersHash ::= SEQUENCE { 227 HASHES { mda-sha256 } 228 } 230 Figure 3: IBS Global Parameters Hash ANSI.1 Structure 232 The hash value of the global parameters is generated by taking in the 233 PKG public parameters of each individual IBS algorithms as input. 234 The data structure for each IBS algorithms supported in this draft 235 are defined in the following. 237 For the ECCSI IBS signature algorithms, its PKG public parameters is 238 specified in following Figure : 240 ECCSIPublicParameters ::= SEQUENCE { 241 version INTEGER { v2(2) }, 242 curve OBJECT IDENTIFIER, 243 hashfcn OBJECT IDENTIFIER, 244 pointP FpPOINT, 245 pointPpub FpPOINT 246 } 248 FpPoint ::= SEQUENCE { 249 x INTEGER, 250 y INTEGER 251 } 253 Figure 4: ECCSI Global Parameters ANSI.1 Structure 255 The structure to carry the ISO-IBS1/ISO-IBS2 PKG public parameters 256 are the same and is specified in followng Figure : 258 ISOIBSPublicParameters ::= SEQUENCE { 259 version INTEGER { v3(3) }, 260 curve OBJECT IDENTIFIER, 261 hashfcn OBJECT IDENTIFIER, 262 pairing PAIRING OPTIONAL, 263 p INTEGER OPTIONAL, 264 q INTEGER OPTIONAL, 265 pointP FpPoint, 266 pointPpub FpPoint 267 } 269 PAIRING ::= ENUMERATED{ 270 weil (1) --Weil pairing 271 tate (2) --Tate pairing 272 optimalAte (3) --Optimal Ate pairing 273 } 275 Figure 5: ISO-IBS1/IBS2 Global Parameters ANSI.1 Structure 277 The structure to carry the ISO-SM9 PKG public parameters is specified 278 in following Figure : 280 SM9PublicParameters ::= SEQUENCE { 281 version INTEGER { v3(3) }, 282 curve OBJECT IDENTIFIER, 283 hashfcn OBJECT IDENTIFIER, 284 pairing PAIRING OPTIONAL, 285 p INTEGER OPTIONAL, 286 q INTEGER OPTIONAL, 287 pointP2 FpxPoint, 288 pointP2pub FpxPoint, 289 y FpxElement 290 } 292 FpxPoint ::= CHOICE{ 293 fpPoint FpPoint, 294 fp2Point [2] EXPLICIT Fp2Point, 295 } 297 Fp2Point ::= SEQUENCE{ 298 x Fp2Element, 299 y Fp2Element 300 } 302 Fp2Element ::= SEQUENCE{ 303 a INTEGER, 304 b INTEGER 305 } 307 FpxElement ::= CHOICE{ 308 fp2Elemt Fp2Element, 309 fp12Elemt Fp12Element, 310 } 312 Fp12Element ::= SEQUENCE{ 313 a Fp6Element, 314 b Fp6Element 315 } 317 Fp6Element ::= SEQUENCE{ 318 a Fp2Element, 319 b Fp2Element, 320 c Fp2Element 321 } 323 Figure 6: ISO-ChineseIBS Global Parameters ANSI.1 Structure 325 For ECCSIPublicParameters data structure, pointP shall be G in RFC 326 6507 and pointPpub shall be KPAK in RFC 6507. For 327 ISOIBSPublicParameters data structure, pointP and pointPpub shall be 328 the same as defined in RFC 5091, and the pairing field shall be weil 329 (1) or tate (2). The pairing field in SM9PublicParameters should be 330 optimalAte (3) and the choice of v should be determined by the curve 331 identifier. For example, for supersingular curves [RFC 5901], v 332 shall be of type Fp2Element and for BN curves or BLS12-curves 333 [FST10], v shall be of type Fp12Element. 335 To support IBS algorithm over TLS protocol, a data structure for 336 signature value need to be defined. 338 Data structure for ECCSI is defined as follows(based RFC 6507): 340 ECCSI-Sig-Value ::= SEQUENCE { 341 r INTEGER, 342 s INTEGER, 343 PVT OCTET STRING 344 } 346 Figure 7: ECCSI Signature Value ANSI.1 Structure 348 where PVT (as defined in RFC 6507) is encoded as 0x04 || x-coordinate 349 of [v]G || y-coordinate of [v]G. 351 Data structure for ISO-IBS1 is defined as follows: 353 ISO-IBS1-Sig-Value ::= SEQUENCE { 354 r INTEGER, 355 s ECPoint 356 } 358 Figure 8: ISO-IBS1 Signature Value ANSI.1 Structure 360 Data structure for ISO-IBS2 is defined as follows: 362 ISO-IBS2-Sig-Value ::= SEQUENCE { 363 r INTEGER, 364 s ECPoint 365 } 367 Figure 9: ISO-IBS2 Signature Value ANSI.1 Structure 369 Data structure for ISO-ChineseIBS (SM9) is defined as follows: 371 SM9-Sig-Value ::= SEQUENCE { 372 r INTEGER, 373 s ECPoint 374 } 376 Figure 10: ISO-ChineseIBS Signature Value ANSI.1 Structure 378 The definition of ECPoint can be found in section 2.2 of RFC 5480. 380 To use a signature algorithm with TLS, OID for the signature 381 algorithm need be provided. For ECCSI algorithm, an OID has been 382 assigned by IANA recently. The following table shows the basic 383 information needed for the ECCSI signature algorithm to be used for 384 TLS. 386 +--------------------------+----------------+-----------------------+ 387 | Key Type | Document | OID | 388 +--------------------------+----------------+-----------------------+ 389 | ISO/IEC 14888-3 IBS-1 | ISO/IEC | 1.0.14888.3.0.7 | 390 | | 14888-3: IBS-1 | | 391 | | mechanism | | 392 +--------------------------+----------------+-----------------------+ 393 | ISO/IEC 14888-3 IBS-2 | ISO/IEC | 1.0.14888.3.0.8 | 394 | | 14888-3: IBS-2 | | 395 | | mechanism | | 396 +--------------------------+----------------+-----------------------+ 397 | ISO/IEC 14888-3 | ISO/IEC | 1.2.156.10197.1.302.1 | 398 | ChineseIBS(SM9) | 14888-3: | | 399 | | ChineseIBS | | 400 | | mechanism | | 401 +--------------------------+----------------+-----------------------+ 402 | Elliptic Curve-Based | Section 5.2 in | 1.3.6.1.5.5.7.6.29 | 403 | Signatureless For | RFC 6507 | | 404 | Identitiy-based | | | 405 | Encryption (ECCSI) | | | 406 +--------------------------+----------------+-----------------------+ 408 Table 1: Algorithm Object Identifiers 410 4. New Signature Algorithms for IBS 412 To using identity as raw public key, new signature algorithms 413 corresponding to the IBS need to be defined. With TLS 1.3, the value 414 for signature algorithm is defined in the SignatureScheme. This 415 document specifies how to support IBS algorithm. As a reult, the 416 SignatureScheme data structure has to be amended by including the 417 presented IBS algorithms. 419 enum { 420 ... 422 /* IBS ECCSI signature algorithm */ 423 eccsi_sha256 (TBD), 424 iso_ibs1 (TBD), 425 iso_ibs2 (TBD), 426 iso_chinese_ibs (TBD), 428 /* Reserved Code Points */ 429 private_use (0xFE00..0xFFFF), 430 (0xFFFF) 431 } SignatureScheme; 433 Figure 11: Include IBS in KeyExchangeAlgorithm 435 Note: The signature algorithm of eccsi_sha256 is defined in RFC6507. 437 Note: Other IBS signature algorithms can be added in the future. 439 5. Identity Fromat and Key Revocation 441 With the raw public scheme proposed in TLS 1.3 [RFC 8446], server 442 maintains a whitlist to bind raw public key and identity. When a raw 443 public key is revoked, then server removes the binding record from 444 the whitelist. On the other hand, when using IBS agorithm for raw 445 public key, there is no whitelist at server side. Instead, the 446 server need to maintain a blacklist, which is much shorter than the 447 whitelist, to support public key revoication. However, if we simply 448 using the identifier as raw public key, the revocation list may keep 449 on increasing with the time going on. Hence, to prevent the 450 revocation list from increasing continuously, it is recommended to 451 include a timestamp for automatic expiration of key material. With 452 the timestamp included in the identifier, i.e. the raw public key, 453 server can remove revoked raw public key from revocation list when it 454 is expired. 456 Based on the above anaysis, it is necessary to include expiration 457 time in the identifiers for the purpose of public key management. 458 Therefore, in this draft, we recommend both client and server take 459 following format for the identifiers used for TLS session setup: 461 Identifier ::= SEQUENCE { 462 version INTEGER {v1 (1)}, 463 identity String, 464 expiration UTCTime 465 } 467 Figure 12: Identifier Format ANSI.1 Structure 469 Both the client and server should check the validity of the 470 expiration field of the raw public key before verify the signature. 471 If the expiration time is invalid, the client or the server should 472 abort the handshake procedure. 474 The identities of client or server shall be unique within the domain 475 managed by one PKG. There are many different identities domains such 476 as email address, telephone number, Network Access Identifier (NAI), 477 International Mobile Subscriber Identity (IMSI) etc. It is up to 478 network operators's choice to determine which name domain the device 479 and server take. 481 6. TLS Client and Server Handshake Behavior 483 When IBS is used as RAW public for TLS, signature and hash algorithms 484 are negotiated during the handshake. 486 The handshake between the TLS client and server follows the 487 procedures defined in [RFC 8446], but with the support of the new 488 signature algorithms specific to the IBS algorithms. The high-level 489 message exchange in the following figure shows TLS handshake using 490 raw public keys, where the client_certificate_type and 491 server_certificate_type extensions added to the client and server 492 hello messages (see Section 4 of [RFC 7250]). 494 client_hello, 495 +key_share 496 +signature_algorithms 497 client_certificate_type, 498 server_certificate_type -> 500 <- server_hello, 501 + key_share 502 {EncryptyedExtensions} 503 {client_certificate_type} 504 {server_certificate_type} 505 {Certificate} 506 {CertificateVerify} 507 {CertificateRequest} 508 {Finished} 509 [Applicaiton Data] 510 {Certificate} 511 {CertificateVerify} 512 {Finished} --------> 513 [Application Data} <-------> [Application Data] 515 Figure 13: Basic Raw Public Key TLS Exchange 517 The client hello messages tells the server the types of certificate 518 or raw public key supported by the client, and also the certificate 519 types that client expects to receive from server. When raw public 520 with IBS algorithm from server is supported by the client, the client 521 includes desired IBS signature algorithm in the client hello message 522 based on the order of client preference. 524 After receiving the client hello message, server determines the 525 client and server certificate types for handshakes. When the 526 selected certificate type is RAW public key and IBS is the chosen 527 signature algorithm, server uses the SubjectPublicKeyInfo structure 528 to carry the raw public key, OID for IBS algorithm. Assuming that 529 ECCSI is selected, the ECCSIPublicParameters data strucutre is used 530 to carry global public parameters. With these information, the 531 client knows the signature algorithm and the public parameters that 532 should be used to verify the signature. The signature value is in 533 the CertificateVerify message and the format of signature value is 534 specified by the selected IBS algorithm. The data structures for PKG 535 public parameters and signature values have been specified in the 536 previous section of this document. 538 When sever specifies that RAW public key should be used by client to 539 authenticate with server, the client_certificate_type in the server 540 hello is set to RawPublicKey. Besides that, the server also sends 541 Certificate Request, indicating that client should use some specific 542 signature and hash algorithms. When IBS is chosen as signature 543 algorithm, the server need to indicate the required IBS signature 544 algorithms in the signature_algorithm extension within the 545 CertificateRequest. 547 After receiving the server hello, the client checks the 548 CertificateRequest for signature algorithms. If client wants to use 549 an IBS algorithm for signature, then the signature algorithm it 550 intended to use must be in the list of supported signature algorithms 551 specified by the server. Assume the IBS algorithm supported by the 552 client is in the list, then the client response with the IBS 553 signature algorithm and PKG information with SubjectPublicKeyInfo 554 structure in the certificate structure and provide signatures in the 555 certificate verify message. The format of signature in the 556 CertificateVerify message should be specified by each individual 557 signature algorithm. 559 The server verifies the signature based on the chosen IBS algorithm 560 and the relevant PKG parameters specified by the client. 562 7. Examples 564 In the following, examples of handshake exchange using IBS algorithm 565 under RawPublicKey are illustrated. 567 7.1. TLS Client and Server Use IBS algorithm 569 In this example, both the TLS client and server use ECCSI for 570 authentication, and they are restricted in that they can only process 571 ECCSI signature algorithm. As a result, the TLS client sets both the 572 server_certificate_type and the client_certificate_type extensions to 573 be raw public key; in addition, the client sets the signature 574 algorithm in the client hello message to be eccsi_sha256. 576 When the TLS server receives the client hello, it processes the 577 message. Since it has an ECCSI raw public key from the PKG, it 578 indicates in (2) that it agrees to use ECCSI and provides an ECCSI 579 key by placing the SubjectPublicKeyInfo structure into the 580 Certificate payload back to the client (3), including the OID, the 581 identity of server, ServerID, which is the public key of server also, 582 and hash value of PKG public parameters. The client_certificate_type 583 in (4) indicates that the TLS server accepts raw public key. The TLS 584 server demands client authentication, and therefore includes a 585 certificate_request(5), which requires the client to use eccsi_sha256 586 for signature. A signature value based on the eccsi_sha256 algorithm 587 is carried in the CertificateVerify (6). The client, which has an 588 ECCSI key, returns its ECCSI public key in the Certificate payload to 589 the server (7), which includes an OID for the ECCSI signature 590 algorithm, the PKGInfo for KMS parameters, and identity of client, 591 ClientID, which is the public key of client also. The client also 592 includes a signature value, ECCSI-Sig-Value, in the CertificateVerify 593 (8) message. 595 When client/server receive PKG public parameters from peer, it should 596 decide whether these parameters are acceptable or not. An exmaple 597 way to make decision is that a whitelist of acceptable PKG public 598 parameters are stored locally at client/server. They can simply make 599 a decision based on the white list stored locally. 601 client_hello, 602 +key_share //(1) 603 signature_algorithm = (eccsi_sha256) //(1) 604 client_certificate_type=(RawPublicKey) //(1) 605 server_certificate_type=(RawPublicKey) //(1) 606 -> 607 <- server_hello, 608 + key_share 609 { server_certificate_type = RawPublicKey} //(2) 610 {certificate=((1.3.6.1.5.5.7.6.29, hash 611 value of ECCSIPublicParameters), 612 serverID)} //(3) 613 {client_certificate_type = RawPublicKey //(4) 614 {certificate_request = (eccsi_sha256)} //(5) 615 {CertificateVerify = {ECCSI-Sig-Value} //(6) 616 {Finishaed} 618 {Certificate=( 619 (1.3.6.1.5.5.7.6.29, 620 hash value of ECCSIPublicParameters), 621 ClientID)} //(7) 622 {CertificatVerify = (ECCSI-Sig-Value)} //(8) 623 {Finished } 624 [Applicateion Data] ----> 625 [Application Data] <---> [Application Data] 627 Figure 14: Basic Raw Public Key TLS Exchange 629 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 631 This example combines the uses of an ECCSI key and an X.509 632 certificate. The TLS client uses an ECCSI key for client 633 authentication, and the TLS server provides an X.509 certificate for 634 server authentication. 636 The exchange starts with the client indicating its ability to process 637 a raw public key, or an X.509 certificate, if provided by the server. 639 It prefers a raw public key with ECCSI signature algorithm since 640 eccsi_sha256 preceeds the ecdsa_secp256r1_sha256. Furthermore, the 641 client indicates that it has a ECCSI-based raw public key for client- 642 side authentication. Client also indicate it supports server using 643 either ECCSI or ecdsa_secp256r1_sha256 for the certificate signature. 644 This further indicates that server can use ecdsa_secp256r1_sha256 to 645 sign the message. 647 With the received client_hello, the server chooses to provide its 648 X.509 certificate in (3) and indicates that choice in (2). For 649 client authentication, the server indicates in (4) that it has 650 selected the raw public key format and requests an ECCSI certificate 651 from the client in (4) and (5). The TLS client provides an ECSSI 652 certificate in (6) and signature value after receiving and processing 653 the TLS server hello message. 655 client_hello, 656 +key_share 657 signature_algorithms =(eccsi_sha256, 658 ecdsa_secp256r1_sha256) //(1) 659 signature_algorithms_cert = ( 660 eccsi_sha256, ecdsa_secp256r1_sha256) //(1) 661 {client_certificate_type= 662 (RawPublicKey)} //(1) 663 {server_certificate_type= 664 (RawPublicKey, X.509) //(1) 665 -> 666 <- server_hello, 667 +key_share 668 {server_certificate_type=X.509} //(2) 669 {Certificate = (x.509 certificate)} //(3) 670 {client_certificate_type = (RawPublicKey)}//(4) 671 {CertificateRequest} = (eccsi_sha256)} //(5) 672 {CertificateVerify} 673 {Finished} 674 certificate=( 675 (1.3.6.1.5.5.7.6.29, 676 ECCSIPublicParameters), 677 ClientID), //(6) 678 {CertificatVerify = 679 (ECCSI-Sig-Value)} //(7) 680 { Finished } 681 [Applicateion Data] ----> 682 [Application Data] <---> [Application Data] 684 Figure 15: Basic Raw Public Key TLS Exchange 686 Handshake for other IBS algorithms can be completed similarly by 687 including different data structures for public parameters and 688 signature values respectively. 690 8. Security Considerations 692 Using IBS-based raw public key in TLS/DTLS does not change the 693 message flows of TLS, hence, for the most part, the security 694 considerations involved in using the Transport Layer Security 695 protocol with raw public key also apply here. The additional 696 security of the resulting protocol rests on the security of the used 697 IBS algorithms. 699 IBS signature algorithm has been standardized for ten years and has 700 been adopted in real applications. However, we would like to point 701 out the difference between IBS signature algorithm and existing raw 702 public key: the private key of IBS used for signature generation is 703 generated by the PKG centre, while the private key for the existing 704 raw public key is generated locally. Therefore, IBS mechanism may 705 face a security risk of private key disclosure due to improper 706 management of KMS system. The entity using IBS with TLS protocol 707 shall be aware the above risk and an enforced key management system 708 shall be adopted by the organization. 710 When using IBS algorithm, key escrow is an concern as the private key 711 of user or devices normally is generated by PKG. PKG in the system 712 which could generate each device's private key. However, when IBS is 713 used in TLS1.3, passively attack to recover the session key is not 714 possible. Actively man-in-the-middle attack by replacing exchanged 715 DH tokens and signatures would certainly leave traces even 716 transiently. Similarly, a PKG could impersonate an entity to conduct 717 a TLS session, just as the KMS in the symmetric key solution, but 718 forensic traces could be also collected in this situation. It would 719 be hugely risky for a PKG, which would usually be a trusted party, to 720 launch such attacks. If such an attack is caught in red-handed, no 721 one would trust the PKG's service anymore. 723 Another worry of using IBS is about the compromising of PKG. The PKG 724 could become operationally compromised and an attacker may obtain 725 master secrets of a PKG. However, this security risk can be solved 726 by protect the PKG with HSM, which is often used by CA to protect the 727 root signning key. 729 Private key compromising is one security risk that need to be 730 considered when using public key technology. When using IBS for raw 731 public, as we have suggested in this document, a revocation list 732 shall be maintained at the server side. At the same time, a 733 timestamp shall be included in the public key to prevent the 734 revocation list from keeping on increasing. With the revocation 735 list, server can prevent following attacks: 737 1) when a device using a revoked identifier for authentication, which 738 has not been expired yet, then the server can reject the TLS session 739 by checking the revocation list maintained at the server side. As it 740 is in the list, then the server aborts the TLS handshake. 742 2) When a device using a identifier which has been expired, the 743 server can simply verify the timestamp contained in the identifier 744 and abort the handshake procedure immediately. 746 3) If the attacker changes the timestemp within the identifier, then 747 it will cause signature verification error when server verify the 748 siganture contained in the signature_verify from client. 750 9. IANA Considerations 752 IANA is requested to assign 4 code points from the TLS 753 SignatureScheme registry with the following descriptions: 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, 831 < >. 833 Authors' Addresses 835 Haiguang Wang (editor) 836 Huawei International Pte. Ltd. 837 11 North Buona Vista Dr, #17-08 838 Singapore 138589 839 SG 841 Phone: +65 6825 4200 842 Email: wang.haiguang1@huawei.com 844 Yanjiang Yang 845 Huawei International Pte. Ltd. 846 11 North Buona Vista Dr, #17-08 847 Singapore 138589 848 SG 850 Phone: +65 6825 4200 851 Email: yang.yanjiang@huawei.com 853 Xin Kang 854 Huawei International Pte. Ltd. 855 11 North Buona Vista Dr, #17-08 856 Singapore 138589 857 SG 859 Phone: +65 6825 4200 860 Email: xin.kang@huawei.com 862 Zhaohui Cheng 863 Shenzhen Olym Info. Security Tech. Ltd. 864 Futong Haowangjiao Podium Building 865 Shenzhen, Guang Dong Province 518101 866 CN 868 Phone: +86 755 8618 2108 869 Email: chenzh@myibc.net