idnits 2.17.1 draft-chen-rats-tee-identification-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 is 1 instance of too long lines in the document, the longest one being 49 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 358: '...rivation process MUST be executed in T...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2021) is 917 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS P. Yang 3 Internet-Draft M. Chen 4 Intended status: Standards Track Li. Su 5 Expires: April 25, 2022 China Mobile 6 October 22, 2021 8 Use TEE Identification in EAP-TLS 9 draft-chen-rats-tee-identification-03 11 Abstract 13 In security considerations, identities of devices like 14 certifications, private keys should be protected and cannot be 15 exposed in public in plaintext during whole lifecycle. When using 16 these identities to make authentications a unified architecture to 17 prevent identity information leakage is needed. This document 18 creates a secure and trusted TEE authentication architecture to 19 authenticate a device's identity based on EAP-TLS and TEE. In this 20 architecture, certificate and handshake keys which are used for EAP- 21 TLS will be executed in TEE. Communication establishment with EAP- 22 TLS Server will be executed in REE. A middle layer is introduced to 23 communicate between TEE and REE to compose the original function of 24 EAP-TLS Client. TEE authentication could be used in LAN or WLAN 25 scenarios. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 25, 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Threat Model and Motivation . . . . . . . . . . . . . . . . . 4 64 3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. motivation . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Middle Layer Message . . . . . . . . . . . . . . . . . . 7 68 4.2. information pre-stored in TEE . . . . . . . . . . . . . . 8 69 4.3. key derivation process in TEE . . . . . . . . . . . . . . 8 70 4.4. Mutual Authentication Procedure . . . . . . . . . . . . . 9 71 4.5. Ticket Establishment . . . . . . . . . . . . . . . . . . 11 72 4.6. Resumption . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.8. Hello Retry Request . . . . . . . . . . . . . . . . . . . 11 75 5. Use Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 79 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 Mutual authentication is an important way to implement identity 85 authentication, it refers to both sides of the authentication 86 procedure to verify each other's identity. Typical examples of 87 mutual authentication are EAP-TLS and EAP-AKA, and EAP-AKA has been 88 used in telecommunication networks for subscriber's network access 89 authentication. 91 However, mutual authentication protocol itself is not sufficient to 92 provide a trusted authentication procedure. The storage and 93 execution of identity related to authentication also need to be 94 protected. That's also why SIM (Subscriber Identity Module) is 95 introduced in telecommunication network to enhance EAP-AKA. SIM 96 provides a trusted execution environment, which could be used to 97 store and execute identity and key derivation about EAP-AKA protocol. 98 And that's one of the reasons why applications could treat the 99 telecommunication network as a trusted network, and secret 100 information like verification code about account of bank could be 101 transferred in this network. 103 In IoT devices or other Internet-access devices, there is still no 104 unified and trusted mechanism that can authenticate a device's 105 identity in a trusted way in LAN or WLAN. So this document tries to 106 use EAP-TLS and TEE (Trusted Execution Environment) to create a 107 secure and trusted architecture to standardize the trusted 108 authentication in LAN or WLAN. 110 EAP-TLS1.3 protocol is defined in RFC 8446[RFC8446], which is treated 111 as a security method that can provide client-server mutual 112 authentication. Usually the authentication server is highly 113 protected and monitored by operators. So the server could be treated 114 as a trust party. But client is more likely to be vulnerable due to 115 the lack of sufficient security mechanisms. TEE used in client could 116 make sure that any code within that environment cannot be tampered 117 with, and that any data used by such code cannot be read or tampered 118 with by any code outside that environment. 120 The primary goal of this document is to provide a trusted 121 authentication architecture which uses EAP-TLS as the essential 122 authentication protocol and TEE as the security shelter to store and 123 execute private key derivations and establish encrypted communication 124 channel. The specific method is to add a middle layer in REE and TEE 125 to exchange data in the form of EAP-TLS. 127 2. Terminology 129 The readers should be familiar with the terms defined in. 131 In addition, this document makes use of the following terms: 133 TEE: Trust Execution Environment. 135 REE: Rich Execution Environment. 137 ML: Middle Layer. 139 IML: Inner Middle Layer. 141 EML: External Middle Layer. 143 peer: The entity that responds to the authenticator. 145 backend authenticator server: A backend authentication server is an 146 entity that provides an authentication service to an 147 authenticator. When used, this server typically executes EAP 148 methods for the authenticator. 150 EAP server: The entity that terminates the EAP authentication method 151 with the peer. In the case where no backend authentication server 152 is used, the EAP server is part of the authenticator. In the case 153 where the authenticator operates in pass-through mode, the EAP 154 server is located on the backend authentication server. 156 EAP-TLS: Extensible Authentication Protocol-Transport Layer. 158 EAP-AKA: Extensible Authentication Protocol-Authentication. 160 SIM: Subscriber Identity Module. 162 DevID: Initial Device Identifier. 164 3. Threat Model and Motivation 166 3.1. Threat Model 168 When executing authentication process in devices, the threat model 169 could be treated as shown in figure 1. In this figure, there are 170 three possible statuses that attackers could manipulate the 171 authentication information: authentication in rest, authentication in 172 process, and authentication in translation. 174 +--------------+----Attacker 175 | | | 176 +--------+--------------+----+ | 177 | REE | | | | 178 | +-----v---------+ | | | +------------+ 179 | | TEE/Identity +----v----+------v--+ Auth center| 180 | +---------------+ | +------------+ 181 | | 182 +----------------------------+ 183 Figure 1: threat model of authentication 185 (1) Authentication in rest. In order to protect identity information 186 in rest from stealing and tampering, methods like DevID or encrypted 187 storage could be used. 189 (2) Authentication in process. In this status the authentication 190 information needs to be calculated and prepared by the device to 191 transfer to authentication center. When a device is preparing to 192 authenticate, some processes need to be executed. For example, key 193 derivation from the chosen ID, encrypted channel establishment 194 between device and Auth Center. When designing an authentication 195 protocol or method, the device is always treated as an atomic point 196 and is secure with no doubt. However, any device is composed of 197 component like hardware, firmware, and operating system. When 198 processing the Identification information in REE environment, the ID 199 may be compromised. 201 (3) Authentication in translation. This status is also easy to 202 deploy in network protocols like TLS. After exchanging handshake 203 keys, it is hard to crack information during translation. 205 3.2. motivation 207 In IETF and other organizations, there are lots of authentication 208 methods and identity systems like DevID, X509.3, X802.1, etc. These 209 procedures are used in different scenario and different network 210 layers. When compared to the threat model, the protection of 211 authentication in process is still undetermined. 213 For example, DevID could prevent the attack of status 1 in threat 214 model. When composed with EAP-TLS, the composition can prevent 215 attack from both status 1 and 3 in threat model. But about the 216 attack for status 2 in threat model, there is no direct solution. 218 There are two possible methods to mitigate this potential risk of 219 status 2 of threat model. The first one is to put all the 220 authentication process and relevant software and network stacks in 221 TEE environment, as shown in figure 2. This method requires large 222 scale TEE and is hard to deploy in resource restricted devices. 224 +------------+ Trusted +------------+ 225 |Device |authentication| | 226 | <--------------> Auth center| 227 | TEE | | | 228 +------------+ +------------+ 230 Figure 2: solution 1: all authentication is under TEE 232 In some cases, TEE is restricted resource and cannot cover all the 233 authentication procedure. Like TPM and other TEE chips for IoT 234 devices, only very limited computing capability is available. When 235 pursuing concise architecture of authentication that consumes minimal 236 TEE, the second solution needs to be discovered. 238 The second solution builds a strict and limited middle layer 239 interface to communicate between TEE and REE. The TEE will only in 240 charge of the generation of encrypted and unreusable identities for 241 authentication. The REE could in charge of the other process of 242 authentication. This design could address the authentication in 243 process threat model. Before going into the detail of TEE 244 authentication architecture, there are three key features about the 245 middle layer need to be point out. (1) Transportation tunnel about 246 authentication is built between TEE and authentication server. (2)The 247 TEE should verify server ID first, otherwise never expose client 248 identity. (3) Nonce and handshake key are used to encrypt ID to 249 prevent replay attack. 251 These three features could make sure: 253 Even the REE of the device is compromised like the memory is dumped, 254 the attackers cannot get any plain text of authentication 255 information. 257 The encrypted message could be stolen, but cannot be reused because 258 of random nonce produced by TEE and server. 260 Attackers cannot use a fake server identity to defraud a client's 261 real identity. Because the private key of server's certificate never 262 exposed and the signature with nonce cannot be imitated. 264 The usage of trusted authentication is extensive. Trusted 265 authentication could be used in factory, campus, transportation 266 sector, etc, in where devices need to get access to network by 267 identifying their identity. Also, devices also need to know the 268 network's identity. In fact, anywhere that needs to identify 269 devices' Identification by LAN or WLAN could use this architecture. 271 4. Architecture Overview 273 This architecture brings in a Middle Layer which is implemented in 274 TEE and REE to translate information between TEE and REE. The 275 structure of this Middle Layer is shown below. 277 +------------------------------------------------------+ 278 | +----------------------------+ REE | 279 | | TEE | | 280 | | +---------------+ +------+ | +-------------------+ | +-------+ 281 | | | certificates| | | | |---------+ | | | | 282 | | +---------------+ | inner| | || | | | | | 283 | | +---------------+ |middle<---->external| EAP-TLS| | |EAP-TLS| 284 | | | key | | layer| | ||middle | Client <-----> server| 285 | | | derivation | | | | ||layer | | | | | 286 | | +---------------+ +------+ | |---------+ | | | | 287 | +----------------------------+ |-------------------+ | +-------+ 288 +------------------------------------------------------+ 290 Figure 3: architecture of middle layer 292 In figure 3, the middle layer is separated in two parts: Inner Middle 293 Layer (IML) and External Middle Layer (EML). The IML is responsible 294 for 296 a. Key derivation b. Response to EML about EAP-TLS encryption and 297 decryption relevant message. 299 In this document, the EML could be set as a part of EAP-TLS Client 300 function which is responsible for: 302 a. Communicate with EAP-TLS Server b. Request encryption and 303 decryption relevant messages from IML. 305 The communication mechanism between IML and EML should follow the 306 specific trust computing architecture like Intel Enclave and 307 TrustZone which is out of this document's scope. 309 4.1. Middle Layer Message 311 The message transmitted between IML and EML will follow the format of 312 TLS1.3, but not all TLS1.3 [RFC8446]message will be transmitted. The 313 IML only accept message relevant to encryption and decryption. The 314 structure of Middle Layer Message is shown below. 316 enum{ 317 Random; 318 keyshareExtension; 319 PreSharedKeyExchange 320 CertificateList 321 CertificateVerify 322 Finished 323 NewSessionTicket 324 ApplicationData 325 Alert 326 }ParameterType 328 Struct{ 329 bool request//true:request; false response. If it's request message, then the payload of message should be set as zero. 330 ParameterType type 331 uint24 length 332 select(type){ 333 case Random randomValue 334 case KeyshareExtension keyshareextensionValue 335 case PreSharedKeyExchange value; 336 case CertificateList 337 case CertificateVerify 338 case Finished 339 case NewSessionTicket 340 case ApplicationData 341 case Alert 342 } 343 }MiddleLayerMessage 345 4.2. information pre-stored in TEE 347 (1) Certificate that complies with X509.3. If using EAP-TLS as the 348 authentication protocol, then the ID of the TEE enabled device is the 349 certificate complies with X509.3. In this document, the certificate 350 of this device is the only item that needs to be stored in TEE before 351 the process of EAP-TLS starts. And regarding to how to get this 352 certificate or update this certificate is out of scope. The 353 certificate will never be allowed to be exposed outside the TEE in 354 plaintext. 356 4.3. key derivation process in TEE 358 Key derivation process MUST be executed in TEE. 360 4.4. Mutual Authentication Procedure 362 Figure 4 illustrates the steps of TEE identification based on EAP- 363 TLS. From the view of EAP-TLS Server there are no changes of the 364 procedure. All the changes are in the EAP-TLS Peer side. This 365 document defines 6 middle layer messages from message 1 to message 6 366 which will be used for different purpose to communicate between IML 367 and EML. The specific steps are shown in bullets below. 369 EAP-TLS Peer 370 +--------------------+ 371 +-----+ +-----+ +-------+ 372 | TEE | | REE | |EAP|TLS| 373 +--+--+ +--+--+ |server | 374 | | +-------+ 375 | | | EAP-Request/ 376 | <-----------------------+ Identity 377 | EAP-Response/ | 378 | Identity(privacy-friendly) | 379 | Recommend random hex +-------> 380 | | | 381 | | EAP-Request/ 382 | <----------------+ EAP-Type=EAP-TLS 383 | | (TLS Start) 384 | Middle layer | 385 <----------------+ Message 1 | 386 | | | 387 Middle layer | | 388 Message 2 +--------------> | 389 | | | 390 | EAP-Response/ | 391 | EAP-Type=EAP-TLS+-----------> 392 | (TLS ClientHello) | 393 | | EAP-Request/ 394 | | EAP-Type=EAP-TLS 395 | | (TLS ServerHello, 396 | <----------------+ TLS EncryptedExtensions, 397 | | TLS CertificateRequest, 398 | | TLS Certificate, 399 | | TLS CertificateVerify, 400 | | TLS Finished) 401 | Middle Layer | 402 <---------------+Message 3 | 403 | | | 404 Middle Layer | | 405 Message 4 +----------------> | 406 | | | 407 | EAP-Response/ | 408 | EAP-Type=EAP-TLS | 409 | (TLS Certificate, | 410 | TLS CertificateVerify, | 411 | TLS Finished) +------------> 412 | | | 413 | | EAP-Request/ 414 | | EAP-Type=EAP-TLS 415 | | (TLS Application 416 | <---------------+ Data 0x00) 417 | | | 418 | Middle Layer | 419 <--------------+ Message 5 | 420 | | | 421 Middle Layer | | 422 Message 6 +---------------> | 423 | | | 424 | EAP-Response/ | 425 | EAP-Type=EAP-TLS+-------------> 426 | | | 427 | <------------------+EAP-Success 428 | | | 429 | | | 431 Figure 4: Mutual TEE Identification based on EAP-TLS 433 In order to complete ClientHello Message, the Key_Share Extension 434 message is needed. This message involves the key derivation function 435 which Must be executed in TEE. So the Middle Layer Message 1 is 436 KeyShareExtension request from EML to IML. 438 Middle Layer Message 2 from IML responses to message1 and returns the 439 KeyShareExtension response to EML. 441 Middle Layer Message 3 includes plaintext ServerHello message and 442 encrypted Server Params and Auth. Since EML does not carry the 443 relevant private key which is derived from KeyShareExtension, it will 444 transfer this message to IML to decode. Message 3 also includes the 445 entire handshake context which will be used to create 446 CertificateVerify and Finished context. 448 In Message 4, encrypted TLS Client Certificate, TLS CertificateVerify 449 and TLS Finished message will be included. 451 Message 5 is the encrypted application data 0x00, which will be sent 452 to IML to decode. 454 After decrypted the message 5, the plaintext will be packed in 455 message 6 and sent to EML. Then EML will make the determination if 456 the authentication procedure is finished. 458 4.5. Ticket Establishment 460 If the NewSessionTicket context is sent by EAP-TLS Server, it will be 461 packed in the middle of Server's TLS Finished message and TLS 462 Application Data 0x00 message. This context will be included in 463 message 5 by EML and conveyed to IML. After received message 5, IML 464 will decrypt and retain this ticket establishment context for 465 resumption. 467 4.6. Resumption 469 After the Client has received a NewSessionTicket message from the 470 EAP-TLS Server, the Client can use PSK mode to connect with EAP-TLS 471 Server. This action happens in TLS ClientHello message, in which the 472 Pre-shared-key extension will be used. Need to notice that the 473 action of resumption is deployed by EAP-TLS Client. EAP-TLS Client 474 determines if it will use NewSessionTicket to rebuild connection with 475 EAP-TLS Server. If do so, the message 1 will include the type of 476 NewSeesionTIcket request to IML. After received this request 477 message, IML will generate the Pre-shared key extension in Message2 478 for EMLREE to generate ClientHello Message. 480 4.7. Termination 482 TLS Error Alert could be sent both by EAP-TLS Server and Client. If 483 sent by Server, the message will be transferred to IML by EML to 484 decrypt. And the IML will notify EML in message 4 or 6. If the TLS 485 Error Alert message is sent by IML, it will be generate in message4, 486 which will be directly transferred to EML. 488 4.8. Hello Retry Request 490 This message happens after the EAP-TLS Server received ClientHello. 491 Since the negotiation is not successful, the Hello Retry Request 492 message will be sent in plaintext to EAP-TLS Client. 494 5. Use Scenarios 496 Like SIM/eSIM is for 4G/5G to authentication, TEE authentication 497 could be used in WLAN and LAN for devices that need to gain access to 498 the network. TEE authentication could be used as complementary of 499 RATs and DevID. In scenarios like manufacturing industry and some 500 IoT scenes, to recognize a device's identity may be important, the 501 specific use scenarios are shown below. 503 Scenario 1, TEE authentication could be used in situations like 504 industrial Internet, in where machines need to have their identity 505 checked for property management or network access. 507 Scenario 2, TEE authentication could be used in situations like 508 campus or factory, in where devices need to authenticate to gain 509 access to network. 511 Scenario 3, TEE authentication could be used in situations in where 512 identities of devices need to be traced with trust. 514 6. Security Considerations 516 This document uses the concept of TEE, which could be considered as a 517 trusted anchor in device that cannot be tampered. The REE of a 518 device cannot be fully trusted or it may be tampered by attackers. 519 The middle layer has two parts: the IML and the EML. Even though the 520 messages conveyed between IML and EML are already encrypted, TEE 521 cannot guarantee the integrity of the message in REE. In another 522 word, DoS attack against REE cannot be prevented. For example, EAP- 523 AKA in 5G involves two components: UE and ME. UE includes SIM and 524 represents authentication procedure, ME represents establishing 525 communication between mobile phone and base station. If an attacker 526 invades into the ME and tampered the communication message, a DOS 527 attack will be implemented. 529 The other aspects of the security considerations will follow TLS1.3, 530 EAP-TLS, and RATs draft--ietf-rats-architecture. 532 7. IANA Considerations 534 No new item needs to register in IANA. 536 8. Acknowledgement 538 TBD 540 9. Normative References 542 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 543 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 544 . 546 Authors' Addresses 547 Penglin Yang 548 China Mobile 549 32, Xuanwumen West 550 BeiJing, BeiJing 100053 551 China 553 Email: yangpenglin@chinamobile.com 555 Meiling Chen 556 China Mobile 557 32, Xuanwumen West 558 BeiJing, BeiJing 100053 559 China 561 Email: chenmeiling@chinamobile.com 563 Li Su 564 China Mobile 565 32, Xuanwumen West 566 BeiJing 100053 567 China 569 Email: suli@chinamobile.com