idnits 2.17.1 draft-chen-rats-tee-identification-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 : ---------------------------------------------------------------------------- ** 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 236: '...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 (May 28, 2021) is 1064 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: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EMU P. Yang 3 Internet-Draft M. Chen 4 Intended status: Standards Track Li. Su 5 Expires: November 29, 2021 China Mobile 6 May 28, 2021 8 Use TEE Identification in EAP-TLS 9 draft-chen-rats-tee-identification-00 11 Abstract 13 In security considerations, identity of a device should be protected 14 and cannot be exposed in public. Based on this purpose, this 15 document specifies the architecture of TEE(Trust Execution 16 Environment) identification based on EAP-TLS. In this architecture, 17 TEE is in charge of protecting the certificate and generating 18 handshake keys which will be used for EAP-TLS authentication. 19 REE(Rich Execution Environment) is in charge of building 20 communication with EAP-TLS Server. A middle layer is introduced to 21 communicate with separate parts of EAP-TLS in TEE and REE to 22 implement its original functionality. 24 This architecture could be used in data link layer and also 25 application layer to implement identity authentication under the 26 protection of TEE and EAP-TLS. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 29, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Middle Layer Message . . . . . . . . . . . . . . . . . . 4 66 3.2. information pre-stored inTEE . . . . . . . . . . . . . . 5 67 3.3. key derivation process in TEE . . . . . . . . . . . . . . 6 68 3.4. Mutual Authentication Procedure . . . . . . . . . . . . . 6 69 3.5. Ticket Establishment . . . . . . . . . . . . . . . . . . 8 70 3.6. Resumption . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.8. Hello Retry Request . . . . . . . . . . . . . . . . . . . 9 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Identity of a device in security region is always important. 82 However, there is still no a unified and secure mechanism that can 83 attest a remote device's identity. Another issue is how to store and 84 protect this attest process is still undetermined. This document 85 tries to use TEE and EAP-TLS to create a secure procedure to attest a 86 device's identity. 88 In this document, TEE (Trusted Execution Environment) described in 89 draft-ietf-teep-architecture-14 will be involved. This environment 90 emphasizes that any code within that environment cannot be tampered 91 with, and that any data used by such code cannot be read or tampered 92 with by any code outside that environment. On the contrary, REE 93 (Rich Execution Environment) is an environment that code and data in 94 that environment may be tampered with. TEE is a scarce resource in 95 devices, not every step or relative processes can be included in TEE. 97 EAP-TLS1.3 protocol, defined in RFC 5216[RFC5216], which is 98 recommended by IETF because of its swift and security features is 99 treated as a security method that can provide client-server mutual 100 authentication. This method is based on the assumption that both 101 client and server are trusted or uncompromised by any attacker. 102 Usually, the server of authentication is highly protected and 103 surveilled by operators, which could be considered as a trust party. 104 But client, especially IoT device, is more likely to be vulnerable 105 due to the lack of sufficient security mechanisms. 107 The primary goal of this document provides a remote identity 108 attestation method which uses EAP-TLS as the essential authentication 109 protocol and TEE as the security shelter to store and execute the 110 certificate and private key derivations. The specific method is to 111 add a middle layer in REE to exchange data in the form of EAP-TLS 112 between EAP-TLS server and TEE/REE. In application scenarios, this 113 method could be used in transport layer authentication, application 114 layer authentication and other scenarios. 116 2. Terminology 118 The readers should be familiar with the terms defined in. 120 In addition, this document makes use of the following terms: 122 TEE: Trust Execution Environment. 124 REE: Rich Execution Environment. 126 IML: Inner Middle Layer. 128 EML: External Middle Layer. 130 peer: The entity that responds to the authenticator. 132 backend authenticator server: A backend authentication server is an 133 entity that provides an authentication service to an 134 authenticator. When used, this server typically executes EAP 135 methods for the authenticator. 137 EAP server: The entity that terminates the EAP authentication method 138 with the peer. In the case where no backend authentication server 139 is used, the EAP server is part of the authenticator. In the case 140 where the authenticator operates in pass-through mode, the EAP 141 server is located on the backend authentication server. 143 3. Architecture Overview 145 This architecture will bring in a Middle Layer which is implemented 146 in TEE and REE to translate information between TEE and EAP-TLS 147 Client. The structure of this Middle Layer is shown below. 149 In figure one, the middle layer is separated in two parts: inner 150 middle layer (IML) and external middle layer (EML). The IML is 151 responsible for: 153 +------------------------------------------------------+ 154 | +----------------------------+ REE | 155 | | TEE | | 156 | | +---------------+ +------+ | +-------------------+ | +-------+ 157 | | | certificates| | | | |---------+ | | | | 158 | | +---------------+ | inner| | || | | | | | 159 | | +---------------+ |middle<---->external| EAP-TLS| | |EAP-TLS| 160 | | | key | | layer| | ||middle | Client <-----> server| 161 | | | derivation | | | | ||layer | | | | | 162 | | +---------------+ +------+ | |---------+ | | | | 163 | +----------------------------+ |-------------------+ | +-------+ 164 +------------------------------------------------------+ 166 Figure 1: architecture of middle layer 168 a. Key derivation b. Response to EML when relevant to encryption 169 and decryption. 171 In this document, the EML could be set as a part of EAP-TLS Client 172 function which is responsible for: 174 a. Communicate with EAP-TLS Server b. Request encryption and 175 decryption relevant messages from IML. 177 The communication mechanism between IML and EML should follow the 178 specific trust computing architecture like Intel Enclave or TCG TSS 179 which is out of this document's scope. 181 3.1. Middle Layer Message 183 The message transmitted between IML and EML will follow the format of 184 TLS1.3[RFC8446], but not all TLS1.3 message will be transmitted. The 185 IML only accept message related to encryption and decryption. The 186 structure of Middle Layer Message is shown below. 188 enum{ 189 Random; 190 keyshareExtension; 191 PreSharedKeyExchange 192 CertificateList 193 CertificateVerify 194 Finished 195 NewSessionTicket 196 ApplicationData 197 Alert 198 }ParameterType 200 Struct{ 201 bool request// true:request; false response 202 ParameterType type 203 uint24 length 204 select(type){ 205 case Random randomValue 206 case KeyshareExtension keyshareextensionValue 207 case PreSharedKeyExchange value; 208 case CertificateList 209 case CertificateVerify 210 case Finished 211 case NewSessionTicket 212 case ApplicationData 213 case Alert 214 } 215 }MiddleLayerMessage 217 3.2. information pre-stored inTEE 219 (1) Certificate that complies with X509.3. In general, the ID of the 220 TEE enabled device is the certificate. In specific, the ID of the 221 device is "subject name" and "subjectUniqueID". In this 222 architecture, the certificate of this device is the only item that 223 needs to be stored in TEE before the process of EAP-TLS starts. And 224 regarding to how to get this certificate or update this certificate 225 is out of scope. The EAP-TLS will never allowed to afford outside 226 the TEE in plain text. 228 (2) Handshake Context during EAP-TLS procedure. During the EAP-TLS 229 procedure TEE need to store the handshake context which is generated 230 by REE. This is because EAP-TLS procedure needs handshake context 231 and certain private key to generate CertificateVerify and Finished 232 information. 234 3.3. key derivation process in TEE 236 Key derivation process MUST be executed in TEE. 238 3.4. Mutual Authentication Procedure 240 In figure 2, there are two steps that need the TEE to be invoked. 241 The first is TLS-ClientHello Parameter Response which will provide 242 parameters of key_share, signature_algorithm, psk_key_exchange_modes, 243 and pre_shared_key. These parameters will be sent to REE, and REE 244 will use process of TLS-ClientHello to send these messages to EAP-TLS 245 Server. The second step is TLS-Finished Parameter Response which 246 will provide parameters of TLS Certificate, TLS CertificateVerify, 247 and TLS Finished(not confirmed yet). The specific description of 248 these two steps will be discussed in section 2.2 and 2.3. 250 Divisions of Responsibility: TEE is in charge of the cipher security, 251 REE is in charge of the conversation integrity. And there may have 252 some tamper-like dos attacks, but there have no phony attack and leak 253 of keys. 255 EAP-TLS Peer 256 +--------------------+ 257 +-----+ +-----+ +-------+ 258 | TEE | | REE | |EAP|TLS| 259 +--+--+ +--+--+ |server | 260 | | +-------+ 261 | | | EAP-Request/ 262 | <-----------------------+ Identity 263 | EAP-Response/ | 264 | Identity(privacy-friendly) | 265 | Recommend random hex +-------> 266 | | | 267 | | EAP-Request/ 268 | <----------------+ EAP-Type=EAP-TLS 269 | | (TLS Start) 270 | Middle layer | 271 <----------------+ Message 1 | 272 | | | 273 Middle layer | | 274 Message 2 +--------------> | 275 | | | 276 | EAP-Response/ | 277 | EAP-Type=EAP-TLS+-----------> 278 | (TLS ClientHello) | 279 | | EAP-Request/ 280 | | EAP-Type=EAP-TLS 281 | | (TLS ServerHello, 282 | <----------------+ TLS EncryptedExtensions, 283 | | TLS CertificateRequest, 284 | | TLS Certificate, 285 | | TLS CertificateVerify, 286 | | TLS Finished) 287 | Middle Layer | 288 <---------------+Message 3 | 289 | | | 290 Middle Layer | | 291 Message 4 +----------------> | 292 | | | 293 | EAP-Response/ | 294 | EAP-Type=EAP-TLS | 295 | (TLS Certificate, | 296 | TLS CertificateVerify, | 297 | TLS Finished) +------------> 298 | | | 299 | | EAP-Request/ 300 | | EAP-Type=EAP-TLS 301 | | (TLS Application 302 | <---------------+ Data 0x00) 303 | | | 304 | Middle Layer | 305 <--------------+ Message 5 | 306 | | | 307 Middle Layer | | 308 Message 6 +---------------> | 309 | | | 310 | EAP-Response/ | 311 | EAP-Type=EAP-TLS+-------------> 312 | | | 313 | <------------------+EAP-Success 314 | | | 315 | | | 317 Figure 2: Mutual TEE Identification based on EAP-TLS 319 In order to complete ClientHello Message, the Key_Share Extension 320 message is needed. This message involves the key derivation function 321 which Must be executed in TEE. So the Middle Layer Message 1 is 322 KeyShareExtension requirement. 324 Middle Layer Message 2 responses to message1 and returns the 325 KeyShareExtension to REE. 327 Middle Layer Message 3 includes plaintext ServerHello message and 328 encrypted Server Params and Auth. Since REE does not carry the 329 relevant private key, it will transfer this message to TEE to decode. 330 Message 3 also include all the context handshake in this session, in 331 which will be used to create CertificateVerify and Finished context. 333 In Message 4, TEE retains the key_share extension, and other message 334 context will be transferred to REE as plaintext. Message 4 also 335 contains context the HMAC of (finished_key, Transcript-Hash(Handshake 336 Context, Certificate, CertificateVerify)), which can only be 337 generated in TEE. 339 Message 5 is the encrypted application data 0x00, which will be sent 340 to TEE to indicate the authentication procedure is finished. 342 After decrypted the message 5, the plaintext will be packed in 343 message 6 and sent to REE. Then REE will make the determination if 344 the authentication procedure is finished 346 3.5. Ticket Establishment 348 If the ticket establishment context is sent by EAP-TLS Server, it 349 will be packed in the middle of Server's TLS Finished message and TLS 350 Application Data 0x00 message. This context will be included in 351 message 5 by REE and conveyed to TEE. After received message 5, TEE 352 will decrypt and retain this ticket establishment context for 353 resumption. 355 3.6. Resumption 357 After the Client has received a NewSessionTicket message from the 358 EAP-TLS Server, the Client can use PSK mode to connect with EAP-TLS 359 Server. This action happens in TLS ClientHello message, in which the 360 Pre-shared-key extension will be used. Need to notice that the 361 action of resumption is deployed by REE. REE determines if it will 362 use NewSessionTicket to rebuild connection with EAP-TLS Server. If 363 do so, the message 1 will include the type of NewSeesionTIcket to 364 TEE. After received this message, TEE will generate the Pre-shared 365 key extension in Message2 for REE to generate ClientHello Message. 367 3.7. Termination 369 TLS Error Alert could be sent both by EAP-TLS Server and Client. If 370 sent by Server, the message will be transferred to TEE to decrypt. 371 And the TEE will notify REE in message 4 or 6. If the TLS Error 372 Alert message is sent by TEE, it will be generate in message4, which 373 will be directly transferred to REE. 375 3.8. Hello Retry Request 377 This message happens after the EAP-TLS Server received ClientHello. 378 Since the negotiation is not successful, the Hello Retry Request 379 message will be sent in plaintext. 381 4. Security Considerations 383 This document used the concept of TEE, which can be considered as a 384 trusted anchor in device that cannot be tampered. But the REE of a 385 device cannot be fully trusted or it may be tampered by attackers. 386 The middle layer has two parts: the inner middle layer and the 387 external middle layer. Even though the message from inner middle 388 layer and external middle layer is already encrypted, TEE cannot 389 guarantee the integrity of these messages and the behavior of EAP-TLS 390 Client. So this architecture can make sure that crucial information 391 like certificate or identity cannot be obtained by illegal party, but 392 cannot deny DOS attack. In fact unless there is trust channel that 393 directly connect between TEE and EAP-TLS Server, otherwise the DOS 394 attack cannot be prevented. For example, in the SUCI-SUPI 395 architecture in 5G system the ME is in charge of establishing 396 communications between USIM and NG RAN. If an attacker invaded into 397 the ME and tampered the SUCI message, a DOS attack will be 398 implemented. 400 The other aspects of the security considerations will follow TLS1.3, 401 EAP-TLS, and RATs draft--ietf-rats-architecture. 403 5. IANA Considerations 405 TBD 407 6. Acknowledgement 409 TBD 411 7. Normative References 413 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 414 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 415 March 2008, . 417 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 418 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 419 . 421 Authors' Addresses 423 Penglin Yang 424 China Mobile 425 32, Xuanwumen West 426 BeiJing, BeiJing 100053 427 China 429 Email: 430 yangpenglin@chinamobile.com 432 Meiling Chen 433 China Mobile 434 32, Xuanwumen West 435 BeiJing, BeiJing 100053 436 China 438 Email: 439 chenmeiling@chinamobile.com 441 Li Su 442 China Mobile 444 32, Xuanwumen West 446 BeiJing 448 100053 450 China 452 Email: 453 suli@chinamobile.com