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