idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-11.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 (October 10, 2019) is 1654 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 493, but not defined == Missing Reference: 'RFC 8446' is mentioned on line 488, but not defined == Missing Reference: 'RFC 6507' is mentioned on line 103, but not defined == Missing Reference: 'RFC 5091' is mentioned on line 126, but not defined -- Looks like a reference, but probably isn't: '2' on line 295 == Missing Reference: 'RFC 5901' is mentioned on line 332, but not defined == Unused Reference: 'RFC2434' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC5091' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'RFC5480' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC6507' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 805, but no explicit reference was found in the text == Unused Reference: 'RFC8216' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 819, 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: April 12, 2020 Huawei International Pte. Ltd. 6 Z. Cheng 7 Shenzhen Olym Info. Security Tech. Ltd. 8 October 10, 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-11 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 April 12, 2020. 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 [TS33.501]. For IoT networks, TLS/DTLS with 95 RAW public key is particularly attractive, but binding identities 96 with public keys might be challenging. The cost to maintain a large 97 table for identity and public key mapping at server side incurs 98 additional maintenance cost, e.g. devices have to pre-register to the 99 server. 101 To simplify the binding between the public key and the entity, a 102 better way could be using Identity-Based Cryptography(IBC), such as 103 ECCSI public key specified in [RFC 6507], for authentication. 104 Different from X.509 certificates and raw public keys, a public key 105 in IBC takes the form of the entity's identity. This eliminates the 106 necessity of binding between a public key and the entity presenting 107 the public key. 109 The concept of IBC was first proposed by Adi Shamir in 1984. As a 110 special class of public key cryptography, IBC uses a user's identity 111 as public key, avoiding the hassle of public key certification in 112 public key cryptosystems. IBC broadly includes IBE (Identity-based 113 Encryption) and IBS (Identity-based Signature). For an IBC system to 114 work, there exists a trusted third party, PKG (private key generator) 115 responsible for issuing private keys to the users. In particular, 116 the PKG has in possession a pair of Master Public Key and Master 117 Secret Key; a private key is generated based on the user's identity 118 by using the Master Secret key, while the Master Public key is used 119 together with the user's identities for encryption (in case of IBE) 120 and signature verification (in case of IBS). Another name of PKG is 121 Key Management System (KMS), which is also used in some IBC system. 122 In this document, the terms of PKG and KMS are interchangeable. 124 A number of IBE and IBS algorithms have been standardized by 125 different standardization bodies, such as IETF, IEEE, ISO, etc. For 126 example, IETF has specified several RFCs such as [RFC 5091], [RFC 127 6507] and [RFC6508] for both IBE and IBS algorithms. ISO and IEEE 128 also have a few standards on IBC algorithms, such as IBS1, IBS2, and 129 ChineseIBS. 131 RFC 7250 has specified the use of raw public key with TLS/DTLS 132 handshake. However, supporting of IBS algorithms has not been 133 included therein. Since IBS algorithms are efficient in public key 134 transmission and also eliminate the binding between public keys and 135 identities, in this document, an amendment is added for supporting 136 IBS algorithms as raw public key. 138 IBS algorithm exempts client and server from public key certification 139 and identity binding by checking an entity's signatures and its 140 identity against the master public key of its PKG. With an IBS 141 algorithm, a PKG generates private keys for entities based on their 142 identities. Global parameters such as PKG's Master Public Key (MPK) 143 need be provisioned to both client and server. These parameters are 144 not user specific, but PKG specific. 146 For a client, PKG specific parameters can be provisioned at the time 147 PKG provisions the private key to the client. For the server, how to 148 get the PKG specific parameters provisioned is out of the scope of 149 this document, and it is deployment dependent. 151 The document is organized as follows: Section 3 defines the data 152 structure required when identity is used as raw public key. 153 Section 4 defines the cipher suites required to support IBS algorithm 154 over TLS/DTLS. Section 5 explains how client and server authenticate 155 each other when using identity as raw public key. Section 6 gives 156 examples for using identity as raw public key over TLS/DTLS handshake 157 procedure. Section 7 discusses the security considerations. 159 2. Terms 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals. 167 3. Extension of RAW Public Key to IBC-based Public Key 169 To support the negotiation of using raw public between client and 170 server, a new certificate structure is defined in RFC 7250. It is 171 used by the client and server in the hello messages to indicate the 172 types of certificates supported by each side. 174 When RawPublicKey type is selected for authentication, a data 175 structure, subjectPublicKeyInfo, is used to carry the raw public key 176 and its cryptographic algorithm. Within the subjectPublicKeyInfo 177 structure, two fields, algorithm and subjectPublicKey, are defined. 178 The algorithm is a data structure that specifies the cryptographic 179 algorithm used with raw public key, which is represented by an object 180 Identifiers (OID); and the parameters field provides necessary 181 parameters associated with the algorithm. The subjectPublicKey field 182 within the subjectPublicKeyInfo carries the raw public itself. 184 subjectPublicKeyInfo ::= SEQUENCE { 185 algorithm AlgorithmIdentifier, 186 subjectPublicKey BIT STRING 187 } 189 AlgorithmIdentifier ::= SEQUENCE { 190 algorithm OBJECT IDENTIFIER, 191 parameters ANY DEFINED BY algorithm OPTIONAL 192 } 194 Figure 1: SubjectPublicKeyInfo ASN.1 Structure 196 With IBS algorithm, identity is used as the raw public key, which can 197 be converted to an BIT string and put into the subjectPublicKey 198 field. The algorithm field in AlgorithmIdentifier structure is the 199 object identifier of the IBS algorithm used. Specifically, for the 200 ECCSI signature algorithm supported in this draft, the OBJECT 201 IDENTIFIER is described with following data structure: 203 sa-eccsiWithSHA256 SIGNATURE-ALGORITHM ::= { 204 IDENTIFIER id-alg-eccsi-with-sha256 205 VALUE ECCSI-Sig-Value PARAMS TYPE NULL ARE absent 206 HASHES { mda-sha256 } 207 SMIME-CAPS { IDENTIFIED BY id-alg-eccsi-with-sha256 } 208 } 210 Figure 2: ECCSI Signature Algorithm ANSI.1 Structure 212 Note, in a real implementation, only IDENTIFIER part will be 213 transmitted over the TLS negotiation protocols. 215 Beside OID, it is necessary to tell the peer the set of global 216 parameters used by the signer. The information can be carried in the 217 payload of the parameters field in AlgorithmIdentifier. On the other 218 hand, when IBS algorithm is used for authentication, normally the 219 global parameters in use are known to client and server, hence, 220 instead of transmitting a full set of PKG public parameters, a hash 221 value of them is transmitted, which is put in the prameters field of 222 AlgorithmIdentifier data structure. 224 The data strcuture used to carry the hash value of public parameters 225 is defined as follows: 227 IBSPublicParametersHash ::= SEQUENCE { 228 HASHES { mda-sha256 } 229 } 231 Figure 3: IBS Global Parameters Hash ANSI.1 Structure 233 The hash value of the global parameters is generated by taking in the 234 DER encoded PKG public parameters of each individual IBS algorithms 235 as input. The data structure for each IBS algorithms supported in 236 this draft are defined in the following. 238 For the ECCSI IBS signature algorithms, its PKG public parameters is 239 specified in following Figure : 241 ECCSIPublicParameters ::= SEQUENCE { 242 version INTEGER { v2(2) }, 243 curve OBJECT IDENTIFIER, 244 hashfcn OBJECT IDENTIFIER, 245 pointP FpPOINT, 246 pointPpub FpPOINT 247 } 249 FpPoint ::= SEQUENCE { 250 x INTEGER, 251 y INTEGER 252 } 254 Figure 4: ECCSI Global Parameters ANSI.1 Structure 256 The structure to carry the ISO-IBS1/ISO-IBS2 PKG public parameters 257 are the same and is specified in followng Figure : 259 ISOIBSPublicParameters ::= SEQUENCE { 260 version INTEGER { v3(3) }, 261 curve OBJECT IDENTIFIER, 262 hashfcn OBJECT IDENTIFIER, 263 pairing PAIRING OPTIONAL, 264 p INTEGER OPTIONAL, 265 q INTEGER OPTIONAL, 266 pointP FpPoint, 267 pointPpub FpPoint 268 } 270 PAIRING ::= ENUMERATED{ 271 weil (1) --Weil pairing 272 tate (2) --Tate pairing 273 optimalAte (3) --Optimal Ate pairing 274 } 276 Figure 5: ISO-IBS1/IBS2 Global Parameters ANSI.1 Structure 278 The structure to carry the ISO-SM9 PKG public parameters is specified 279 in following Figure : 281 SM9PublicParameters ::= SEQUENCE { 282 version INTEGER { v3(3) }, 283 curve OBJECT IDENTIFIER, 284 hashfcn OBJECT IDENTIFIER, 285 pairing PAIRING OPTIONAL, 286 p INTEGER OPTIONAL, 287 q INTEGER OPTIONAL, 288 pointP2 FpxPoint, 289 pointP2pub FpxPoint, 290 y FpxElement 291 } 293 FpxPoint ::= CHOICE{ 294 fpPoint FpPoint, 295 fp2Point [2] EXPLICIT Fp2Point, 296 } 298 Fp2Point ::= SEQUENCE{ 299 x Fp2Element, 300 y Fp2Element 301 } 303 Fp2Element ::= SEQUENCE{ 304 a INTEGER, 305 b INTEGER 306 } 308 FpxElement ::= CHOICE{ 309 fp2Elemt Fp2Element, 310 fp12Elemt Fp12Element, 311 } 313 Fp12Element ::= SEQUENCE{ 314 a Fp6Element, 315 b Fp6Element 316 } 318 Fp6Element ::= SEQUENCE{ 319 a Fp2Element, 320 b Fp2Element, 321 c Fp2Element 322 } 324 Figure 6: ISO-ChineseIBS Global Parameters ANSI.1 Structure 326 For ECCSIPublicParameters data structure, pointP shall be G in RFC 327 6507 and pointPpub shall be KPAK in RFC 6507. For 328 ISOIBSPublicParameters data structure, pointP and pointPpub shall be 329 the same as defined in RFC 5091, and the pairing field shall be weil 330 (1) or tate (2). The pairing field in SM9PublicParameters should be 331 optimalAte (3) and the choice of v should be determined by the curve 332 identifier. For example, for supersingular curves [RFC 5901], v 333 shall be of type Fp2Element and for BN curves or BLS12-curves 334 [FST10], v shall be of type Fp12Element. 336 To support IBS algorithm over TLS protocol, a data structure for 337 signature value need to be defined. 339 Data structure for ECCSI is defined as follows(based RFC 6507): 341 ECCSI-Sig-Value ::= SEQUENCE { 342 r INTEGER, 343 s INTEGER, 344 PVT OCTET STRING 345 } 347 Figure 7: ECCSI Signature Value ANSI.1 Structure 349 where PVT (as defined in RFC 6507) is encoded as 0x04 || x-coordinate 350 of [v]G || y-coordinate of [v]G. 352 Data structure for ISO-IBS1 is defined as follows: 354 ISO-IBS1-Sig-Value ::= SEQUENCE { 355 r INTEGER, 356 s ECPoint 357 } 359 Figure 8: ISO-IBS1 Signature Value ANSI.1 Structure 361 Data structure for ISO-IBS2 is defined as follows: 363 ISO-IBS2-Sig-Value ::= SEQUENCE { 364 r INTEGER, 365 s ECPoint 366 } 368 Figure 9: ISO-IBS2 Signature Value ANSI.1 Structure 370 Data structure for ISO-ChineseIBS (SM9) is defined as follows: 372 SM9-Sig-Value ::= SEQUENCE { 373 r INTEGER, 374 s ECPoint 375 } 377 Figure 10: ISO-ChineseIBS Signature Value ANSI.1 Structure 379 The definition of ECPoint can be found in section 2.2 of RFC 5480. 381 To use a signature algorithm with TLS, OID for the signature 382 algorithm need be provided. For ECCSI algorithm, an OID has been 383 assigned by IANA recently. The following table shows the basic 384 information needed for the ECCSI signature algorithm to be used for 385 TLS. 387 +--------------------------+----------------+-----------------------+ 388 | Key Type | Document | OID | 389 +--------------------------+----------------+-----------------------+ 390 | ISO/IEC 14888-3 IBS-1 | ISO/IEC | 1.0.14888.3.0.7 | 391 | | 14888-3: IBS-1 | | 392 | | mechanism | | 393 +--------------------------+----------------+-----------------------+ 394 | ISO/IEC 14888-3 IBS-2 | ISO/IEC | 1.0.14888.3.0.8 | 395 | | 14888-3: IBS-2 | | 396 | | mechanism | | 397 +--------------------------+----------------+-----------------------+ 398 | ISO/IEC 14888-3 | ISO/IEC | 1.2.156.10197.1.302.1 | 399 | ChineseIBS(SM9) | 14888-3: | | 400 | | ChineseIBS | | 401 | | mechanism | | 402 +--------------------------+----------------+-----------------------+ 403 | Elliptic Curve-Based | Section 5.2 in | 1.3.6.1.5.5.7.6.29 | 404 | Signatureless For | RFC 6507 | | 405 | Identitiy-based | | | 406 | Encryption (ECCSI) | | | 407 +--------------------------+----------------+-----------------------+ 409 Table 1: Algorithm Object Identifiers 411 4. New Signature Algorithms for IBS 413 To using identity as raw public key, new signature algorithms 414 corresponding to the IBS need to be defined. With TLS 1.3, the value 415 for signature algorithm is defined in the SignatureScheme. This 416 document specifies how to support IBS algorithm. As a reult, the 417 SignatureScheme data structure has to be amended by including the 418 presented IBS algorithms. 420 enum { 421 ... 423 /* IBS ECCSI signature algorithm */ 424 eccsi_sha256 (TBD), 425 iso_ibs1 (TBD), 426 iso_ibs2 (TBD), 427 iso_chinese_ibs (TBD), 429 /* Reserved Code Points */ 430 private_use (0xFE00..0xFFFF), 431 (0xFFFF) 432 } SignatureScheme; 434 Figure 11: Include IBS in KeyExchangeAlgorithm 436 Note: The signature algorithm of eccsi_sha256 is defined in RFC6507. 438 Note: Other IBS signature algorithms can be added in the future. 440 5. Identity Fromat and Key Revocation 442 With the raw public scheme proposed in TLS 1.3 [RFC 8446], server 443 maintains a whitlist to bind raw public key and identity. When a raw 444 public key is revoked, then server removes the binding record from 445 the whitelist. On the other hand, when using IBS agorithm for raw 446 public key, there is no whitelist at server side. Instead, the 447 server need to maintain a blacklist, which is much shorter than the 448 whitelist, to support public key revoication. However, if we simply 449 using the identifier as raw public key, the revocation list may keep 450 on increasing with the time going on. Hence, to prevent the 451 revocation list from increasing continuously, it is recommended to 452 include a timestamp for automatic expiration of key material. With 453 the timestamp included in the identifier, i.e. the raw public key, 454 server can remove revoked raw public key from revocation list when it 455 is expired. 457 Based on the above anaysis, it is necessary to include expiration 458 time in the identifiers for the purpose of public key management. 459 Therefore, in this draft, we recommend both client and server take 460 following format for the identifiers used for TLS session setup: 462 Identifier ::= SEQUENCE { 463 version INTEGER {v1 (1)}, 464 identity String, 465 expiration UTCTime 466 } 468 Figure 12: Identifier Format ANSI.1 Structure 470 Both the client and server should check the validity of the 471 expiration field of the raw public key before verify the signature. 472 If the expiration time is invalid, the client or the server should 473 abort the handshake procedure. 475 The identities of client or server shall be unique within the domain 476 managed by one PKG. There are many different identities domains such 477 as email address, telephone number, Network Access Identifier (NAI), 478 International Mobile Subscriber Identity (IMSI) etc. It is up to 479 network operators's choice to determine which name domain the device 480 and server take. 482 6. TLS Client and Server Handshake Behavior 484 When IBS is used as RAW public for TLS, signature and hash algorithms 485 are negotiated during the handshake. 487 The handshake between the TLS client and server follows the 488 procedures defined in [RFC 8446], but with the support of the new 489 signature algorithms specific to the IBS algorithms. The high-level 490 message exchange in the following figure shows TLS handshake using 491 raw public keys, where the client_certificate_type and 492 server_certificate_type extensions added to the client and server 493 hello messages (see Section 4 of [RFC 7250]). 495 client_hello, 496 +key_share 497 +signature_algorithms 498 client_certificate_type, 499 server_certificate_type -> 501 <- server_hello, 502 + key_share 503 {EncryptyedExtensions} 504 {client_certificate_type} 505 {server_certificate_type} 506 {Certificate} 507 {CertificateVerify} 508 {CertificateRequest} 509 {Finished} 510 [Applicaiton Data] 511 {Certificate} 512 {CertificateVerify} 513 {Finished} --------> 514 [Application Data} <-------> [Application Data] 516 Figure 13: Basic Raw Public Key TLS Exchange 518 The client hello messages tells the server the types of certificate 519 or raw public key supported by the client, and also the certificate 520 types that client expects to receive from server. When raw public 521 with IBS algorithm from server is supported by the client, the client 522 includes desired IBS signature algorithm in the client hello message 523 based on the order of client preference. 525 After receiving the client hello message, server determines the 526 client and server certificate types for handshakes. When the 527 selected certificate type is RAW public key and IBS is the chosen 528 signature algorithm, server uses the SubjectPublicKeyInfo structure 529 to carry the raw public key, OID for IBS algorithm. Assuming that 530 ECCSI is selected, the ECCSIPublicParameters data strucutre is used 531 to carry global public parameters. With these information, the 532 client knows the signature algorithm and the public parameters that 533 should be used to verify the signature. The signature value is in 534 the CertificateVerify message and the format of signature value is 535 specified by the selected IBS algorithm. The data structures for PKG 536 public parameters and signature values have been specified in the 537 previous section of this document. 539 When sever specifies that RAW public key should be used by client to 540 authenticate with server, the client_certificate_type in the server 541 hello is set to RawPublicKey. Besides that, the server also sends 542 Certificate Request, indicating that client should use some specific 543 signature and hash algorithms. When IBS is chosen as signature 544 algorithm, the server need to indicate the required IBS signature 545 algorithms in the signature_algorithm extension within the 546 CertificateRequest. 548 After receiving the server hello, the client checks the 549 CertificateRequest for signature algorithms. If client wants to use 550 an IBS algorithm for signature, then the signature algorithm it 551 intended to use must be in the list of supported signature algorithms 552 specified by the server. Assume the IBS algorithm supported by the 553 client is in the list, then the client response with the IBS 554 signature algorithm and PKG information with SubjectPublicKeyInfo 555 structure in the certificate structure and provide signatures in the 556 certificate verify message. The format of signature in the 557 CertificateVerify message should be specified by each individual 558 signature algorithm. 560 The server verifies the signature based on the chosen IBS algorithm 561 and the relevant PKG parameters specified by the client. 563 7. Examples 565 In the following, examples of handshake exchange using IBS algorithm 566 under RawPublicKey are illustrated. 568 7.1. TLS Client and Server Use IBS algorithm 570 In this example, both the TLS client and server use ECCSI for 571 authentication, and they are restricted in that they can only process 572 ECCSI signature algorithm. As a result, the TLS client sets both the 573 server_certificate_type and the client_certificate_type extensions to 574 be raw public key; in addition, the client sets the signature 575 algorithm in the client hello message to be eccsi_sha256. 577 When the TLS server receives the client hello, it processes the 578 message. Since it has an ECCSI raw public key from the PKG, it 579 indicates in (2) that it agrees to use ECCSI and provides an ECCSI 580 key by placing the SubjectPublicKeyInfo structure into the 581 Certificate payload back to the client (3), including the OID, the 582 identity of server, ServerID, which is the public key of server also, 583 and hash value of PKG public parameters. The client_certificate_type 584 in (4) indicates that the TLS server accepts raw public key. The TLS 585 server demands client authentication, and therefore includes a 586 certificate_request(5), which requires the client to use eccsi_sha256 587 for signature. A signature value based on the eccsi_sha256 algorithm 588 is carried in the CertificateVerify (6). The client, which has an 589 ECCSI key, returns its ECCSI public key in the Certificate payload to 590 the server (7), which includes an OID for the ECCSI signature 591 algorithm, the PKGInfo for KMS parameters, and identity of client, 592 ClientID, which is the public key of client also. The client also 593 includes a signature value, ECCSI-Sig-Value, in the CertificateVerify 594 (8) message. 596 When client/server receive PKG public parameters from peer, it should 597 decide whether these parameters are acceptable or not. An exmaple 598 way to make decision is that a whitelist of acceptable PKG public 599 parameters are stored locally at client/server. They can simply make 600 a decision based on the white list stored locally. 602 client_hello, 603 +key_share //(1) 604 signature_algorithm = (eccsi_sha256) //(1) 605 client_certificate_type=(RawPublicKey) //(1) 606 server_certificate_type=(RawPublicKey) //(1) 607 -> 608 <- server_hello, 609 + key_share 610 { server_certificate_type = RawPublicKey} //(2) 611 {certificate=((1.3.6.1.5.5.7.6.29, hash 612 value of ECCSIPublicParameters), 613 serverID)} //(3) 614 {client_certificate_type = RawPublicKey //(4) 615 {certificate_request = (eccsi_sha256)} //(5) 616 {CertificateVerify = {ECCSI-Sig-Value} //(6) 617 {Finishaed} 619 {Certificate=( 620 (1.3.6.1.5.5.7.6.29, 621 hash value of ECCSIPublicParameters), 622 ClientID)} //(7) 623 {CertificatVerify = (ECCSI-Sig-Value)} //(8) 624 {Finished } 625 [Applicateion Data] ----> 626 [Application Data] <---> [Application Data] 628 Figure 14: Basic Raw Public Key TLS Exchange 630 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 632 This example combines the uses of an ECCSI key and an X.509 633 certificate. The TLS client uses an ECCSI key for client 634 authentication, and the TLS server provides an X.509 certificate for 635 server authentication. 637 The exchange starts with the client indicating its ability to process 638 a raw public key, or an X.509 certificate, if provided by the server. 640 It prefers a raw public key with ECCSI signature algorithm since 641 eccsi_sha256 preceeds the ecdsa_secp256r1_sha256. Furthermore, the 642 client indicates that it has a ECCSI-based raw public key for client- 643 side authentication. Client also indicate it supports server using 644 either ECCSI or ecdsa_secp256r1_sha256 for the certificate signature. 645 This further indicates that server can use ecdsa_secp256r1_sha256 to 646 sign the message. 648 With the received client_hello, the server chooses to provide its 649 X.509 certificate in (3) and indicates that choice in (2). For 650 client authentication, the server indicates in (4) that it has 651 selected the raw public key format and requests an ECCSI certificate 652 from the client in (4) and (5). The TLS client provides an ECSSI 653 certificate in (6) and signature value after receiving and processing 654 the TLS server hello message. 656 client_hello, 657 +key_share 658 signature_algorithms =(eccsi_sha256, 659 ecdsa_secp256r1_sha256) //(1) 660 signature_algorithms_cert = ( 661 eccsi_sha256, ecdsa_secp256r1_sha256) //(1) 662 {client_certificate_type= 663 (RawPublicKey)} //(1) 664 {server_certificate_type= 665 (RawPublicKey, X.509) //(1) 666 -> 667 <- server_hello, 668 +key_share 669 {server_certificate_type=X.509} //(2) 670 {Certificate = (x.509 certificate)} //(3) 671 {client_certificate_type = (RawPublicKey)}//(4) 672 {CertificateRequest} = (eccsi_sha256)} //(5) 673 {CertificateVerify} 674 {Finished} 675 certificate=( 676 (1.3.6.1.5.5.7.6.29, 677 ECCSIPublicParameters), 678 ClientID), //(6) 679 {CertificatVerify = 680 (ECCSI-Sig-Value)} //(7) 681 { Finished } 682 [Applicateion Data] ----> 683 [Application Data] <---> [Application Data] 685 Figure 15: Basic Raw Public Key TLS Exchange 687 Handshake for other IBS algorithms can be completed similarly by 688 including different data structures for public parameters and 689 signature values respectively. 691 8. Security Considerations 693 Using IBS-based raw public key in TLS/DTLS does not change the 694 message flows of TLS, hence, for the most part, the security 695 considerations involved in using the Transport Layer Security 696 protocol with raw public key also apply here. The additional 697 security of the resulting protocol rests on the security of the used 698 IBS algorithms. 700 IBS signature algorithm has been standardized for ten years and has 701 been adopted in real applications. However, we would like to point 702 out the difference between IBS signature algorithm and existing raw 703 public key: the private key of IBS used for signature generation is 704 generated by the PKG centre, while the private key for the existing 705 raw public key is generated locally. Therefore, IBS mechanism may 706 face a security risk of private key disclosure due to improper 707 management of KMS system. The entity using IBS with TLS protocol 708 shall be aware the above risk and an enforced key management system 709 shall be adopted by the organization. 711 When using IBS algorithm, key escrow is an concern as the private key 712 of user or devices normally is generated by PKG. PKG in the system 713 which could generate each device's private key. However, when IBS is 714 used in TLS1.3, passively attack to recover the session key is not 715 possible. Actively man-in-the-middle attack by replacing exchanged 716 DH tokens and signatures would certainly leave traces even 717 transiently. Similarly, a PKG could impersonate an entity to conduct 718 a TLS session, just as the KMS in the symmetric key solution, but 719 forensic traces could be also collected in this situation. It would 720 be hugely risky for a PKG, which would usually be a trusted party, to 721 launch such attacks. If such an attack is caught in red-handed, no 722 one would trust the PKG's service anymore. 724 Another worry of using IBS is about the compromising of PKG. The PKG 725 could become operationally compromised and an attacker may obtain 726 master secrets of a PKG. However, this security risk can be solved 727 by protect the PKG with HSM, which is often used by CA to protect the 728 root signning key. 730 Private key compromising is one security risk that need to be 731 considered when using public key technology. When using IBS for raw 732 public, as we have suggested in this document, a revocation list 733 shall be maintained at the server side. At the same time, a 734 timestamp shall be included in the public key to prevent the 735 revocation list from keeping on increasing. With the revocation 736 list, server can prevent following attacks: 738 1) when a device using a revoked identifier for authentication, which 739 has not been expired yet, then the server can reject the TLS session 740 by checking the revocation list maintained at the server side. As it 741 is in the list, then the server aborts the TLS handshake. 743 2) When a device using a identifier which has been expired, the 744 server can simply verify the timestamp contained in the identifier 745 and abort the handshake procedure immediately. 747 3) If the attacker changes the timestemp within the identifier, then 748 it will cause signature verification error when server verify the 749 siganture contained in the signature_verify from client. 751 9. IANA Considerations 753 IANA has assigned 4 code points from the TLS SignatureScheme registry 754 for the four IBS algorithms used in this document. The code poins 755 are listed as follows: 757 - eccsi_sha256 759 - iso_ibs1 761 - iso_ibs2 763 - iso_chinese_ibs 765 For all of these entries the Recommended field should be N, and the 766 Reference field should be this document. 768 10. Acknowledgements 770 11. References 772 11.1. Normative References 774 [PKIX] "Internet X.509 Public Key Infrastructure Certificate and 775 Certificate Revocation List(CRL) Profile", June 2008. 777 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 778 Requirement Levels", BCP 14, RFC 2119, 779 DOI 10.17487/RFC2119, March 1997, 780 . 782 [RFC2434] "Guidelines for Writing an IANA Consideration Section in 783 RFCs", October 1998. 785 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 786 Standard (IBCS) #1: Supersingular Curve Implementations of 787 the BF and BB1 Cryptosystems", RFC 5091, 788 DOI 10.17487/RFC5091, December 2007, 789 . 791 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 792 "Elliptic Curve Cryptography Subject Public Key 793 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 794 . 796 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 797 Signatures for Identity-Based Encryption (ECCSI)", 798 RFC 6507, DOI 10.17487/RFC6507, February 2012, 799 . 801 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 802 RFC 6508, DOI 10.17487/RFC6508, February 2012, 803 . 805 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 806 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 807 Transport Layer Security (TLS) and Datagram Transport 808 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 809 June 2014, . 811 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 812 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 813 May 2017, . 815 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 816 RFC 8216, DOI 10.17487/RFC8216, August 2017, 817 . 819 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 820 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 821 . 823 11.2. Informative References 825 [Defeating-SSL] 826 "New Tricks for Defeating SSL in Practice", Feb 2009, 827 . 831 [FST10] "A Taxonomy of Pairing-Friendly Elliptic Curves. Journal 832 of Cryptology. Volume 23, Issue 2, pp 224-280,", Apr 2010. 834 [TS33.501] 835 "TS 33.501, Security architecture and procedures for 5G 836 System, v.g.0.0", Sept 2019, 837 . 840 Authors' Addresses 842 Haiguang Wang (editor) 843 Huawei International Pte. Ltd. 844 11 North Buona Vista Dr, #17-08 845 Singapore 138589 846 SG 848 Phone: +65 6825 4200 849 Email: wang.haiguang1@huawei.com 851 Yanjiang Yang 852 Huawei International Pte. Ltd. 853 11 North Buona Vista Dr, #17-08 854 Singapore 138589 855 SG 857 Phone: +65 6825 4200 858 Email: yang.yanjiang@huawei.com 860 Xin Kang 861 Huawei International Pte. Ltd. 862 11 North Buona Vista Dr, #17-08 863 Singapore 138589 864 SG 866 Phone: +65 6825 4200 867 Email: xin.kang@huawei.com 868 Zhaohui Cheng 869 Shenzhen Olym Info. Security Tech. Ltd. 870 Futong Haowangjiao Podium Building 871 Shenzhen, Guang Dong Province 518101 872 CN 874 Phone: +86 755 8618 2108 875 Email: chenzh@myibc.net