idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-13.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 9, 2020) is 1295 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 487, but not defined == Missing Reference: 'RFC 8446' is mentioned on line 482, 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 289 == Missing Reference: 'RFC 5901' is mentioned on line 326, but not defined == Unused Reference: 'RFC2434' is defined on line 777, but no explicit reference was found in the text == Unused Reference: 'RFC5091' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'RFC5480' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'RFC6507' is defined on line 791, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'RFC8216' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 814, 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, 2021 Huawei International Pte. Ltd. 6 Z. Cheng 7 Shenzhen Olym Info. Security Tech. Ltd. 8 M. Chen 9 China Mobile 10 October 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-13 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 few Identity-based signature algorithms from different 23 standard organizations are supported in the current version. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 12, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Extension of RAW Public Key to IBC-based Public Key . . . . . 4 62 4. New Signature Algorithms for IBS . . . . . . . . . . . . . . 9 63 5. Identity Format and Key Revocation . . . . . . . . . . . . . 10 64 6. TLS Client and Server Handshake Behavior . . . . . . . . . . 11 65 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 7.1. TLS Client and Server Use IBS algorithm . . . . . . . . . 13 67 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 14 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 73 11.2. Informative References . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 DISCLAIMER: This is a personal draft and a limited security analysis 79 is provided. 81 Traditionally, TLS client and server exchange public keys endorsed by 82 PKIX [PKIX] certificates. It is considered complicated and may cause 83 security weaknesses with the use of PKIX certificates 84 [Defeating-SSL]. To simplify certificates exchange, using RAW public 85 key with TLS/DTLS has been specified in [RFC 7250] and has been 86 included in the TLS 1.3 [RFC 8446]. Instead of transmitting a full 87 certificate or a certificate chain in the TLS messages, only public 88 keys are exchanged between client and server. However, using RAW 89 public key requires out-of-band mechanisms to verify the purported 90 public key to the claimed entity. 92 Recently, 3GPP has adopted the EAP authentication framework for 5G 93 and EAP-TLS is considered as one of the candidate authentication 94 methods for private networks, especially for networks with a large 95 number of IoT devices [TS33.501]. For IoT networks, EAP-TLS with RAW 96 public key is particularly attractive, but binding identities with 97 public keys might be challenging. The cost to maintain a large table 98 for identity and public key mapping at server side incurs additional 99 cost, e.g. devices have to pre-register to the 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 existing raw public keys, a 105 public key in IBC takes the form of the entity's identity. This 106 eliminates the necessity of binding between a public key and the 107 entity presenting 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, private key generator 115 (PKG), which is responsible for issuing private keys to the users. A 116 PKG has in possession a pair of Master Public Key and Master Secret 117 Key; a private key is generated based on the user's identity by using 118 the Master Secret key, while the Master Public key is used together 119 with the user's identities for encryption (in case of IBE) and 120 signature verification (in case of IBS). Another name of PKG is Key 121 Management System (KMS), which is also used in some IBC system. In 122 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 [ISO_IEC-IBS]. 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 eliminate the binding between 134 public keys and identities, this further simplifies the using of raw 135 public key with TLS. Therefore, in this document, an amendment is 136 added for supporting IBS algorithms when using raw public key. 138 With IBS algorithms, a PKG generates private keys for entities based 139 on identities from requestors. Global parameters such as PKG's 140 Master Public Key (MPK) are provisioned to both client and server. 141 These parameters are not user specific, but PKG specific. 143 For a client, PKG specific parameters can be provisioned at the time 144 PKG provisions the private key to the client. For the server, how to 145 get the PKG specific parameters provisioned is out of the scope of 146 this document, and it is deployment dependent. 148 The document is organized as follows: Section 3 defines the data 149 structure required when identity is used as raw public key. 150 Section 4 defines the cipher suites required to support IBS algorithm 151 over TLS/DTLS. Section 5 explains how client and server authenticate 152 each other when using identity as raw public key. Section 6 gives 153 examples for using identity as raw public key over TLS/DTLS handshake 154 procedure. Section 7 discusses the security considerations. 156 2. Terms 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in BCP 161 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals. 164 3. Extension of RAW Public Key to IBC-based Public Key 166 To support the negotiation of using raw public between client and 167 server, a new certificate structure is defined in RFC 7250. It is 168 used by the client and server in the hello messages to indicate the 169 types of certificates supported by each side. 171 When RawPublicKey type is selected for authentication, a data 172 structure, subjectPublicKeyInfo, is used to carry the raw public key 173 and its cryptographic algorithm. Within the subjectPublicKeyInfo 174 structure, two fields, algorithm and subjectPublicKey, are defined. 175 The algorithm is a data structure that specifies the cryptographic 176 algorithm used with raw public key, which is represented by an object 177 Identifiers (OID); and the parameters field provides necessary 178 parameters associated with the algorithm. The subjectPublicKey field 179 within the subjectPublicKeyInfo carries the raw public itself. 181 subjectPublicKeyInfo ::= SEQUENCE { 182 algorithm AlgorithmIdentifier, 183 subjectPublicKey BIT STRING 184 } 186 AlgorithmIdentifier ::= SEQUENCE { 187 algorithm OBJECT IDENTIFIER, 188 parameters ANY DEFINED BY algorithm OPTIONAL 189 } 191 Figure 1: SubjectPublicKeyInfo ASN.1 Structure 193 With IBS algorithm, identity is used as the raw public key, which can 194 be converted to an BIT string and put into the subjectPublicKey 195 field. The algorithm field in AlgorithmIdentifier structure is the 196 object identifier of the IBS algorithm used. Specifically, for the 197 ECCSI signature algorithm supported in this draft, the OBJECT 198 IDENTIFIER is described with following data structure: 200 sa-eccsiWithSHA256 SIGNATURE-ALGORITHM ::= { 201 IDENTIFIER id-alg-eccsi-with-sha256 202 VALUE ECCSI-Sig-Value PARAMS TYPE NULL ARE absent 203 HASHES { mda-sha256 } 204 SMIME-CAPS { IDENTIFIED BY id-alg-eccsi-with-sha256 } 205 } 207 Figure 2: ECCSI Signature Algorithm ANSI.1 Structure 209 Beside OID, it is necessary to tell the peer the set of global 210 parameters used by the signer. The information can be carried in the 211 payload of the parameters field in AlgorithmIdentifier. On the other 212 hand, when IBS algorithm is used for authentication, normally the 213 global parameters in use are known to client and server, hence, 214 instead of transmitting a full set of PKG public parameters, a hash 215 value of them is transmitted, which is put in the parameters field of 216 AlgorithmIdentifier data structure. 218 The data structure used to carry the hash value of public parameters 219 is defined as follows: 221 IBSPublicParametersHash ::= SEQUENCE { 222 HASHES { mda-sha256 } 223 } 225 Figure 3: IBS Global Parameters Hash ANSI.1 Structure 227 The hash value of the global parameters is generated by taking in the 228 DER encoded PKG public parameters of each individual IBS algorithms 229 as input. The data structure for each IBS algorithms supported in 230 this draft are defined in the following. 232 For the ECCSI IBS signature algorithms, its PKG public parameters is 233 specified in following Figure : 235 ECCSIPublicParameters ::= SEQUENCE { 236 version INTEGER { v2(2) }, 237 curve OBJECT IDENTIFIER, 238 hashfcn OBJECT IDENTIFIER, 239 pointP FpPOINT, 240 pointPpub FpPOINT 241 } 243 FpPoint ::= SEQUENCE { 244 x INTEGER, 245 y INTEGER 246 } 248 Figure 4: ECCSI Global Parameters ANSI.1 Structure 250 The structure to carry the ISO-IBS1/ISO-IBS2 PKG public parameters 251 are the same and is specified in following Figure : 253 ISOIBSPublicParameters ::= SEQUENCE { 254 version INTEGER { v3(3) }, 255 curve OBJECT IDENTIFIER, 256 hashfcn OBJECT IDENTIFIER, 257 pairing PAIRING OPTIONAL, 258 p INTEGER OPTIONAL, 259 q INTEGER OPTIONAL, 260 pointP FpPoint, 261 pointPpub FpPoint 262 } 264 PAIRING ::= ENUMERATED{ 265 weil (1) --Weil pairing 266 tate (2) --Tate pairing 267 optimalAte (3) --Optimal Ate pairing 268 } 270 Figure 5: ISO-IBS1/IBS2 Global Parameters ANSI.1 Structure 272 The structure to carry the ISO-SM9 PKG public parameters is specified 273 in following Figure : 275 SM9PublicParameters ::= SEQUENCE { 276 version INTEGER { v3(3) }, 277 curve OBJECT IDENTIFIER, 278 hashfcn OBJECT IDENTIFIER, 279 pairing PAIRING OPTIONAL, 280 p INTEGER OPTIONAL, 281 q INTEGER OPTIONAL, 282 pointP2 FpxPoint, 283 pointP2pub FpxPoint, 284 v FpxElement 285 } 287 FpxPoint ::= CHOICE{ 288 fpPoint FpPoint, 289 fp2Point [2] EXPLICIT Fp2Point, 290 } 292 Fp2Point ::= SEQUENCE{ 293 x Fp2Element, 294 y Fp2Element 295 } 297 Fp2Element ::= SEQUENCE{ 298 a INTEGER, 299 b INTEGER 300 } 302 FpxElement ::= CHOICE{ 303 fp2Elemt Fp2Element, 304 fp12Elemt Fp12Element, 305 } 307 Fp12Element ::= SEQUENCE{ 308 a Fp6Element, 309 b Fp6Element 310 } 312 Fp6Element ::= SEQUENCE{ 313 a Fp2Element, 314 b Fp2Element, 315 c Fp2Element 316 } 318 Figure 6: ISO-ChineseIBS Global Parameters ANSI.1 Structure 320 For ECCSIPublicParameters data structure, pointP shall be G in RFC 321 6507 and pointPpub shall be KPAK in RFC 6507. For 322 ISOIBSPublicParameters data structure, pointP and pointPpub shall be 323 the same as defined in RFC 5091, and the pairing field shall be weil 324 (1) or tate (2). The pairing field in SM9PublicParameters should be 325 optimalAte (3) and the choice of v should be determined by the curve 326 identifier. For example, for supersingular curves [RFC 5901], v 327 shall be of type Fp2Element and for BN curves or BLS12-curves 328 [FST10], v shall be of type Fp12Element. 330 To support IBS algorithm over TLS protocol, a data structure for 331 signature value need to be defined. 333 Data structure for ECCSI is defined as follows(based RFC 6507): 335 ECCSI-Sig-Value ::= SEQUENCE { 336 r INTEGER, 337 s INTEGER, 338 PVT OCTET STRING 339 } 341 Figure 7: ECCSI Signature Value ANSI.1 Structure 343 where PVT (as defined in RFC 6507) is encoded as 0x04 || x-coordinate 344 of [v]G || y-coordinate of [v]G. 346 Data structure for ISO-IBS1 is defined as follows: 348 ISO-IBS1-Sig-Value ::= SEQUENCE { 349 r INTEGER, 350 s ECPoint 351 } 353 Figure 8: ISO-IBS1 Signature Value ANSI.1 Structure 355 Data structure for ISO-IBS2 is defined as follows: 357 ISO-IBS2-Sig-Value ::= SEQUENCE { 358 r INTEGER, 359 s ECPoint 360 } 362 Figure 9: ISO-IBS2 Signature Value ANSI.1 Structure 364 Data structure for ISO-ChineseIBS (SM9) is defined as follows: 366 SM9-Sig-Value ::= SEQUENCE { 367 r INTEGER, 368 s ECPoint 369 } 371 Figure 10: ISO-ChineseIBS Signature Value ANSI.1 Structure 373 The definition of ECPoint can be found in section 2.2 of RFC 5480. 375 To use a signature algorithm with TLS, OID for the signature 376 algorithm need be provided. For ECCSI algorithm, an OID has been 377 assigned by IANA recently. The following table shows the basic 378 information needed for the ECCSI signature algorithm to be used for 379 TLS. 381 +--------------------------+----------------+-----------------------+ 382 | Key Type | Document | OID | 383 +--------------------------+----------------+-----------------------+ 384 | ISO/IEC 14888-3 IBS-1 | ISO/IEC | 1.0.14888.3.0.7 | 385 | | 14888-3: IBS-1 | | 386 | | mechanism | | 387 +--------------------------+----------------+-----------------------+ 388 | ISO/IEC 14888-3 IBS-2 | ISO/IEC | 1.0.14888.3.0.8 | 389 | | 14888-3: IBS-2 | | 390 | | mechanism | | 391 +--------------------------+----------------+-----------------------+ 392 | ISO/IEC 14888-3 | ISO/IEC | 1.2.156.10197.1.302.1 | 393 | ChineseIBS(SM9) | 14888-3: | | 394 | | ChineseIBS | | 395 | | mechanism | | 396 +--------------------------+----------------+-----------------------+ 397 | Elliptic Curve-Based | Section 5.2 | 1.3.6.1.5.5.7.6.29 | 398 | Signatureless For | in RFC 6507 | | 399 | Identitiy-based | | | 400 | Encryption (ECCSI) | | | 401 +--------------------------+----------------+-----------------------+ 403 Table 1: Algorithm Object Identifiers 405 4. New Signature Algorithms for IBS 407 To using identity as raw public key, new signature algorithms 408 corresponding to the IBS need to be defined. With TLS 1.3, the value 409 for signature algorithm is defined in the SignatureScheme. This 410 document specifies how to support IBS algorithm. As a result, the 411 SignatureScheme data structure has to be amended by including the 412 presented IBS algorithms. 414 enum { 415 ... 417 /* IBS ECCSI signature algorithm */ 418 eccsi_sha256 (0x0704), 419 iso_ibs1 (0x0705), 420 iso_ibs2 (0x0706), 421 iso_chinese_ibs (0x0707), 423 /* Reserved Code Points */ 424 private_use (0xFE00..0xFFFF), 425 (0xFFFF) 426 } SignatureScheme; 428 Figure 11: Include IBS in KeyExchangeAlgorithm 430 Note: The signature algorithm of eccsi_sha256 is defined in RFC6507. 432 Note: Other IBS signature algorithms can be added in the future. 434 5. Identity Format and Key Revocation 436 With the raw public scheme proposed in TLS 1.3 [RFC 8446], the server 437 maintains a whitelist to bind raw public key and identity. When a 438 raw public key is revoked, then the server removes the binding record 439 from the whitelist. On the other hand, when using IBS algorithms, it 440 is not necessary to maintain a whitelist at the server's side. 441 Instead, the server can simply maintain a blacklist, which is much 442 shorter than the whitelist. However, if we simply use the identifier 443 as a raw public key, the revocation list may keep on increasing with 444 the time going on. Hence, to prevent the revocation list from 445 increasing continuously, it is recommended to include a timestamp for 446 the automatic expiration of key material. With the timestamp 447 included in the identifier, i.e. the raw public key, server can 448 remove the revoked raw public key from the revocation list when it is 449 expired. 451 Based on the above analysis, it is necessary to include an expiration 452 time in the identifiers for the purpose of public key management. 453 Therefore, in this draft, we recommend both client and server take 454 following format for the identifiers used for TLS session setup: 456 Identifier ::= SEQUENCE { 457 version INTEGER {v1 (1)}, 458 identity String, 459 expiration UTCTime 460 } 462 Figure 12: Identifier Format ANSI.1 Structure 464 Both the client and server should check the validity of the 465 expiration field of the raw public key before verify the signature. 466 If the expiration time is invalid, the client or the server should 467 abort the handshake procedure. 469 The identities of client or server shall be unique within the domain 470 managed by one PKG. There are many different identities domains such 471 as email address, telephone number, Network Access Identifier (NAI), 472 International Mobile Subscriber Identity (IMSI) etc. It is up to 473 network operators' choice to determine which name domain the device 474 and server take. 476 6. TLS Client and Server Handshake Behavior 478 When RAW public is used with IBS for TLS, signature and hash 479 algorithms are negotiated during the handshake. 481 The handshake between the TLS client and server follows the 482 procedures defined in [RFC 8446], but with the support of the new 483 signature algorithms specific to the IBS algorithms. The high-level 484 message exchange in the following figure shows the TLS handshake 485 using raw public keys, where the client_certificate_type and 486 server_certificate_type extensions added to the client and server 487 hello messages (see Section 4 of [RFC 7250]). 489 client_hello, 490 +key_share 491 +signature_algorithms 492 client_certificate_type, 493 server_certificate_type -> 495 <- server_hello, 496 + key_share 497 {EncryptyedExtensions} 498 {client_certificate_type} 499 {server_certificate_type} 500 {Certificate} 501 {CertificateVerify} 502 {CertificateRequest} 503 {Finished} 504 [Applicaiton Data] 505 {Certificate} 506 {CertificateVerify} 507 {Finished} --------> 508 [Application Data} <-------> [Application Data] 510 Figure 13: Basic Raw Public Key TLS Exchange 512 The client hello message tells the server the types of certificate or 513 raw public key supported by the client, and also the certificate 514 types that the client expects to receive from the server. When raw 515 public with IBS algorithm from the server is supported by the client, 516 the client includes desired IBS signature algorithm in the client 517 hello message based on the order of client preference. 519 After receiving the client hello message, the server determines the 520 client and server certificate types for handshakes. When the 521 selected certificate type is RAW public key and IBS is the chosen 522 signature algorithm, the server uses the SubjectPublicKeyInfo 523 structure to carry the raw public key, OID for IBS algorithm and 524 public parameters or the hash value of public parameters. Assuming 525 that ECCSI is selected, the ECCSIPublicParameters data structure is 526 used to carry global public parameters. With this information, the 527 client knows the signature algorithm and the public parameters that 528 should be used to verify the signature. The signature value is in 529 the CertificateVerify message and the format of signature value is 530 specified by the selected IBS algorithm. The data structures for PKG 531 public parameters and signature values have been specified in the 532 previous section of this document. 534 When the sever specifies that RAW public key should be used by the 535 client to authenticate with the server, the client_certificate_type 536 in the server hello is set to RawPublicKey. Besides that, the server 537 also sends Certificate Request, indicating that client should use 538 some specific signature and hash algorithms. When IBS is chosen as 539 signature algorithm, the server need to indicate the required IBS 540 signature algorithms in the signature_algorithm extension within the 541 CertificateRequest. 543 After receiving the server hello, the client checks the 544 CertificateRequest for signature algorithms. If the client wants to 545 use an IBS algorithm for signature, then the signature algorithm it 546 intended to use must be in the list of supported signature algorithms 547 specified by the server. Assume the IBS algorithm supported by the 548 client is in the list, then the client responds with the IBS 549 signature algorithm and PKG information with SubjectPublicKeyInfo 550 structure in the certificate structure and provide signatures in the 551 certificate verify message. The format of signature in the 552 CertificateVerify message should be specified by each individual 553 signature algorithm. 555 The server verifies the signature based on the chosen IBS algorithm 556 and the relevant PKG parameters specified by the client. 558 7. Examples 560 In the following, examples of handshake exchange using IBS algorithm 561 under RawPublicKey are illustrated. 563 7.1. TLS Client and Server Use IBS algorithm 565 In this example, both the TLS client and server use ECCSI for 566 authentication, and they are restricted in that they can only process 567 ECCSI signature algorithm. As a result, the TLS client sets both the 568 server_certificate_type and the client_certificate_type extensions to 569 be raw public key; in addition, the client sets the signature 570 algorithm in the client hello message to be eccsi_sha256. 572 When the TLS server receives the client hello, it processes the 573 message. Since it has an ECCSI raw public key from the PKG, it 574 indicates in (2) that it agrees to use ECCSI and provides an ECCSI 575 key by placing the SubjectPublicKeyInfo structure into the 576 Certificate payload back to the client (3), including the OID, the 577 identity of the server, ServerID, which is the public key of the 578 server also, and the hash value of PKG public parameters. The 579 client_certificate_type in (4) indicates that the TLS server accepts 580 raw public key. The TLS server demands client authentication, and 581 therefore includes a certificate_request(5), which requires the 582 client to use eccsi_sha256 for signature. A signature value based on 583 the eccsi_sha256 algorithm is carried in the CertificateVerify (6). 584 The client, which has an ECCSI key, returns its ECCSI public key in 585 the Certificate payload to the server (7), which includes an OID for 586 the ECCSI signature algorithm, the PKGInfo for KMS parameters, and 587 identity of the client, ClientID, which is the public key of client 588 also. The client also includes a signature value, ECCSI-Sig-Value, 589 in the CertificateVerify (8) message. 591 When client/server receives PKG public parameters from peer, it 592 should decide whether these parameters are acceptable or not. An 593 example way to make decision is that a whitelist of acceptable PKG 594 public parameters are stored locally at client/server. They can 595 simply make a decision based on the white list stored locally. 597 client_hello, 598 +key_share //(1) 599 signature_algorithm = (eccsi_sha256) //(1) 600 client_certificate_type=(RawPublicKey) //(1) 601 server_certificate_type=(RawPublicKey) //(1) 602 -> 603 <- server_hello, 604 + key_share 605 { server_certificate_type = RawPublicKey} //(2) 606 {certificate=((1.3.6.1.5.5.7.6.29, hash 607 value of ECCSIPublicParameters), 608 serverID)} //(3) 609 {client_certificate_type = RawPublicKey //(4) 610 {certificate_request = (eccsi_sha256)} //(5) 611 {CertificateVerify = {ECCSI-Sig-Value} //(6) 612 {Finishaed} 614 {Certificate=( 615 (1.3.6.1.5.5.7.6.29, 616 hash value of ECCSIPublicParameters), 617 ClientID)} //(7) 618 {CertificatVerify = (ECCSI-Sig-Value)} //(8) 619 {Finished } 620 [Applicateion Data] ----> 621 [Application Data] <---> [Application Data] 623 Figure 14: Basic Raw Public Key TLS Exchange 625 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 627 This example combines the uses of an ECCSI key and an X.509 628 certificate. The TLS client uses an ECCSI key for client 629 authentication, and the TLS server provides an X.509 certificate for 630 server authentication. 632 The exchange starts with the client indicating its ability to process 633 a raw public key, or an X.509 certificate, if provided by the server. 634 It prefers a raw public key with ECCSI signature algorithm since 635 eccsi_sha256 precedes the ecdsa_secp256r1_sha256. Furthermore, the 636 client indicates that it has a ECCSI-based raw public key for client- 637 side authentication. The client also indicates that it supports the 638 server using either ECCSI or ecdsa_secp256r1_sha256 for the 639 certificate signature. This further indicates that the server can 640 use ecdsa_secp256r1_sha256 to sign the message. 642 With the received client_hello, the server chooses to provide its 643 X.509 certificate in (3) and indicates that choice in (2). For 644 client authentication, the server indicates in (4) that it has 645 selected the raw public key format and requests an ECCSI certificate 646 from the client in (4) and (5). The TLS client provides an ECSSI 647 certificate in (6) and signature value after receiving and processing 648 the TLS server hello message. 650 client_hello, 651 +key_share 652 signature_algorithms =(eccsi_sha256, 653 ecdsa_secp256r1_sha256) //(1) 654 signature_algorithms_cert = ( 655 eccsi_sha256, ecdsa_secp256r1_sha256) //(1) 656 {client_certificate_type= 657 (RawPublicKey)} //(1) 658 {server_certificate_type= 659 (RawPublicKey, X.509) //(1) 660 -> 661 <- server_hello, 662 +key_share 663 {server_certificate_type=X.509} //(2) 664 {Certificate = (x.509 certificate)} //(3) 665 {client_certificate_type = (RawPublicKey)}//(4) 666 {CertificateRequest} = (eccsi_sha256)} //(5) 667 {CertificateVerify} 668 {Finished} 669 certificate=( 670 (1.3.6.1.5.5.7.6.29, 671 ECCSIPublicParameters), 672 ClientID), //(6) 673 {CertificatVerify = 674 (ECCSI-Sig-Value)} //(7) 675 { Finished } 676 [Applicateion Data] ----> 677 [Application Data] <---> [Application Data] 679 Figure 15: Basic Raw Public Key TLS Exchange 681 Handshake for other IBS algorithms can be completed similarly by 682 including different data structures for public parameters and 683 signature values respectively. 685 8. Security Considerations 687 Using IBS-based raw public key in TLS/DTLS does not change the 688 message flows of TLS, hence, for the most part, the security 689 considerations involved in using the Transport Layer Security 690 protocol with raw public key also apply here. The additional 691 security of the resulting protocol rests on the security of the used 692 IBS algorithms. 694 IBS signature algorithm has been standardized for ten years and has 695 been adopted in real applications. However, we would like to point 696 out the differences between IBS signature algorithm and the existing 697 raw public key based algorithms: the private key of IBS used for 698 signature generation is generated by the PKG centre, while the 699 private key for the existing raw public key algorithms can be 700 generated locally. Therefore, IBS mechanism may face a security risk 701 of private key disclosure due to improper management of KMS system. 702 The entity using IBS with TLS protocol shall be aware the above risk 703 and an enforced key management system shall be adopted by the 704 organization. 706 When using IBS algorithm, key escrow is an concern as the private key 707 of user or devices normally is generated by PKG. PKG in the system 708 which could generate each device's private key. However, when IBS is 709 used in TLS1.3, passive attacks to recover the session key is not 710 possible. Actively man-in-the-middle attack by replacing exchanged 711 DH tokens and signatures would certainly leave traces even 712 transiently. Similarly, a PKG could impersonate an entity to conduct 713 a TLS session, just as the KMS in the symmetric key solution, but 714 forensic traces could be also collected in this situation. It would 715 be hugely risky for a PKG, which would usually be a trusted party, to 716 launch such attacks. If such an attack is caught in red-handed, no 717 one would trust the PKG's service anymore. 719 Another worry of using IBS is about the compromising of PKG. The PKG 720 could become operationally compromised and an attacker may obtain 721 master secrets of a PKG. However, this security risk can be solved 722 by protect the PKG with HSM, which is often used by CA to protect the 723 root signing key. 725 Private key compromising is one security risk that need to be 726 considered when using public key technology. When using raw public 727 key with IBS algorithm, as we have suggested in this document, a 728 revocation list shall be maintained at the server side. At the same 729 time, a timestamp shall be included in the public key to prevent the 730 revocation list from keeping on increasing. With the revocation 731 list, the server can prevent following attacks: 733 1) when a device use a revoked identifier for authentication, which 734 has not expired yet, then the server can reject the TLS session by 735 checking the revocation list maintained at the server-side. As it is 736 on the list, then the server aborts the TLS handshake. 738 2) When a device using a identifier which has been expired, the 739 server can simply verify the timestamp contained in the identifier 740 and abort the handshake procedure immediately. 742 3) If the attacker changes the timestamp within the identifier, then 743 it will cause signature verification error when the server verify the 744 signature contained in the signature_verify from client. 746 9. IANA Considerations 748 IANA has assigned 4 code points from the TLS SignatureScheme registry 749 for the four IBS algorithms used in this document. The code points 750 are listed as follows: 752 - eccsi_sha256 754 - iso_ibs1 756 - iso_ibs2 758 - iso_chinese_ibs 760 For all of these entries the Recommended field should be N, and the 761 Reference field should be this document. 763 10. Acknowledgements 765 11. References 767 11.1. Normative References 769 [PKIX] "Internet X.509 Public Key Infrastructure Certificate and 770 Certificate Revocation List(CRL) Profile", June 2008. 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, 774 DOI 10.17487/RFC2119, March 1997, 775 . 777 [RFC2434] "Guidelines for Writing an IANA Consideration Section in 778 RFCs", October 1998. 780 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 781 Standard (IBCS) #1: Supersingular Curve Implementations of 782 the BF and BB1 Cryptosystems", RFC 5091, 783 DOI 10.17487/RFC5091, December 2007, 784 . 786 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 787 "Elliptic Curve Cryptography Subject Public Key 788 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 789 . 791 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 792 Signatures for Identity-Based Encryption (ECCSI)", 793 RFC 6507, DOI 10.17487/RFC6507, February 2012, 794 . 796 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 797 RFC 6508, DOI 10.17487/RFC6508, February 2012, 798 . 800 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 801 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 802 Transport Layer Security (TLS) and Datagram Transport 803 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 804 June 2014, . 806 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 807 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 808 May 2017, . 810 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 811 RFC 8216, DOI 10.17487/RFC8216, August 2017, 812 . 814 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 815 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 816 . 818 11.2. Informative References 820 [Defeating-SSL] 821 "New Tricks for Defeating SSL in Practice", Feb 2009, 822 . 826 [FST10] "A Taxonomy of Pairing-Friendly Elliptic Curves. Journal 827 of Cryptology. Volume 23, Issue 2, pp 224-280,", Apr 2010. 829 [ISO_IEC-IBS] 830 "ISO/IEC 14888-3:2018 IT Security techniques - Digital 831 signatures with appendix - Part 3: Discrete logarithm 832 based mechanisms", Sept 2019. 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 877 Meiling Chen 878 China Mobile 879 32, Xuanwumen West 880 BeiJing, BeiJing 100053 881 China 883 Email: 884 chenmeiling@chinamobile.com