idnits 2.17.1 draft-wang-tls-raw-public-key-with-ibc-14.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 11, 2021) is 1112 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 7250' is mentioned on line 489, but not defined == Missing Reference: 'RFC 8446' is mentioned on line 484, but not defined == Missing Reference: 'RFC 6507' is mentioned on line 104, but not defined == Missing Reference: 'RFC 5091' is mentioned on line 127, but not defined -- Looks like a reference, but probably isn't: '2' on line 291 == Missing Reference: 'RFC 5901' is mentioned on line 328, but not defined == Unused Reference: 'RFC2434' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC5091' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC5480' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'RFC6507' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 802, but no explicit reference was found in the text == Unused Reference: 'RFC8216' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 816, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 5091 ** Downref: Normative reference to an Informational RFC: RFC 6507 ** Downref: Normative reference to an Informational RFC: RFC 6508 ** Downref: Normative reference to an Informational RFC: RFC 8216 Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Wang, Ed. 3 Internet-Draft Y. Yang 4 Intended status: Standards Track X. Kang 5 Expires: October 13, 2021 Huawei International Pte. Ltd. 6 Z. Cheng 7 Shenzhen Olym Info. Security Tech. Ltd. 8 M. Chen 9 China Mobile 10 April 11, 2021 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-14 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 October 13, 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 as a unified uthentication for 5G 93 and included both EAP-APA' and EAP-TLS as authentication methods. It 94 is specified in the 5G specification that EAP-TLS can be used for 95 private networks, especially for networks with a large number of IoT 96 devices [TS33.501]. For IoT networks, EAP-TLS with RAW public key is 97 particularly attractive, but binding identities with public keys 98 might be challenging. The cost to maintain a large table for 99 identity and public key mapping at server side incurs additional 100 cost, e.g. devices have to pre-register to the server. 102 To simplify the binding between the public key and the entity, a 103 better way could be using Identity-Based Cryptography(IBC), such as 104 ECCSI public key specified in [RFC 6507], for authentication. 105 Different from X.509 certificates and existing raw public keys, a 106 public key in IBC takes the form of the entity's identity. This 107 eliminates the necessity of binding between a public key and the 108 entity presenting the public key. 110 The concept of IBC was first proposed by Adi Shamir in 1984. As a 111 special class of public key cryptography, IBC uses a user's identity 112 as public key, avoiding the hassle of public key certification in 113 public key cryptosystems. IBC broadly includes IBE (Identity-based 114 Encryption) and IBS (Identity-based Signature). For an IBC system to 115 work, there exists a trusted third party, private key generator 116 (PKG), which is responsible for issuing private keys to the users. A 117 PKG has in possession a pair of Master Public Key and Master Secret 118 Key. A private key is generated based on the user's identity by using 119 the Master Secret key, while the Master Public key is used together 120 with the user's identities for encryption (in case of IBE) and 121 signature verification (in case of IBS). Another name of PKG is Key 122 Management System (KMS), which is also used in some IBC system. In 123 this document, the terms of PKG and KMS are interchangeable. 125 A number of IBE and IBS algorithms have been standardized by 126 different standardization bodies, such as IETF, IEEE, ISO, etc. For 127 example, IETF has specified several RFCs such as [RFC 5091], [RFC 128 6507] and [RFC6508] for both IBE and IBS algorithms. ISO and IEEE 129 also have a few standards on IBC algorithms, such as IBS1, IBS2, and 130 ChineseIBS [ISO_IEC-IBS]. 132 RFC 7250 has specified the use of raw public key with TLS/DTLS 133 handshake. However, supporting of IBS algorithms has not been 134 included therein. Since IBS algorithms eliminate the binding between 135 public keys and identities, this further simplifies the using of raw 136 public key with TLS. Therefore, in this document, an amendment is 137 added for supporting IBS algorithms when using raw public key. 139 With IBS algorithms, a PKG generates private keys for entities based 140 on identities from requestors. Global parameters such as PKG's 141 Master Public Key (MPK) are provisioned to both client and server. 142 These parameters are not user specific, but PKG specific. 144 For a client, PKG specific parameters can be provisioned at the time 145 PKG provisions the private key to the client. For the server, how to 146 get the PKG specific parameters provisioned is out of the scope of 147 this document, and it is deployment dependent. 149 The document is organized as follows: Section 2 defines the terms 150 used in thsi document, Section 3 defines the data structure required 151 when identity is used as raw public key. Section 4 specifies the 152 cipher suites required to support IBS algorithm over TLS/DTLS. 153 Section 5 explains how client and server authenticate each other when 154 using identity as raw public key. Section 6 gives examples for using 155 identity as raw public key over TLS/DTLS handshake procedure. 156 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 when 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 message exchange to 171 indicate the 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 Beside OID, it is necessary to tell the peer the set of global 212 parameters used by the signer. The information can be carried in the 213 payload of the parameters field in AlgorithmIdentifier. On the other 214 hand, when IBS algorithm is used for authentication, normally the 215 global parameters in use are known to client and server, hence, 216 instead of transmitting a full set of PKG public parameters, a hash 217 value of them is transmitted, which is put in the parameters field of 218 AlgorithmIdentifier data structure. 220 The data structure used to carry the hash value of public parameters 221 is defined as follows: 223 IBSPublicParametersHash ::= SEQUENCE { 224 HASHES { mda-sha256 } 225 } 227 Figure 3: IBS Global Parameters Hash ANSI.1 Structure 229 The hash value of the global parameters is generated by taking in the 230 DER encoded PKG public parameters of each individual IBS algorithms 231 as input. The data structure for each IBS algorithms supported in 232 this draft are defined in the following. 234 For the ECCSI IBS signature algorithms, its PKG public parameters is 235 specified in following Figure : 237 ECCSIPublicParameters ::= SEQUENCE { 238 version INTEGER { v2(2) }, 239 curve OBJECT IDENTIFIER, 240 hashfcn OBJECT IDENTIFIER, 241 pointP FpPOINT, 242 pointPpub FpPOINT 243 } 245 FpPoint ::= SEQUENCE { 246 x INTEGER, 247 y INTEGER 248 } 250 Figure 4: ECCSI Global Parameters ANSI.1 Structure 252 The structure to carry the ISO-IBS1/ISO-IBS2 PKG public parameters 253 are the same and is specified in following Figure : 255 ISOIBSPublicParameters ::= SEQUENCE { 256 version INTEGER { v3(3) }, 257 curve OBJECT IDENTIFIER, 258 hashfcn OBJECT IDENTIFIER, 259 pairing PAIRING OPTIONAL, 260 p INTEGER OPTIONAL, 261 q INTEGER OPTIONAL, 262 pointP FpPoint, 263 pointPpub FpPoint 264 } 266 PAIRING ::= ENUMERATED{ 267 weil (1) --Weil pairing 268 tate (2) --Tate pairing 269 optimalAte (3) --Optimal Ate pairing 270 } 272 Figure 5: ISO-IBS1/IBS2 Global Parameters ANSI.1 Structure 274 The structure to carry the ISO-SM9 PKG public parameters is specified 275 in following Figure : 277 SM9PublicParameters ::= SEQUENCE { 278 version INTEGER { v3(3) }, 279 curve OBJECT IDENTIFIER, 280 hashfcn OBJECT IDENTIFIER, 281 pairing PAIRING OPTIONAL, 282 p INTEGER OPTIONAL, 283 q INTEGER OPTIONAL, 284 pointP2 FpxPoint, 285 pointP2pub FpxPoint, 286 v FpxElement 287 } 289 FpxPoint ::= CHOICE{ 290 fpPoint FpPoint, 291 fp2Point [2] EXPLICIT Fp2Point, 292 } 294 Fp2Point ::= SEQUENCE{ 295 x Fp2Element, 296 y Fp2Element 297 } 299 Fp2Element ::= SEQUENCE{ 300 a INTEGER, 301 b INTEGER 302 } 304 FpxElement ::= CHOICE{ 305 fp2Elemt Fp2Element, 306 fp12Elemt Fp12Element, 307 } 309 Fp12Element ::= SEQUENCE{ 310 a Fp6Element, 311 b Fp6Element 312 } 314 Fp6Element ::= SEQUENCE{ 315 a Fp2Element, 316 b Fp2Element, 317 c Fp2Element 318 } 320 Figure 6: ISO-ChineseIBS Global Parameters ANSI.1 Structure 322 For ECCSIPublicParameters data structure, pointP shall be G in RFC 323 6507 and pointPpub shall be KPAK in RFC 6507. For 324 ISOIBSPublicParameters data structure, pointP and pointPpub shall be 325 the same as defined in RFC 5091, and the pairing field shall be weil 326 (1) or tate (2). The pairing field in SM9PublicParameters should be 327 optimalAte (3) and the choice of v should be determined by the curve 328 identifier. For example, for supersingular curves [RFC 5901], v 329 shall be of type Fp2Element and for BN curves or BLS12-curves 330 [FST10], v shall be of type Fp12Element. 332 To support IBS algorithm over TLS protocol, a data structure for 333 signature value need to be defined. 335 Data structure for ECCSI is defined as follows(based RFC 6507): 337 ECCSI-Sig-Value ::= SEQUENCE { 338 r INTEGER, 339 s INTEGER, 340 PVT OCTET STRING 341 } 343 Figure 7: ECCSI Signature Value ANSI.1 Structure 345 where PVT (as defined in RFC 6507) is encoded as 0x04 || x-coordinate 346 of [v]G || y-coordinate of [v]G. 348 Data structure for ISO-IBS1 is defined as follows: 350 ISO-IBS1-Sig-Value ::= SEQUENCE { 351 r INTEGER, 352 s ECPoint 353 } 355 Figure 8: ISO-IBS1 Signature Value ANSI.1 Structure 357 Data structure for ISO-IBS2 is defined as follows: 359 ISO-IBS2-Sig-Value ::= SEQUENCE { 360 r INTEGER, 361 s ECPoint 362 } 364 Figure 9: ISO-IBS2 Signature Value ANSI.1 Structure 366 Data structure for ISO-ChineseIBS (SM9) is defined as follows: 368 SM9-Sig-Value ::= SEQUENCE { 369 r INTEGER, 370 s ECPoint 371 } 373 Figure 10: ISO-ChineseIBS Signature Value ANSI.1 Structure 375 The definition of ECPoint can be found in section 2.2 of RFC 5480. 377 To use a signature algorithm with TLS, OID for the signature 378 algorithm need be provided. For ECCSI algorithm, an OID has been 379 assigned by IANA recently. The following table shows the basic 380 information needed for the ECCSI signature algorithm to be used for 381 TLS. 383 +--------------------------+----------------+-----------------------+ 384 | Key Type | Document | OID | 385 +--------------------------+----------------+-----------------------+ 386 | ISO/IEC 14888-3 IBS-1 | ISO/IEC | 1.0.14888.3.0.7 | 387 | | 14888-3: IBS-1 | | 388 | | mechanism | | 389 +--------------------------+----------------+-----------------------+ 390 | ISO/IEC 14888-3 IBS-2 | ISO/IEC | 1.0.14888.3.0.8 | 391 | | 14888-3: IBS-2 | | 392 | | mechanism | | 393 +--------------------------+----------------+-----------------------+ 394 | ISO/IEC 14888-3 | ISO/IEC | 1.2.156.10197.1.302.1 | 395 | ChineseIBS(SM9) | 14888-3: | | 396 | | ChineseIBS | | 397 | | mechanism | | 398 +--------------------------+----------------+-----------------------+ 399 | Elliptic Curve-Based | Section 5.2 in | 1.3.6.1.5.5.7.6.29 | 400 | Signatureless For | RFC 6507 | | 401 | Identitiy-based | | | 402 | Encryption (ECCSI) | | | 403 +--------------------------+----------------+-----------------------+ 405 Table 1: Algorithm Object Identifiers 407 4. New Signature Algorithms for IBS 409 To using identity as raw public key, new signature algorithms 410 corresponding to the IBS need to be defined. With TLS 1.3, the value 411 for signature algorithm is defined in the SignatureScheme. This 412 document specifies how to support IBS algorithm. As a result, the 413 SignatureScheme data structure has to be amended by including the 414 presented IBS algorithms. 416 enum { 417 ... 419 /* IBS ECCSI signature algorithm */ 420 eccsi_sha256 (0x0704), 421 iso_ibs1 (0x0705), 422 iso_ibs2 (0x0706), 423 iso_chinese_ibs (0x0707), 425 /* Reserved Code Points */ 426 private_use (0xFE00..0xFFFF), 427 (0xFFFF) 428 } SignatureScheme; 430 Figure 11: Include IBS in KeyExchangeAlgorithm 432 Note: The signature algorithm of eccsi_sha256 is defined in RFC6507. 434 Note: Other IBS signature algorithms can be added in the future. 436 5. Identity Format and Key Revocation 438 With the raw public scheme proposed in TLS 1.3 [RFC 8446], the server 439 maintains a whitelist to bind raw public key and identity. When a 440 raw public key is revoked, then the server removes the binding record 441 from the whitelist. On the other hand, when using IBS algorithms, it 442 is not necessary to maintain a whitelist at the server's side. 443 Instead, the server can simply maintain a blacklist, which is much 444 shorter than the whitelist. However, if we simply use the identifier 445 as a raw public key, the revocation list may keep on increasing with 446 the time going on. Hence, to prevent the revocation list from 447 increasing continuously, it is recommended to include a timestamp for 448 the automatic expiration of key material. With the timestamp 449 included in the identifier, i.e. the raw public key, server can 450 remove the revoked raw public key from the revocation list when it is 451 expired. 453 Based on the above analysis, it is necessary to include an expiration 454 time in the identifiers for the purpose of public key management. 455 Therefore, in this draft, we recommend both client and server take 456 following format for the identifiers used for TLS session setup: 458 Identifier ::= SEQUENCE { 459 version INTEGER {v1 (1)}, 460 identity String, 461 expiration UTCTime 462 } 464 Figure 12: Identifier Format ANSI.1 Structure 466 Both the client and server should check the validity of the 467 expiration field of the raw public key before verify the signature. 468 If the expiration time is invalid, the client or the server should 469 abort the handshake procedure. 471 The identities of client or server shall be unique within the domain 472 managed by one PKG. There are many different identities domains such 473 as email address, telephone number, Network Access Identifier (NAI), 474 International Mobile Subscriber Identity (IMSI) etc. It is up to 475 network operators' choice to determine which name domain the device 476 and server take. 478 6. TLS Client and Server Handshake Behavior 480 When RAW public is used with IBS for TLS, signature and hash 481 algorithms are negotiated during the handshake. 483 The handshake between the TLS client and server follows the 484 procedures defined in [RFC 8446], but with the support of the new 485 signature algorithms specific to the IBS algorithms. The high-level 486 message exchange in the following figure shows the TLS handshake 487 using raw public keys, where the client_certificate_type and 488 server_certificate_type extensions added to the client and server 489 hello messages (see Section 4 of [RFC 7250]). 491 client_hello, 492 +key_share 493 +signature_algorithms 494 client_certificate_type, 495 server_certificate_type -> 497 <- server_hello, 498 + key_share 499 {EncryptyedExtensions} 500 {client_certificate_type} 501 {server_certificate_type} 502 {Certificate} 503 {CertificateVerify} 504 {CertificateRequest} 505 {Finished} 506 [Applicaiton Data] 507 {Certificate} 508 {CertificateVerify} 509 {Finished} --------> 510 [Application Data} <-------> [Application Data] 512 Figure 13: Basic Raw Public Key TLS Exchange 514 The client hello message tells the server the types of certificate or 515 raw public key supported by the client, and also the certificate 516 types that the client expects to receive from the server. When raw 517 public with IBS algorithm from the server is supported by the client, 518 the client includes desired IBS signature algorithm in the client 519 hello message based on the order of client preference. 521 After receiving the client hello message, the server determines the 522 client and server certificate types for handshakes. When the 523 selected certificate type is RAW public key and IBS is the chosen 524 signature algorithm, the server uses the SubjectPublicKeyInfo 525 structure to carry the raw public key, OID for IBS algorithm and 526 public parameters or the hash value of public parameters. Assuming 527 that ECCSI is selected, the ECCSIPublicParameters data structure is 528 used to carry global public parameters. With this information, the 529 client knows the signature algorithm and the public parameters that 530 should be used to verify the signature. The signature value is in 531 the CertificateVerify message and the format of signature value is 532 specified by the selected IBS algorithm. The data structures for PKG 533 public parameters and signature values have been specified in the 534 previous section of this document. 536 When the sever specifies that RAW public key should be used by the 537 client to authenticate with the server, the client_certificate_type 538 in the server hello is set to RawPublicKey. Besides that, the server 539 also sends Certificate Request, indicating that client should use 540 some specific signature and hash algorithms. When IBS is chosen as 541 signature algorithm, the server need to indicate the required IBS 542 signature algorithms in the signature_algorithm extension within the 543 CertificateRequest. 545 After receiving the server hello, the client checks the 546 CertificateRequest for signature algorithms. If the client wants to 547 use an IBS algorithm for signature, then the signature algorithm it 548 intended to use must be in the list of supported signature algorithms 549 specified by the server. Assume the IBS algorithm supported by the 550 client is in the list, then the client responds with the IBS 551 signature algorithm and PKG information with SubjectPublicKeyInfo 552 structure in the certificate structure and provide signatures in the 553 certificate verify message. The format of signature in the 554 CertificateVerify message should be specified by each individual 555 signature algorithm. 557 The server verifies the signature based on the chosen IBS algorithm 558 and the relevant PKG parameters specified by the client. 560 7. Examples 562 In the following, examples of handshake exchange using IBS algorithm 563 under RawPublicKey are illustrated. 565 7.1. TLS Client and Server Use IBS algorithm 567 In this example, both the TLS client and server use ECCSI for 568 authentication, and they are restricted in that they can only process 569 ECCSI signature algorithm. As a result, the TLS client sets both the 570 server_certificate_type and the client_certificate_type extensions to 571 be raw public key; in addition, the client sets the signature 572 algorithm in the client hello message to be eccsi_sha256. 574 When the TLS server receives the client hello, it processes the 575 message. Since it has an ECCSI raw public key from the PKG, it 576 indicates in (2) that it agrees to use ECCSI and provides an ECCSI 577 key by placing the SubjectPublicKeyInfo structure into the 578 Certificate payload back to the client (3), including the OID, the 579 identity of the server, ServerID, which is the public key of the 580 server also, and the hash value of PKG public parameters. The 581 client_certificate_type in (4) indicates that the TLS server accepts 582 raw public key. The TLS server demands client authentication, and 583 therefore includes a certificate_request(5), which requires the 584 client to use eccsi_sha256 for signature. A signature value based on 585 the eccsi_sha256 algorithm is carried in the CertificateVerify (6). 586 The client, which has an ECCSI key, returns its ECCSI public key in 587 the Certificate payload to the server (7), which includes an OID for 588 the ECCSI signature algorithm, the PKGInfo for KMS parameters, and 589 identity of the client, ClientID, which is the public key of client 590 also. The client also includes a signature value, ECCSI-Sig-Value, 591 in the CertificateVerify (8) message. 593 When client/server receives PKG public parameters from peer, it 594 should decide whether these parameters are acceptable or not. An 595 example way to make decision is that a whitelist of acceptable PKG 596 public parameters are stored locally at client/server. They can 597 simply make a decision based on the white list stored locally. 599 client_hello, 600 +key_share //(1) 601 signature_algorithm = (eccsi_sha256) //(1) 602 client_certificate_type=(RawPublicKey) //(1) 603 server_certificate_type=(RawPublicKey) //(1) 604 -> 605 <- server_hello, 606 + key_share 607 { server_certificate_type = RawPublicKey} //(2) 608 {certificate=((1.3.6.1.5.5.7.6.29, hash 609 value of ECCSIPublicParameters), 610 serverID)} //(3) 611 {client_certificate_type = RawPublicKey //(4) 612 {certificate_request = (eccsi_sha256)} //(5) 613 {CertificateVerify = {ECCSI-Sig-Value} //(6) 614 {Finishaed} 616 {Certificate=( 617 (1.3.6.1.5.5.7.6.29, 618 hash value of ECCSIPublicParameters), 619 ClientID)} //(7) 620 {CertificatVerify = (ECCSI-Sig-Value)} //(8) 621 {Finished } 622 [Applicateion Data] ----> 623 [Application Data] <---> [Application Data] 625 Figure 14: Basic Raw Public Key TLS Exchange 627 7.2. Combined Usage of Raw Public Keys and X.509 Certificates 629 This example combines the uses of an ECCSI key and an X.509 630 certificate. The TLS client uses an ECCSI key for client 631 authentication, and the TLS server provides an X.509 certificate for 632 server authentication. 634 The exchange starts with the client indicating its ability to process 635 a raw public key, or an X.509 certificate, if provided by the server. 636 It prefers a raw public key with ECCSI signature algorithm since 637 eccsi_sha256 precedes the ecdsa_secp256r1_sha256. Furthermore, the 638 client indicates that it has a ECCSI-based raw public key for client- 639 side authentication. The client also indicates that it supports the 640 server using either ECCSI or ecdsa_secp256r1_sha256 for the 641 certificate signature. This further indicates that the server can 642 use ecdsa_secp256r1_sha256 to sign the message. 644 With the received client_hello, the server chooses to provide its 645 X.509 certificate in (3) and indicates that choice in (2). For 646 client authentication, the server indicates in (4) that it has 647 selected the raw public key format and requests an ECCSI certificate 648 from the client in (4) and (5). The TLS client provides an ECSSI 649 certificate in (6) and signature value after receiving and processing 650 the TLS server hello message. 652 client_hello, 653 +key_share 654 signature_algorithms =(eccsi_sha256, 655 ecdsa_secp256r1_sha256) //(1) 656 signature_algorithms_cert = ( 657 eccsi_sha256, ecdsa_secp256r1_sha256) //(1) 658 {client_certificate_type= 659 (RawPublicKey)} //(1) 660 {server_certificate_type= 661 (RawPublicKey, X.509) //(1) 662 -> 663 <- server_hello, 664 +key_share 665 {server_certificate_type=X.509} //(2) 666 {Certificate = (x.509 certificate)} //(3) 667 {client_certificate_type = (RawPublicKey)}//(4) 668 {CertificateRequest} = (eccsi_sha256)} //(5) 669 {CertificateVerify} 670 {Finished} 671 certificate=( 672 (1.3.6.1.5.5.7.6.29, 673 ECCSIPublicParameters), 674 ClientID), //(6) 675 {CertificatVerify = 676 (ECCSI-Sig-Value)} //(7) 677 { Finished } 678 [Applicateion Data] ----> 679 [Application Data] <---> [Application Data] 681 Figure 15: Basic Raw Public Key TLS Exchange 683 Handshake for other IBS algorithms can be completed similarly by 684 including different data structures for public parameters and 685 signature values respectively. 687 8. Security Considerations 689 Using IBS-based raw public key in TLS/DTLS does not change the 690 message flows of TLS, hence, for the most part, the security 691 considerations involved in using the Transport Layer Security 692 protocol with raw public key also apply here. The additional 693 security of the resulting protocol rests on the security of the used 694 IBS algorithms. 696 IBS signature algorithm has been standardized for ten years and has 697 been adopted in real applications. However, we would like to point 698 out the differences between IBS signature algorithm and the existing 699 raw public key based algorithms: the private key of IBS used for 700 signature generation is generated by the PKG centre, while the 701 private key for the existing raw public key algorithms can be 702 generated locally. Therefore, IBS mechanism may face a security risk 703 of private key disclosure due to improper management of KMS system. 704 The entity using IBS with TLS protocol shall be aware the above risk 705 and an enforced key management system shall be adopted by the 706 organization. 708 When using IBS algorithm, key escrow is an concern as the private key 709 of user or devices normally is generated by PKG. PKG in the system 710 which could generate each device's private key. However, when IBS is 711 used in TLS1.3, passive attacks to recover the session key is not 712 possible. Actively man-in-the-middle attack by replacing exchanged 713 DH tokens and signatures would certainly leave traces even 714 transiently. Similarly, a PKG could impersonate an entity to conduct 715 a TLS session, just as the KMS in the symmetric key solution, but 716 forensic traces could be also collected in this situation. It would 717 be hugely risky for a PKG, which would usually be a trusted party, to 718 launch such attacks. If such an attack is caught in red-handed, no 719 one would trust the PKG's service anymore. 721 Another worry of using IBS is about the compromising of PKG. The PKG 722 could become operationally compromised and an attacker may obtain 723 master secrets of a PKG. However, this security risk can be solved 724 by protect the PKG with HSM, which is often used by CA to protect the 725 root signing key. 727 Private key compromising is one security risk that need to be 728 considered when using public key technology. When using raw public 729 key with IBS algorithm, as we have suggested in this document, a 730 revocation list shall be maintained at the server side. At the same 731 time, a timestamp shall be included in the public key to prevent the 732 revocation list from keeping on increasing. With the revocation 733 list, the server can prevent following attacks: 735 1) when a device use a revoked identifier for authentication, which 736 has not expired yet, then the server can reject the TLS session by 737 checking the revocation list maintained at the server-side. As it is 738 on the list, then the server aborts the TLS handshake. 740 2) When a device using a identifier which has been expired, the 741 server can simply verify the timestamp contained in the identifier 742 and abort the handshake procedure immediately. 744 3) If the attacker changes the timestamp within the identifier, then 745 it will cause signature verification error when the server verify the 746 signature contained in the signature_verify from client. 748 9. IANA Considerations 750 IANA has assigned 4 code points from the TLS SignatureScheme registry 751 for the four IBS algorithms used in this document. The code points 752 are listed as follows: 754 - eccsi_sha256 756 - iso_ibs1 758 - iso_ibs2 760 - iso_chinese_ibs 762 For all of these entries the Recommended field should be N, and the 763 Reference field should be this document. 765 10. Acknowledgements 767 11. References 769 11.1. Normative References 771 [PKIX] "Internet X.509 Public Key Infrastructure Certificate and 772 Certificate Revocation List(CRL) Profile", June 2008. 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, 776 DOI 10.17487/RFC2119, March 1997, 777 . 779 [RFC2434] "Guidelines for Writing an IANA Consideration Section in 780 RFCs", October 1998. 782 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 783 Standard (IBCS) #1: Supersingular Curve Implementations of 784 the BF and BB1 Cryptosystems", RFC 5091, 785 DOI 10.17487/RFC5091, December 2007, 786 . 788 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 789 "Elliptic Curve Cryptography Subject Public Key 790 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 791 . 793 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 794 Signatures for Identity-Based Encryption (ECCSI)", 795 RFC 6507, DOI 10.17487/RFC6507, February 2012, 796 . 798 [RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", 799 RFC 6508, DOI 10.17487/RFC6508, February 2012, 800 . 802 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 803 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 804 Transport Layer Security (TLS) and Datagram Transport 805 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 806 June 2014, . 808 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 809 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 810 May 2017, . 812 [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", 813 RFC 8216, DOI 10.17487/RFC8216, August 2017, 814 . 816 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 817 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 818 . 820 11.2. Informative References 822 [Defeating-SSL] 823 "New Tricks for Defeating SSL in Practice", Feb 2009, 824 . 828 [FST10] "A Taxonomy of Pairing-Friendly Elliptic Curves. Journal 829 of Cryptology. Volume 23, Issue 2, pp 224-280,", Apr 2010. 831 [ISO_IEC-IBS] 832 "ISO/IEC 14888-3:2018 IT Security techniques - Digital 833 signatures with appendix - Part 3: Discrete logarithm 834 based mechanisms", Sept 2019. 836 [TS33.501] 837 "TS 33.501, Security architecture and procedures for 5G 838 System, v.g.0.0", Sept 2019, 839 . 842 Authors' Addresses 844 Haiguang Wang (editor) 845 Huawei International Pte. Ltd. 846 9 North Buona Vista Dr, #13-01 847 Singapore 138589 848 SG 850 Phone: +65 6825 4200 851 Email: wang.haiguang1@huawei.com 853 Yanjiang Yang 854 Huawei International Pte. Ltd. 855 9 North Buona Vista Dr, #13-01 856 Singapore 138589 857 SG 859 Phone: +65 6825 4200 860 Email: yang.yanjiang@huawei.com 862 Xin Kang 863 Huawei International Pte. Ltd. 864 9 North Buona Vista Dr, #13-01 865 Singapore 138589 866 SG 868 Phone: +65 6825 4200 869 Email: xin.kang@huawei.com 870 Zhaohui Cheng 871 Shenzhen Olym Info. Security Tech. Ltd. 872 Futong Haowangjiao Podium Building 873 Shenzhen, Guang Dong Province 518101 874 CN 876 Phone: +86 755 8618 2108 877 Email: chenzh@myibc.net 879 Meiling Chen 880 China Mobile 881 32, Xuanwumen West 882 BeiJing, BeiJing 100053 883 China 885 Email: chenmeiling@chinamobile.com