idnits 2.17.1 draft-chen-emu-eap-tls-ibs-00.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 10 instances of too long lines in the document, the longest one being 18 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '... ANY DEFINED BY algorithm OPTIONAL }...' RFC 2119 keyword, line 250: '...n extension type MUST NOT appear in th...' RFC 2119 keyword, line 296: '...he authenticator MAY act as a pass-thr...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2020) is 1444 days in the past. Is this intentional? 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: 'PKIX' is mentioned on line 177, but not defined ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU M. Chen 3 Internet-Draft Li. Su 4 Intended status: Standards Track China Mobile 5 Expires: November 13, 2020 H. Wang, Ed. 6 Huawei International Pte. Ltd. 7 May 12, 2020 9 Use Identity as Raw Public Key in EAP-TLS 10 draft-chen-emu-eap-tls-ibs-00 12 Abstract 14 This document specifies the use of identity as a raw public key in 15 EAP-TLS and EAP-TLS13, EAP-TLS defined in RFC 5216. The protocol 16 procedures of EAP-TLS-IBS will comply with EAP-TLS and EAP-TLS13, 17 Identity-based signature will be extended to support EAP-TLS's 18 signature algorithms. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 13, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Structure of the Raw Public Key Extension . . . . . . . . . . 4 57 4. EAP-TLS using raw public keys . . . . . . . . . . . . . . . . 6 58 4.1. EAP TLS1.2 Client and Server Handshake Behavior . . . . . 6 59 4.1.1. raw public keys TLS exchange . . . . . . . . . . . . 6 60 4.1.2. EAP-TLS handshake in TLS1.2 . . . . . . . . . . . . . 7 61 4.1.3. raw public keys EAP-TLS exchange . . . . . . . . . . 8 62 4.1.4. EAP-TLS1.2-IBS example . . . . . . . . . . . . . . . 10 63 4.2. EAP TLS1.3 Client and Server Handshake Behavior . . . . . 12 64 4.2.1. TLS1.3 handshake . . . . . . . . . . . . . . . . . . 12 65 4.2.2. EAP-TLS1.3 handshake procedure . . . . . . . . . . . 13 66 4.2.3. raw public keys EAP-TLS1.3 exchange . . . . . . . . . 14 67 4.2.4. EAP-TLS1.3-IBS example . . . . . . . . . . . . . . . 15 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 70 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 73 8.2. Informative references . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 The Extensible Authentication Protocol(EAP) defined in RFC 79 3748[RFC3748] can provide support for multiple authentication 80 methods. Transport Layer Security(TLS) provides for mutual 81 authentication, integrity-protected ciphersuite negotiation, and 82 exchange between two endpoints. The EAP-TLS defined in RFC 5216 83 [RFC5216] which combines EAP and TLS that apply EAP method to load 84 TLS procedures. 86 Traditionally, TLS client and server public keys are obtained in PKIX 87 containers in-band as part of the TLS handshake procedure and are 88 validated using trust anchors based on a PKIX certification authority 89 (CA). But there is another method, Using Raw Public Keys in 90 Transport Layer Security (TLS) and Datagram Transport Layer Security 91 (DTLS) are defined in RFC 7250[RFC7250], the document defines two TLS 92 extensions client_certificate_type and server_certificate_type, which 93 can be used as part of an extended TLS handshake when raw public keys 94 are used. 96 Digital signatures provide the functions of Sender reliability and 97 Message integrity. A chain of trust for such signatures is usually 98 provided by certificates, but in low-bandwidth and resource- 99 constrained environments, the use of certificates might be 100 undesirable. In comparison with the original certificate, the raw 101 public key is fairly small. This document describes a signature 102 algorithm using identity as a raw public key in EAP-TLS, instead of 103 transmitting a full certificate in the EAP-TLS message, only public 104 keys are exchanged between client and server, also known as EAP-TLS- 105 IBS. 107 With the existing raw public key scheme, a public key and identity 108 mapping table is required at server. This table usually established 109 with offline method and may require additional efforts for 110 establishment and maintenance, especially when the number of devices 111 are huge. On the other hand, with IBS signature algorithm, it not 112 only can take the advantage of raw public key, but also eliminates 113 the efforts for the mapping table establishment and maintenance at 114 the server side. Instead, a small table for CRL is enough for 115 exclude revoked identity from accessing the network. A number of IBE 116 and IBS algorithms have been standardized, such as ECCSI defined in 117 RFC 6507[RFC6507]. 119 IBC was first proposed by Adi Shamir in 1984. For an IBC system, a 120 Key Management System (KMS) is required to generate keys for devices. 121 The KMS choose its KMS Secret Authentication Key(KSAK) as the root of 122 trust. A public parameter, KMS Public Authentication Key (KPAK) is 123 derived from this secrete key and is used by others in verifying the 124 signature. The signatures are generated by an entity with private 125 keys obtained from the KMS. KMS is a trusted third party, users or 126 devices can obtain private key using their identities from KMS. In 127 IBS the private key is also known as Secret Signing Key(SSK). A 128 sender can sign a message using SSK. The receiver can verify the 129 signature with sender's identity and the KPAK. 131 This document is organized as follows: the second section defines the 132 terms used in the text; the third section gives a brief overview of 133 the IBS algorithms; the fourth section presents the example message 134 flow and message format for EAP-TLS-IBS and follows by security 135 consideration and IANA cosideration etc. 137 2. Terminology 139 The readers should be familiar with the terms defined in. 141 In addition, this document makes use of the following terms: 143 IBC: Identity-Based Cryptograph, it is an asymmetric public key 144 cryptosystem. 146 IBS: Identity-based Signature, such as ECCSI. 148 PKI: Public Key Infrastructure, an infrastructure built with a 149 public-key mechanism. 151 authenticator: The entity initiating EAP authentication. 153 peer: The entity that responds to the authenticator. 155 backend authenticator server: A backend authentication server is an 156 entity that provides an authentication service to an 157 authenticator. When used, this server typically executes EAP 158 methods for the authenticator. 160 EAP server: The entity that terminates the EAP authentication method 161 with the peer. In the case where no backend authentication server 162 is used, the EAP server is part of the authenticator. In the case 163 where the authenticator operates in pass-through mode, the EAP 164 server is located on the backend authentication server. 166 3. Structure of the Raw Public Key Extension 168 To support the negotiation of using raw public between client and 169 server, a new certificate structure is defined in RFC 7250[RFC7250]. 170 It is used by the client and server in the hello messages to indicate 171 the types of certificates supported by each side. When RawPublicKey 172 type is selected for authentication, SubjectPublicKeyInfo which is a 173 data structure is used to carry the raw public key and its 174 cryptographic algorithm. 176 The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC 177 5280 [PKIX][RFC5280] and not only contains the raw keys, such as the 178 public exponent and the modulus of an RSA public key, but also an 179 algorithm identifier. The algorithm identifier can also include 180 parameters. The structure of SubjectPublicKeyInfo is shown in 181 Figure 1: 183 SubjectPublicKeyInfo ::= SEQUENCE { 184 algorithm AlgorithmIdentifier, 185 subjectPublicKey BIT STRING } 187 AlgorithmIdentifier ::= SEQUENCE { 188 algorithm OBJECT IDENTIFIER, 189 parameters ANY DEFINED BY algorithm OPTIONAL } 191 Figure 1: SubjectPublicKeyInfo ASN.1 Structure 193 The algorithms identifiers are Object Identifier(OIDs), 194 AlgorithmIdentifier is also data structure with two fields, OID 195 represent the cryptographic algorithm used with raw public key, such 196 as ECCSI, parameters are the necessary parameters associated with the 197 algorithm. 199 In the case of IBS algorithm, the User's identity is the raw public 200 key which can be represented by "subjectPublicKey", when ECCSI is 201 used as the Identity-based signature algorithm, then "algorithm" is 202 for ECCSI, and "parameters" is the parameters needed in ECCSI. 204 So far, IBS has the following four algorithms, the following table is 205 the corresponding table of Key type and OID. 207 +--------------------------+----------------+-----------------------+ 208 | Key Type | Document | OID | 209 +--------------------------+----------------+-----------------------+ 210 | ISO/IEC 14888-3 IBS-1 | ISO/IEC | 1.0.14888.3.0.7 | 211 | | 14888-3: IBS-1 | | 212 | | mechanism | | 213 +--------------------------+----------------+-----------------------+ 214 | ISO/IEC 14888-3 IBS-2 | ISO/IEC | 1.0.14888.3.0.8 | 215 | | 14888-3: IBS-2 | | 216 | | mechanism | | 217 +--------------------------+----------------+-----------------------+ 218 | ISO/IEC 14888-3 | ISO/IEC | 1.2.156.10197.1.302.1 | 219 | ChineseIBS(SM9) | 14888-3: | | 220 | | ChineseIBS | | 221 | | mechanism | | 222 +--------------------------+----------------+-----------------------+ 223 | Elliptic Curve-Based | Section 5.2 | 1.3.6.1.5.5.7.6.29 | 224 | Signatureless For | in RFC 6507 | | 225 | Identitiy-based | | | 226 | Encryption (ECCSI) | | | 227 +--------------------------+----------------+-----------------------+ 229 Table 1: Algorithm Object Identifiers 231 In the draft draft-wang-tls-raw-public-key-with-ibc, there extend 232 signature scheme with IBS algorithm which indicated in the client's 233 "signature_algorithms" extension. 235 4. EAP-TLS using raw public keys 237 This section describes EAP-TLS-IBS both in the case of TLS1.2 and 238 TLS1.3, each section contains EAP-TLS and EAP-TLS using raw public 239 keys full message authentication, and finally give the example when 240 using IBS. 242 4.1. EAP TLS1.2 Client and Server Handshake Behavior 244 4.1.1. raw public keys TLS exchange 246 As described in [RFC7250][RFC7250], the document intrudoces the use 247 of raw public keys in TLS/DTLS, the basic raw public key TLS exchange 248 will appear as follows, Figure 2 shows the client_certificate_type 249 and server_certificate_type extensions added to the client and server 250 hello messages. An extension type MUST NOT appear in the ServerHello 251 unless the same extension type appeared in the corresponding 252 ClientHello, defined in RFC5246[RFC5246]. 254 The server_certificate_type extension in the client hello indicates 255 the types of certificates the client is able to process when provided 256 by the server in a subsequent certificate payload. 258 The client_certificate_type and server_certificate_type extensions 259 sent in the client hello each carry a list of supported certificate 260 types, sorted by client preference. When the client supports only 261 one certificate type, it is a list containing a single element. Many 262 types of certificates can be used, such as RawPublicKey, X.509 and 263 OpenPGP. 265 client_hello, 266 client_certificate_type, 267 server_certificate_type -> 269 <- server_hello, 270 client_certificate_type, 271 server_certificate_type, 272 certificate, 273 server_key_exchange, 274 certificate_request, 275 server_hello_done 276 certificate, 277 client_key_exchange, 278 certificate_verify, 279 change_cipher_spec, 280 finished -> 282 <- change_cipher_spec, 283 finished 285 Application Data <-------> Application Data 287 Figure 2: Basic Raw Public Key TLS Exchange 289 4.1.2. EAP-TLS handshake in TLS1.2 291 As described in [RFC3748] [RFC3748], the EAP-TLS conversation will 292 typically begin with the authenticator and the peer negotiating EAP. 293 The authenticator will then typically send an EAP-Request/Identity 294 packet to the peer, and the peer will respond with an EAP-Response/ 295 Identity packet to the authenticator, containing the peer's user-Id. 296 The authenticator MAY act as a pass-through device, with the EAP 297 packets received from the peer being encapsulated for transmission to 298 a backend authentication server. 300 In the case where the EAP-TLS mutual authentication is successful, 301 defined in RFC5216 [RFC5216], the conversation will appear as 302 follows: 304 Authenticating Peer Authenticator 305 ------------------- ------------- 306 <- EAP-Request/ 307 Identity 308 EAP-Response/ 309 Identity (MyID) -> 310 <- EAP-Request/ 311 EAP-Type=EAP-TLS 312 (TLS Start) 313 EAP-Response/ 314 EAP-Type=EAP-TLS 315 (TLS client_hello)-> 316 <- EAP-Request/ 317 EAP-Type=EAP-TLS 318 (TLS server_hello, 319 TLS certificate, 320 TLS server_key_exchange, 321 TLS certificate_request, 322 TLS server_hello_done) 323 EAP-Response/ 324 EAP-Type=EAP-TLS 325 (TLS certificate, 326 TLS client_key_exchange, 327 TLS certificate_verify, 328 TLS change_cipher_spec, 329 TLS finished) -> 330 <- EAP-Request/ 331 EAP-Type=EAP-TLS 332 (TLS change_cipher_spec, 333 TLS finished) 334 EAP-Response/ 335 EAP-Type=EAP-TLS -> 336 <- EAP-Success 338 Figure 3: EAP-TLS authentication procedure with TLS1.2 handshake 340 4.1.3. raw public keys EAP-TLS exchange 342 This section describes EAP-TLS extend using raw public keys, the 343 procedures is as follows, In the discussion, we will use the term 344 "EAP server" to denote the ultimate endpoint conversing with the 345 peer. 347 Authenticating Peer EAP server 348 ------------------- ------------- 349 <- EAP-Request/ 350 Identity 351 EAP-Response/ 352 Identity (MyID) -> 353 <- EAP-Request/ 354 EAP-Type=EAP-TLS 355 (TLS Start) 356 EAP-Response/ 357 EAP-Type=EAP-TLS 358 (TLS client_hello 359 +signature_algorithm 360 server_certificate_type, 361 client_certificate_type)-> 363 <- EAP-Request/ 364 EAP-Type=EAP-TLS 365 (TLS server_hello, 366 {client_certificate_type} 367 {server_certificate_type} 368 {TLS certificate} 369 {TLS server_key_exchange} 370 {TLS certificate_request} 371 {TLS server_hello_done} 372 ) 373 EAP-Response/ 374 EAP-Type=EAP-TLS 375 (TLS certificate, 376 TLS client_key_exchange, 377 TLS certificate_verify, 378 TLS change_cipher_spec, 379 TLS finished) -> 380 <- EAP-Request/ 381 EAP-Type=EAP-TLS 382 (TLS change_cipher_spec, 383 TLS finished) 384 EAP-Response/ 385 EAP-Type=EAP-TLS -> 386 <- EAP-Success 388 Figure 4: EAP-TLS extend raw public keys authentication procedure with TLS1.2 handshake 390 4.1.4. EAP-TLS1.2-IBS example 392 In this example, both the TLS client and server use ECCSI for 393 authentication, and they are restricted in that they can only process 394 ECCSI signature algorithm. As a result, the TLS client sets both the 395 server_certificate_type and the client_certificate_type extensions to 396 be raw public key; in addition, the client sets the signature 397 algorithm in the client hello message to be eccsi_sha256. 399 Authenticating Peer EAP server 400 ------------------- ------------- 401 <- EAP-Request/ 402 Identity 403 EAP-Response/ 404 Identity (MyID) -> 405 <- EAP-Request/ 406 EAP-Type=EAP-TLS 407 (TLS Start) 408 EAP-Response/ 409 EAP-Type=EAP-TLS 410 (TLS client_hello 411 signature_algorithm = (eccsi_sha256) 412 server_certificate_type = (RawPublicKey,...) 413 client_certificate_type = (RawPublicKey,...))-> 415 <- EAP-Request/ 416 EAP-Type=EAP-TLS 417 (TLS server_hello, 418 {client_certificate_type = RawPublicKey} 419 {server_certificate_type = RawPublicKey} 420 {certificate = (1.3.6.1.5.5.7.6.29, hash 421 value of ECCSIPublicParameters), 422 serverID)} 423 {certificate_request = (eccsi_sha256)} 424 {server_hello_done} 425 ) 426 EAP-Response/ 427 EAP-Type=EAP-TLS 428 ({certificate = ((1.3.6.1.5.5.7.6.29, 429 hash value of ECCSIPublicParameters), 430 ClientID)}, 431 {certificate_verify = (ECCSI-Sig-Value)}, 432 {finished}) -> 433 <- EAP-Request/ 434 EAP-Type=EAP-TLS 435 (TLS finished) 436 EAP-Response/ 437 EAP-Type=EAP-TLS -> 438 <- EAP-Success 440 Figure 5: EAP-TLS1.2-IBS example 442 4.2. EAP TLS1.3 Client and Server Handshake Behavior 444 TLS1.3 defined in RFC8446, as TLS 1.3 is not directly compatible with 445 previous versions, all versions of TLS incorporate a versioning 446 mechanism which allows clients and servers to interoperably negotiate 447 a common version if one is supported by both peers. when make the 448 discussion on EAP-TLS using raw public keys we also make a different 449 with TLS1.2, This section is for EAP-TLS1.3 handshake behavior using 450 raw public keys and give example for EAP-TLS-IBS. 452 4.2.1. TLS1.3 handshake 454 TLS1.3 is more secure than TLS1.2 in preventing eavesdropping, 455 tampering, and message forgery. The handshake can be thought of 456 having three phases: Key Exchange, Server Parameters and 457 Authentication. The message flow for full TLS handshake is as 458 follows. 460 Client Server 462 Key ^ ClientHello 463 Exch | + key_share* 464 | + signature_algorithms* 465 | + psk_key_exchange_modes* 466 v + pre_shared_key* --------> 467 ServerHello ^ Key 468 + key_share* | Exch 469 + pre_shared_key* v 470 {EncryptedExtensions} ^ Server 471 {CertificateRequest*} v Params 472 {Certificate*} ^ 473 {CertificateVerify*} | Auth 474 {Finished} v 475 <-------- [Application Data*] 476 ^ {Certificate*} 477 Auth | {CertificateVerify*} 478 v {Finished} --------> 479 [Application Data] <-------> [Application Data] 481 + Indicates noteworthy extensions sent in the 482 previously noted message. 484 * Indicates optional or situation-dependent 485 messages/extensions that are not always sent. 487 {} Indicates messages protected using keys 488 derived from a [sender]_handshake_traffic_secret. 490 [] Indicates messages protected using keys 491 derived from [sender]_application_traffic_secret_N. 493 Figure 6: Message Flow for Full TLS1.3 Handshake 495 4.2.2. EAP-TLS1.3 handshake procedure 497 EAP-TLS mutual authentication in the case of TLS1.3. defined in the 498 draft-ietf-emu-eap-tls13. TLS 1.3 provides significantly improved 499 security, privacy, and reduced latency when compared to earlier 500 versions of TLS. EAP-TLS with TLS 1.3 further improves security and 501 privacy by mandating use of privacy and revocation checking. 503 EAP Peer EAP Server 505 EAP-Request/ 506 <-------- Identity 507 EAP-Response/ 508 Identity (Privacy-Friendly) --------> 509 EAP-Request/ 510 EAP-Type=EAP-TLS 511 <-------- (TLS Start) 512 EAP-Response/ 513 EAP-Type=EAP-TLS 514 (TLS ClientHello) --------> 515 EAP-Request/ 516 EAP-Type=EAP-TLS 517 (TLS ServerHello, 518 TLS EncryptedExtensions, 519 TLS CertificateRequest, 520 TLS Certificate, 521 TLS CertificateVerify, 522 TLS Finished, 523 <-------- Commitment Message) 524 EAP-Response/ 525 EAP-Type=EAP-TLS 526 (TLS Certificate, 527 TLS CertificateVerify, 528 TLS Finished) --------> 529 <-------- EAP-Success 531 Figure 7: EAP-TLS mutual authentication with TLS1.3 handshake 533 4.2.3. raw public keys EAP-TLS1.3 exchange 535 This section describes EAP-TLS1.3 extend using raw public keys, the 536 procedures is as follows, both client and server have the extension 537 "key_share", the "key_share" extension contains the endpoint's 538 cryptographic parameters. the "signature_algorithm" extension 539 contains the signature algorithm and hash algorithms the client and 540 server can support for the new signature algorithms specific to the 541 IBS algorithms. When IBS is chosen as signature algorithm, the 542 server need to indicated the required IBS signature algorithms int 543 the signature_algorithm extension within the CertificateRequest. 545 Authenticating Peer EAP server 546 ------------------- ------------- 547 <- EAP-Request/ 548 Identity 549 EAP-Response/ 550 Identity (MyID) -> 551 <- EAP-Request/ 552 EAP-Type=EAP-TLS 553 (TLS Start) 554 EAP-Response/ 555 EAP-Type=EAP-TLS 556 (TLS client_hello 557 +key_share 558 +signature_algorithm 559 server_certificate_type, 560 client_certificate_type)-> 562 <- EAP-Request/ 563 EAP-Type=EAP-TLS 564 (TLS server_hello, 565 +key_share 566 {EncryptedExtensions} 567 {client_certificate_type} 568 {server_certificate_type} 569 {certificate} 570 {CertificateVerify} 571 {certificateRequest} 572 {Finished} 573 [Application Data] 574 ) 575 EAP-Response/ 576 EAP-Type=EAP-TLS 577 ({certificate} 578 {CertificateVerify} 579 {Finished} 580 [Application Data]) -> 581 <- EAP-Success 582 [Application Data] 584 Figure 8: EAP-TLS1.3 authentication procedure with raw public keys 586 4.2.4. EAP-TLS1.3-IBS example 588 When the EAP server receives the client hello, it processes the 589 message. Since it has an ECCSI raw public key from the KMS, it 590 indicates that it agrees to use ECCSI and provides an ECCSI key by 591 placing the SubjectPublicKeyInfo structure into the Certificate 592 payload back to the client, including the OID, the identity of 593 server, ServerID, which is the public key of server also, and hash 594 value of KMS public parameters. The client_certificate_type 595 indicates that the TLS server accepts raw public key. The TLS server 596 demands client authentication, and therefore includes a 597 certificate_request, which requires the client to use eccsi_sha256 598 for signature. A signature value based on the eccsi_sha256 algorithm 599 is carried in the CertificateVerify. The client, which has an ECCSI 600 key, returns its ECCSI public key in the Certificate payload to the 601 server, which includes an OID for the ECCSI signature. The example 602 of EAP-TLS1.3-IBS is as follows: 604 Authenticating Peer EAP server 605 ------------------- ------------- 606 <- EAP-Request/ 607 Identity 608 EAP-Response/ 609 Identity (MyID) -> 610 <- EAP-Request/ 611 EAP-Type=EAP-TLS 612 (TLS Start) 613 EAP-Response/ 614 EAP-Type=EAP-TLS 615 (TLS client_hello 616 signature_algorithm = (eccsi_sha256) 617 server_certificate_type = (RawPublicKey,...) 618 client_certificate_type = (RawPublicKey,...))-> 620 <- EAP-Request/ 621 EAP-Type=EAP-TLS 622 (TLS server_hello, 623 +key_share 624 {client_certificate_type = RawPublicKey} 625 {server_certificate_type = RawPublicKey} 626 {certificate = (1.3.6.1.5.5.7.6.29, hash 627 value of ECCSIPublicParameters), 628 serverID)} 629 {certificate_request = (eccsi_sha256)} 630 {certificate_verify = {ECCSI-Sig-Value}} 631 {Finished} 632 [Application Data] 633 ) 634 EAP-Response/ 635 EAP-Type=EAP-TLS 636 ({certificate = ((1.3.6.1.5.5.7.6.29, 637 hash value of ECCSIPublicParameters), 638 ClientID)}, 639 {certificate_verify = (ECCSI-Sig-Value)}, 640 {Finished}) 641 [Application Data] -> 642 <- EAP-Success 643 [Application Data] 645 Figure 9: EAP-TLS1.3-IBS example 647 5. Security Considerations 649 TBD 651 6. IANA Considerations 653 This document does not require any action from IANA. 655 7. Acknowledgement 657 TBD 659 8. References 661 8.1. Normative References 663 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 664 Levkowetz, Ed., "Extensible Authentication Protocol 665 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 666 . 668 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 669 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 670 March 2008, . 672 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 673 (TLS) Protocol Version 1.2", RFC 5246, 674 DOI 10.17487/RFC5246, August 2008, 675 . 677 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 678 Housley, R., and W. Polk, "Internet X.509 Public Key 679 Infrastructure Certificate and Certificate Revocation List 680 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 681 . 683 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 684 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 685 Transport Layer Security (TLS) and Datagram Transport 686 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 687 June 2014, . 689 8.2. Informative references 691 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 692 Signatures for Identity-Based Encryption (ECCSI)", 693 RFC 6507, DOI 10.17487/RFC6507, February 2012, 694 . 696 Authors' Addresses 698 Meiling Chen 699 China Mobile 700 32, Xuanwumen West 701 BeiJing, BeiJing 100053 702 China 704 Email: 705 chenmeiling@chinamobile.com 707 Li Su 708 China Mobile 710 32, Xuanwumen West 712 BeiJing 714 100053 716 China 718 Email: 719 suli@chinamobile.com 721 Haiguang Wang (editor) 722 Huawei International Pte. Ltd. 723 11 North Buona Vista Dr, #17-08 724 Singapore 138589 725 SG 727 Phone: +65 6825 4200 728 Email: wang.haiguang1@huawei.com