idnits 2.17.1 draft-chen-emu-eap-tls-ibs-03.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 211: '... ANY DEFINED BY algorithm OPTIONAL }...' RFC 2119 keyword, line 273: '...n extension type MUST NOT appear in th...' RFC 2119 keyword, line 319: '...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 15, 2021) is 892 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 199, 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 19, 2022 H. Wang 6 Huawei International Pte. Ltd. 7 November 15, 2021 9 Use Identity as Raw Public Key in EAP-TLS 10 draft-chen-emu-eap-tls-ibs-03 12 Abstract 14 This document specifies the use of identity as a raw public key in 15 EAP-TLS, EAP-TLS for TLS1.2 is defined in RFC 5216 and EAP-TLS for 16 TLS1.3 is defined in the draft draft-ietf-emu-eap-tls13 and draft- 17 ietf-tls-dtls13. The procedures of EAP-TLS-IBS will consistent with 18 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 19, 2022. 38 Copyright Notice 40 Copyright (c) 2021 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. Use case of the EAP-TLS-IBS . . . . . . . . . . . . . . . . . 4 58 4. Structure of the Raw Public Key Extension . . . . . . . . . . 5 59 5. EAP-TLS using raw public keys . . . . . . . . . . . . . . . . 6 60 5.1. EAP TLS1.2 Client and Server Handshake Behavior . . . . . 6 61 5.1.1. raw public keys TLS exchange . . . . . . . . . . . . 6 62 5.1.2. EAP-TLS handshake in TLS1.2 . . . . . . . . . . . . . 7 63 5.1.3. raw public keys EAP-TLS exchange . . . . . . . . . . 8 64 5.1.4. EAP-TLS1.2-IBS example . . . . . . . . . . . . . . . 10 65 5.2. EAP TLS1.3 Client and Server Handshake Behavior . . . . . 12 66 5.2.1. TLS1.3 handshake . . . . . . . . . . . . . . . . . . 12 67 5.2.2. EAP-TLS1.3 handshake procedure . . . . . . . . . . . 13 68 5.2.3. raw public keys EAP-TLS1.3 exchange . . . . . . . . . 14 69 5.2.4. EAP-TLS1.3-IBS example . . . . . . . . . . . . . . . 16 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 75 9.2. Informative references . . . . . . . . . . . . . . . . . 19 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 The Extensible Authentication Protocol(EAP) defined in RFC 81 3748[RFC3748] can provide support for multiple authentication 82 methods. Transport Layer Security(TLS) provides for mutual 83 authentication, integrity-protected ciphersuite negotiation, and 84 exchange between two endpoints. The EAP-TLS defined in RFC 5216 85 [RFC5216] which combines EAP and TLS that apply EAP method to load 86 TLS procedures. 88 Traditionally, TLS client and server public keys are obtained in PKIX 89 containers in-band as part of the TLS handshake procedure and are 90 validated using trust anchors based on a PKIX certification authority 91 (CA). But there is another method, Using Raw Public Keys in 92 Transport Layer Security (TLS) and Datagram Transport Layer Security 93 (DTLS) are defined in RFC 7250[RFC7250], the document defines two TLS 94 extensions client_certificate_type and server_certificate_type, which 95 can be used as part of an extended TLS handshake when raw public keys 96 are used. In the draft draft-ietf-emu-eap-tls13 reads certificates 97 can be of any type supported by TLS including raw public keys. In 98 RFC7250[RFC7250] it assuming that an out-of-band mechanism is used to 99 bind the public key to the entity presenting the key. 101 Digital signatures provide the functions of Sender reliability and 102 Message integrity. A chain of trust for such signatures is usually 103 provided by certificates, but in low-bandwidth and resource- 104 constrained environments, the use of certificates might be 105 undesirable. In comparison with the original certificate, the raw 106 public key is fairly small. This document describes a signature 107 algorithm using identity as a raw public key in EAP-TLS, instead of 108 transmitting a full certificate in the EAP-TLS message, only public 109 keys are exchanged between client and server, also known as EAP-TLS- 110 IBS. 112 With the existing raw public key scheme, a public key and identity 113 mapping table is required at server. This table usually established 114 with offline method and may require additional efforts for 115 establishment and maintenance, especially when the number of devices 116 are huge. On the other hand, with IBS signature algorithm, it not 117 only can take the advantage of raw public key, but also eliminates 118 the efforts for the mapping table establishment and maintenance at 119 the server side. Instead, a small table for CRL is enough for 120 exclude revoked identity from accessing the network. A number of IBE 121 and IBS algorithms have been standardized, such as ECCSI defined in 122 RFC 6507[RFC6507]. 124 IBC was first proposed by Adi Shamir in 1984. For an IBC system, a 125 Key Management System (KMS) is required to generate keys for devices. 126 The KMS choose its KMS Secret Authentication Key(KSAK) as the root of 127 trust. A public parameter, KMS Public Authentication Key (KPAK) is 128 derived from this secrete key and is used by others in verifying the 129 signature. The signatures are generated by an entity with private 130 keys obtained from the KMS. KMS is a trusted third party, users or 131 devices can obtain private key using their identities from KMS. In 132 IBS the private key is also known as Secret Signing Key(SSK). A 133 sender can sign a message using SSK. The receiver can verify the 134 signature with sender's identity and the KPAK. 136 This document is organized as follows: the second section defines the 137 terms used in the text; the third section gives a brief overview of 138 the IBS algorithms; the fourth section presents the example message 139 flow and message format for EAP-TLS-IBS and follows by security 140 consideration and IANA cosideration etc. 142 2. Terminology 144 The readers should be familiar with the terms defined in. 146 In addition, this document makes use of the following terms: 148 IBC: Identity-Based Cryptograph, it is an asymmetric public key 149 cryptosystem. 151 IBS: Identity-based Signature, such as ECCSI. 153 PKI: Public Key Infrastructure, an infrastructure built with a 154 public-key mechanism. 156 authenticator: The entity initiating EAP authentication. 158 peer: The entity that responds to the authenticator. 160 backend authenticator server: A backend authentication server is an 161 entity that provides an authentication service to an 162 authenticator. When used, this server typically executes EAP 163 methods for the authenticator. 165 EAP server: The entity that terminates the EAP authentication method 166 with the peer. In the case where no backend authentication server 167 is used, the EAP server is part of the authenticator. In the case 168 where the authenticator operates in pass-through mode, the EAP 169 server is located on the backend authentication server. 171 3. Use case of the EAP-TLS-IBS 173 Used for authentication of Internet of Things devices: due to the 174 limited processing power of IoT devices, resources for secure 175 identity authentication are limited, especially passive, long life 176 cycle devices, however, the traditional certificate authentication 177 based on PKI X509, because of the complexity of certificate 178 processing and certificate chain authentication, not very suitable 179 for the Internet of Things scenario. Internet of Things devices 180 really need a more lightweight authentication method, and EAP-TLS-IBS 181 as one of the candidates. 183 Used for systems that do not support CA certificates: an internal 184 system with network security boundaries that can self-operate the Key 185 Management System(KMS) secret key distribution center, EAP-TLS-IBS 186 can be used between internal subsystems. 188 4. Structure of the Raw Public Key Extension 190 To support the negotiation of using raw public between client and 191 server, a new certificate structure is defined in RFC 7250[RFC7250]. 192 It is used by the client and server in the hello messages to indicate 193 the types of certificates supported by each side. When RawPublicKey 194 type is selected for authentication, SubjectPublicKeyInfo which is a 195 data structure is used to carry the raw public key and its 196 cryptographic algorithm. 198 The SubjectPublicKeyInfo structure is defined in Section 4.1 of RFC 199 5280 [PKIX][RFC5280] and not only contains the raw keys, such as the 200 public exponent and the modulus of an RSA public key, but also an 201 algorithm identifier. The algorithm identifier can also include 202 parameters. The structure of SubjectPublicKeyInfo is shown in 203 Figure 1: 205 SubjectPublicKeyInfo ::= SEQUENCE { 206 algorithm AlgorithmIdentifier, 207 subjectPublicKey BIT STRING } 209 AlgorithmIdentifier ::= SEQUENCE { 210 algorithm OBJECT IDENTIFIER, 211 parameters ANY DEFINED BY algorithm OPTIONAL } 213 Figure 1: SubjectPublicKeyInfo ASN.1 Structure 215 The algorithms identifiers are Object Identifier(OIDs), 216 AlgorithmIdentifier is also data structure with two fields, OID 217 represent the cryptographic algorithm used with raw public key, such 218 as ECCSI, parameters are the necessary parameters associated with the 219 algorithm. 221 In the case of IBS algorithm, the User's identity is the raw public 222 key which can be represented by "subjectPublicKey", when ECCSI is 223 used as the Identity-based signature algorithm, then "algorithm" is 224 for ECCSI, and "parameters" is the parameters needed in ECCSI. 226 So far, IBS has the following four algorithms, the following table is 227 the corresponding table of Key type and OID. 229 +--------------------------+----------------+-----------------------+ 230 | Key Type | Document | OID | 231 +--------------------------+----------------+-----------------------+ 232 | ISO/IEC 14888-3 IBS-1 | ISO/IEC | 1.0.14888.3.0.7 | 233 | | 14888-3: IBS-1 | | 234 | | mechanism | | 235 +--------------------------+----------------+-----------------------+ 236 | ISO/IEC 14888-3 IBS-2 | ISO/IEC | 1.0.14888.3.0.8 | 237 | | 14888-3: IBS-2 | | 238 | | mechanism | | 239 +--------------------------+----------------+-----------------------+ 240 | ISO/IEC 14888-3 | ISO/IEC | 1.2.156.10197.1.302.1 | 241 | ChineseIBS(SM9) | 14888-3: | | 242 | | ChineseIBS | | 243 | | mechanism | | 244 +--------------------------+----------------+-----------------------+ 245 | Elliptic Curve-Based | Section 5.2 | 1.3.6.1.5.5.7.6.29 | 246 | Signatureless For | in RFC 6507 | | 247 | Identitiy-based | | | 248 | Encryption (ECCSI) | | | 249 +--------------------------+----------------+-----------------------+ 251 Table 1: Algorithm Object Identifiers 253 In the draft draft-wang-tls-raw-public-key-with-ibc, there extend 254 signature scheme with IBS algorithm which indicated in the client's 255 "signature_algorithms" extension. The SignatureScheme data structure 256 also keep pace with the section 4. 258 5. EAP-TLS using raw public keys 260 This section describes EAP-TLS-IBS both in the case of TLS1.2 and 261 TLS1.3, each section contains EAP-TLS and EAP-TLS using raw public 262 keys full message authentication, and finally give the example when 263 using IBS. 265 5.1. EAP TLS1.2 Client and Server Handshake Behavior 267 5.1.1. raw public keys TLS exchange 269 As described in [RFC7250][RFC7250], the document intrudoces the use 270 of raw public keys in TLS/DTLS, the basic raw public key TLS exchange 271 will appear as follows, Figure 2 shows the client_certificate_type 272 and server_certificate_type extensions added to the client and server 273 hello messages. An extension type MUST NOT appear in the ServerHello 274 unless the same extension type appeared in the corresponding 275 ClientHello, defined in RFC5246[RFC5246]. 277 The server_certificate_type extension in the client hello indicates 278 the types of certificates the client is able to process when provided 279 by the server in a subsequent certificate payload. 281 The client_certificate_type and server_certificate_type extensions 282 sent in the client hello each carry a list of supported certificate 283 types, sorted by client preference. When the client supports only 284 one certificate type, it is a list containing a single element. Many 285 types of certificates can be used, such as RawPublicKey, X.509 and 286 OpenPGP. 288 client_hello, 289 client_certificate_type, 290 server_certificate_type -> 292 <- server_hello, 293 client_certificate_type, 294 server_certificate_type, 295 certificate, 296 server_key_exchange, 297 certificate_request, 298 server_hello_done 299 certificate, 300 client_key_exchange, 301 certificate_verify, 302 change_cipher_spec, 303 finished -> 305 <- change_cipher_spec, 306 finished 308 Application Data <-------> Application Data 310 Figure 2: Basic Raw Public Key TLS Exchange 312 5.1.2. EAP-TLS handshake in TLS1.2 314 As described in [RFC3748] [RFC3748], the EAP-TLS conversation will 315 typically begin with the authenticator and the peer negotiating EAP. 316 The authenticator will then typically send an EAP-Request/Identity 317 packet to the peer, and the peer will respond with an EAP-Response/ 318 Identity packet to the authenticator, containing the peer's user-Id. 319 The authenticator MAY act as a pass-through device, with the EAP 320 packets received from the peer being encapsulated for transmission to 321 a backend authentication server. 323 In the case where the EAP-TLS mutual authentication is successful, 324 defined in RFC5216 [RFC5216], the conversation will appear as 325 follows: 327 Authenticating Peer Authenticator 328 ------------------- ------------- 329 <- EAP-Request/ 330 Identity 331 EAP-Response/ 332 Identity (MyID) -> 333 <- EAP-Request/ 334 EAP-Type=EAP-TLS 335 (TLS Start) 336 EAP-Response/ 337 EAP-Type=EAP-TLS 338 (TLS client_hello)-> 339 <- EAP-Request/ 340 EAP-Type=EAP-TLS 341 (TLS server_hello, 342 TLS certificate, 343 TLS server_key_exchange, 344 TLS certificate_request, 345 TLS server_hello_done) 346 EAP-Response/ 347 EAP-Type=EAP-TLS 348 (TLS certificate, 349 TLS client_key_exchange, 350 TLS certificate_verify, 351 TLS change_cipher_spec, 352 TLS finished) -> 353 <- EAP-Request/ 354 EAP-Type=EAP-TLS 355 (TLS change_cipher_spec, 356 TLS finished) 357 EAP-Response/ 358 EAP-Type=EAP-TLS -> 359 <- EAP-Success 361 Figure 3: EAP-TLS authentication procedure with TLS1.2 handshake 363 5.1.3. raw public keys EAP-TLS exchange 365 This section describes EAP-TLS extend using raw public keys, the 366 procedures is as follows, In the discussion, we will use the term 367 "EAP server" to denote the ultimate endpoint conversing with the 368 peer. 370 Authenticating Peer EAP server 371 ------------------- ------------- 372 <- EAP-Request/ 373 Identity 374 EAP-Response/ 375 Identity (MyID) -> 376 <- EAP-Request/ 377 EAP-Type=EAP-TLS 378 (TLS Start) 379 EAP-Response/ 380 EAP-Type=EAP-TLS 381 (TLS client_hello 382 +signature_algorithm 383 server_certificate_type, 384 client_certificate_type)-> 386 <- EAP-Request/ 387 EAP-Type=EAP-TLS 388 (TLS server_hello, 389 {client_certificate_type} 390 {server_certificate_type} 391 {TLS certificate} 392 {TLS server_key_exchange} 393 {TLS certificate_request} 394 {TLS server_hello_done} 395 ) 396 EAP-Response/ 397 EAP-Type=EAP-TLS 398 (TLS certificate, 399 TLS client_key_exchange, 400 TLS certificate_verify, 401 TLS change_cipher_spec, 402 TLS finished) -> 403 <- EAP-Request/ 404 EAP-Type=EAP-TLS 405 (TLS change_cipher_spec, 406 TLS finished) 407 EAP-Response/ 408 EAP-Type=EAP-TLS -> 409 <- EAP-Success 411 Figure 4: EAP-TLS extend raw public keys authentication procedure with TLS1.2 handshake 413 5.1.4. EAP-TLS1.2-IBS example 415 In this example, both the TLS client and server use ECCSI for 416 authentication, and they are restricted in that they can only process 417 ECCSI signature algorithm. As a result, the TLS client sets both the 418 server_certificate_type and the client_certificate_type extensions to 419 be raw public key; in addition, the client sets the signature 420 algorithm in the client hello message to be eccsi_sha256. 422 Authenticating Peer EAP server 423 ------------------- ------------- 424 <- EAP-Request/ 425 Identity 426 EAP-Response/ 427 Identity (MyID) -> 428 <- EAP-Request/ 429 EAP-Type=EAP-TLS 430 (TLS Start) 431 EAP-Response/ 432 EAP-Type=EAP-TLS 433 (TLS client_hello 434 signature_algorithm = (eccsi_sha256) 435 server_certificate_type = (RawPublicKey,...) 436 client_certificate_type = (RawPublicKey,...))-> 438 <- EAP-Request/ 439 EAP-Type=EAP-TLS 440 (TLS server_hello, 441 {client_certificate_type = RawPublicKey} 442 {server_certificate_type = RawPublicKey} 443 {certificate = (1.3.6.1.5.5.7.6.29, hash 444 value of ECCSIPublicParameters), 445 serverID)} 446 {certificate_request = (eccsi_sha256)} 447 {server_hello_done} 448 ) 449 EAP-Response/ 450 EAP-Type=EAP-TLS 451 ({certificate = ((1.3.6.1.5.5.7.6.29, 452 hash value of ECCSIPublicParameters), 453 ClientID)}, 454 {certificate_verify = (ECCSI-Sig-Value)}, 455 {finished}) -> 456 <- EAP-Request/ 457 EAP-Type=EAP-TLS 458 (TLS finished) 459 EAP-Response/ 460 EAP-Type=EAP-TLS -> 461 <- EAP-Success 463 Figure 5: EAP-TLS1.2-IBS example 465 5.2. EAP TLS1.3 Client and Server Handshake Behavior 467 TLS1.3 defined in RFC8446, as TLS 1.3 is not directly compatible with 468 previous versions, all versions of TLS incorporate a versioning 469 mechanism which allows clients and servers to interoperably negotiate 470 a common version if one is supported by both peers. when make the 471 discussion on EAP-TLS using raw public keys we also make a different 472 with TLS1.2, This section is for EAP-TLS1.3 handshake behavior using 473 raw public keys and give example for EAP-TLS-IBS. 475 5.2.1. TLS1.3 handshake 477 TLS1.3 is more secure than TLS1.2 in preventing eavesdropping, 478 tampering, and message forgery. The handshake can be thought of 479 having three phases: Key Exchange, Server Parameters and 480 Authentication. The message flow for full TLS handshake is as 481 follows. 483 Client Server 485 Key ^ ClientHello 486 Exch | + key_share* 487 | + signature_algorithms* 488 | + psk_key_exchange_modes* 489 v + pre_shared_key* --------> 490 ServerHello ^ Key 491 + key_share* | Exch 492 + pre_shared_key* v 493 {EncryptedExtensions} ^ Server 494 {CertificateRequest*} v Params 495 {Certificate*} ^ 496 {CertificateVerify*} | Auth 497 {Finished} v 498 <-------- [Application Data*] 499 ^ {Certificate*} 500 Auth | {CertificateVerify*} 501 v {Finished} --------> 502 [Application Data] <-------> [Application Data] 504 + Indicates noteworthy extensions sent in the 505 previously noted message. 507 * Indicates optional or situation-dependent 508 messages/extensions that are not always sent. 510 {} Indicates messages protected using keys 511 derived from a [sender]_handshake_traffic_secret. 513 [] Indicates messages protected using keys 514 derived from [sender]_application_traffic_secret_N. 516 Figure 6: Message Flow for Full TLS1.3 Handshake 518 5.2.2. EAP-TLS1.3 handshake procedure 520 EAP-TLS mutual authentication in the case of TLS1.3. defined in the 521 draft-ietf-emu-eap-tls13. TLS 1.3 provides significantly improved 522 security, privacy, and reduced latency when compared to earlier 523 versions of TLS. EAP-TLS with TLS 1.3 further improves security and 524 privacy by mandating use of privacy and revocation checking. 526 EAP Peer EAP Server 528 EAP-Request/ 529 <-------- Identity 530 EAP-Response/ 531 Identity (Privacy-Friendly) --------> 532 EAP-Request/ 533 EAP-Type=EAP-TLS 534 <-------- (TLS Start) 535 EAP-Response/ 536 EAP-Type=EAP-TLS 537 (TLS ClientHello) --------> 538 EAP-Request/ 539 EAP-Type=EAP-TLS 540 (TLS ServerHello, 541 TLS EncryptedExtensions, 542 TLS CertificateRequest, 543 TLS Certificate, 544 TLS CertificateVerify, 545 TLS Finished, 546 <-------- ) 547 EAP-Response/ 548 EAP-Type=EAP-TLS 549 (TLS Certificate, 550 TLS CertificateVerify, 551 TLS Finished) --------> EAP-Request/ 552 EAP-Type=EAP-TLS 553 <-------- TLS Application Data 0x00 554 EAP-Response/ 555 EAP-Type=EAP-TLS --------> 556 <-------- EAP-Success 558 Figure 7: EAP-TLS mutual authentication with TLS1.3 handshake 560 5.2.3. raw public keys EAP-TLS1.3 exchange 562 This section describes EAP-TLS1.3 extend using raw public keys, the 563 procedures is as follows, both client and server have the extension 564 "key_share", the "key_share" extension contains the endpoint's 565 cryptographic parameters. the "signature_algorithm" extension 566 contains the signature algorithm and hash algorithms the client and 567 server can support for the new signature algorithms specific to the 568 IBS algorithms. When IBS is chosen as signature algorithm, the 569 server need to indicated the required IBS signature algorithms int 570 the signature_algorithm extension within the CertificateRequest. 572 Authenticating Peer EAP server 573 ------------------- ------------- 574 <- EAP-Request/ 575 Identity 576 EAP-Response/ 577 Identity (MyID) -> 578 <- EAP-Request/ 579 EAP-Type=EAP-TLS 580 (TLS Start) 581 EAP-Response/ 582 EAP-Type=EAP-TLS 583 (TLS client_hello 584 +key_share 585 +signature_algorithm 586 server_certificate_type, 587 client_certificate_type)-> 589 <- EAP-Request/ 590 EAP-Type=EAP-TLS 591 (TLS server_hello, 592 +key_share 593 {EncryptedExtensions} 594 {client_certificate_type} 595 {server_certificate_type} 596 {certificate} 597 {CertificateVerify} 598 {certificateRequest} 599 {Finished} 600 ) 601 EAP-Response/ 602 EAP-Type=EAP-TLS 603 ({certificate} 604 {CertificateVerify} 605 {Finished} 606 ) -> 607 EAP-Request/ 608 EAP-Type=EAP-TLS 609 <--TLS Application Data 0x00 611 EAP-Response/ 612 EAP-Type=EAP-TLS--> 613 <- EAP-Success 615 Figure 8: EAP-TLS1.3 authentication procedure with raw public keys 617 5.2.4. EAP-TLS1.3-IBS example 619 When the EAP server receives the client hello, it processes the 620 message. Since it has an ECCSI raw public key from the KMS, it 621 indicates that it agrees to use ECCSI and provides an ECCSI key by 622 placing the SubjectPublicKeyInfo structure into the Certificate 623 payload back to the client, including the OID, the identity of 624 server, ServerID, which is the public key of server also, and hash 625 value of KMS public parameters. The client_certificate_type 626 indicates that the TLS server accepts raw public key. The TLS server 627 demands client authentication, and therefore includes a 628 certificate_request, which requires the client to use eccsi_sha256 629 for signature. A signature value based on the eccsi_sha256 algorithm 630 is carried in the CertificateVerify. The client, which has an ECCSI 631 key, returns its ECCSI public key in the Certificate payload to the 632 server, which includes an OID for the ECCSI signature. The example 633 of EAP-TLS1.3-IBS is as follows: 635 Authenticating Peer EAP server 636 ------------------- ------------- 637 <- EAP-Request/ 638 Identity 639 EAP-Response/ 640 Identity (MyID) -> 641 <- EAP-Request/ 642 EAP-Type=EAP-TLS 643 (TLS Start) 644 EAP-Response/ 645 EAP-Type=EAP-TLS 646 (TLS client_hello 647 signature_algorithm = (eccsi_sha256) 648 server_certificate_type = (RawPublicKey) 649 client_certificate_type = (RawPublicKey))-> 651 <- EAP-Request/ 652 EAP-Type=EAP-TLS 653 (TLS server_hello, 654 +key_share 655 {client_certificate_type = RawPublicKey} 656 {server_certificate_type = RawPublicKey} 657 {certificate = (1.3.6.1.5.5.7.6.29, hash 658 value of ECCSIPublicParameters, 659 serverID)} 660 {certificate_request = (eccsi_sha256)} 661 {certificate_verify = {ECCSI-Sig-Value}} 662 {Finished} 664 ) 665 EAP-Response/ 666 EAP-Type=EAP-TLS 667 ({certificate = ((1.3.6.1.5.5.7.6.29, 668 hash value of ECCSIPublicParameters), 669 ClientID)}, 670 {certificate_verify = (ECCSI-Sig-Value)}, 671 {Finished}) 672 ---> 673 EAP-Request/ 674 EAP-Type=EAP-TLS 675 <----TLS Application Data 0x00) 676 EAP-Response/ 677 EAP-Type=EAP-TLS----> 678 <---- EAP-Success 680 Figure 9: EAP-TLS1.3-IBS example 682 6. Security Considerations 684 TBD 686 7. IANA Considerations 688 This document registers the following item in the "Method Types" 689 registry under the "extensible Authentication Protocol(EAP) Registry" 690 heading. 692 +---------+-------------------+ 693 | Value | Description | 694 +---------+-------------------+ 695 | TBD | EAP-TLS-IBS | 696 +---------+-------------------+ 698 8. Acknowledgement 700 TBD 702 9. References 704 9.1. Normative References 706 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 707 Levkowetz, Ed., "Extensible Authentication Protocol 708 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 709 . 711 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 712 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 713 March 2008, . 715 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 716 (TLS) Protocol Version 1.2", RFC 5246, 717 DOI 10.17487/RFC5246, August 2008, 718 . 720 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 721 Housley, R., and W. Polk, "Internet X.509 Public Key 722 Infrastructure Certificate and Certificate Revocation List 723 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 724 . 726 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 727 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 728 Transport Layer Security (TLS) and Datagram Transport 729 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 730 June 2014, . 732 9.2. Informative references 734 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 735 Signatures for Identity-Based Encryption (ECCSI)", 736 RFC 6507, DOI 10.17487/RFC6507, February 2012, 737 . 739 Authors' Addresses 741 Meiling Chen (editor) 742 China Mobile 743 32, Xuanwumen West 744 BeiJing, BeiJing 100053 745 China 747 Email: chenmeiling@chinamobile.com 749 Li Su 750 China Mobile 751 32, Xuanwumen West 752 BeiJing 100053 753 China 755 Email: suli@chinamobile.com 757 Haiguang Wang 758 Huawei International Pte. Ltd. 759 11 North Buona Vista Dr, #17-08 760 Singapore 138589 761 SG 763 Phone: +65 6825 4200 764 Email: wang.haiguang1@huawei.com