idnits 2.17.1 draft-chen-rats-tee-identification-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 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 240: '...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 (June 03, 2021) is 1052 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) == Unused Reference: 'RFC8446' is defined on line 415, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: December 5, 2021 China Mobile 6 June 03, 2021 8 Use TEE Identification in EAP-TLS 9 draft-chen-rats-tee-identification-01 11 Abstract 13 In security considerations, identity of a device should be protected 14 and cannot be exposed in public in plaintext. The storage and 15 execution of identity in device also need to be protected during the 16 lifecycle. Based on this purpose, this document specifies the 17 architecture of TEE identification based on EAP-TLS. In this 18 architecture, certificate protection and handshake keys generation 19 which are used for EAP-TLS authentication will be executed in TEE. 20 Communication establishment with EAP-TLS Server will be executed in 21 REE. A middle layer is introduced to communicate between TEE and REE 22 to compose the original function of EAP-TLS Client. 24 TEE identification based on EAP-TLS could be used in different 25 network layers to implement identity authentication. 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 December 5, 2021. 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. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Middle Layer Message . . . . . . . . . . . . . . . . . . 5 65 3.2. information pre-stored in TEE . . . . . . . . . . . . . . 5 66 3.3. key derivation process in TEE . . . . . . . . . . . . . . 6 67 3.4. Mutual Authentication Procedure . . . . . . . . . . . . . 6 68 3.5. Ticket Establishment . . . . . . . . . . . . . . . . . . 8 69 3.6. Resumption . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.7. Termination . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.8. Hello Retry Request . . . . . . . . . . . . . . . . . . . 8 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 In security considerations, identity of a device should be protected 81 and cannot be exposed in public in plaintext. The storage and 82 execution of identity in device also need to be protected during the 83 lifecycle. Even though the authentication protocol like EAP-TLS, 84 802.1X can guarantee the procedure of communication is security but 85 they are all built by the assumption that the device and the 86 implementation of procedure is trusted. In fact, security is the 87 result of multi-layer composition which could affect the security 88 both in protocol level and equipment level. Based on these 89 considerations, there is still no a unified and trusted mechanism 90 that can attest a remote device's identity in a trusted way in 91 Internet. So this document tries to use TEE and EAP-TLS to create a 92 secure and trusted procedure to attest a device's identity. 94 In this document, TEE (Trusted Execution Environment) described in 95 draft-ietf-teep-architecture-14 will be involved. This environment 96 emphasizes that any code within that environment cannot be tampered 97 with, and that any data used by such code cannot be read or tampered 98 with by any code outside that environment. On the contrary, REE 99 (Rich Execution Environment) is an environment that code and data in 100 that environment may be tampered with. Need to mention that in 101 device TEE is scarce resource which can only involve security 102 critical processes inside. 104 EAP-TLS1.3 protocol, defined in RFC RFC 5216[RFC5216] which is 105 recommended by IETF because of its swift and security features. This 106 protocol is treated as a security method that can provide client- 107 server mutual authentication. In this protocol there is an 108 assumption that both client and server are trusted or uncompromised 109 by any attacker. Usually the server of authentication is highly 110 protected and surveilled by operators, this means that the server 111 could be considered as a trust party. But client especially IoT 112 device is more likely to be vulnerable due to the lack of sufficient 113 security mechanisms. 115 The primary goal of this document is to provide a remote identity 116 attestation method which uses EAP-TLS as the essential authentication 117 protocol and TEE as the security shelter to store and execute the 118 certificate and private key derivations. The specific method is to 119 add a middle layer in REE and TEE to exchange data in the form of 120 EAP-TLS. In application scenarios, this method could be used in 121 transport layer authentication, application layer authentication and 122 other scenarios. 124 2. Terminology 126 The readers should be familiar with the terms defined in. 128 In addition, this document makes use of the following terms: 130 TEE: Trust Execution Environment. 132 REE: Rich Execution Environment. 134 ML: Middle Layer. 136 IML: Inner Middle Layer. 138 EML: External Middle Layer. 140 peer: The entity that responds to the authenticator. 142 backend authenticator server: A backend authentication server is an 143 entity that provides an authentication service to an 144 authenticator. When used, this server typically executes EAP 145 methods for the authenticator. 147 EAP server: The entity that terminates the EAP authentication method 148 with the peer. In the case where no backend authentication server 149 is used, the EAP server is part of the authenticator. In the case 150 where the authenticator operates in pass-through mode, the EAP 151 server is located on the backend authentication server. 153 3. Architecture Overview 155 This architecture will bring in a Middle Layer which is implemented 156 in TEE and REE to translate information between TEE and REE. The 157 structure of this Middle Layer is shown below 159 +------------------------------------------------------+ 160 | +----------------------------+ REE | 161 | | TEE | | 162 | | +---------------+ +------+ | +-------------------+ | +-------+ 163 | | | certificates| | | | |---------+ | | | | 164 | | +---------------+ | inner| | || | | | | | 165 | | +---------------+ |middle<---->external| EAP-TLS| | |EAP-TLS| 166 | | | key | | layer| | ||middle | Client <-----> server| 167 | | | derivation | | | | ||layer | | | | | 168 | | +---------------+ +------+ | |---------+ | | | | 169 | +----------------------------+ |-------------------+ | +-------+ 170 +------------------------------------------------------+ 172 Figure 1: architecture of middle layer 174 In figure 1, the middle layer is separated in two parts: Inner Middle 175 Layer (IML) and External Middle Layer (EML). The IML is responsible 176 for 178 a. Key derivation b. Response to EML about EAP-TLS encryption and 179 decryption relevant message. 181 In this document, the EML could be set as a part of EAP-TLS Client 182 function which is responsible for: 184 a. Communicate with EAP-TLS Server b. Request encryption and 185 decryption relevant messages from IML. 187 The communication mechanism between IML and EML should follow the 188 specific trust computing architecture like Intel Enclave and 189 TrustZone which is out of this document's scope. 191 3.1. Middle Layer Message 193 The message transmitted between IML and EML will follow the format of 194 TLS1.3, but not all TLS1.3 [RFC8446]message will be transmitted. The 195 IML only accept message relevant to encryption and decryption. The 196 structure of Middle Layer Message is shown below. 198 enum{ 199 Random; 200 keyshareExtension; 201 PreSharedKeyExchange 202 CertificateList 203 CertificateVerify 204 Finished 205 NewSessionTicket 206 ApplicationData 207 Alert 208 }ParameterType 210 Struct{ 211 bool request//true:request; false response. If it's request message, then the payload of message should be set as zero. 212 ParameterType type 213 uint24 length 214 select(type){ 215 case Random randomValue 216 case KeyshareExtension keyshareextensionValue 217 case PreSharedKeyExchange value; 218 case CertificateList 219 case CertificateVerify 220 case Finished 221 case NewSessionTicket 222 case ApplicationData 223 case Alert 224 } 225 }MiddleLayerMessage 227 3.2. information pre-stored in TEE 229 (1) Certificate that complies with X509.3. If using EAP-TLS as the 230 authentication protocol, then the ID of the TEE enabled device is the 231 certificate complies X509.3. In this document, the certificate of 232 this device is the only item that needs to be stored in TEE before 233 the process of EAP-TLS starts. And regarding to how to get this 234 certificate or update this certificate is out of scope. The 235 certificate will never be allowed to be exposed outside the TEE in 236 plaintext. 238 3.3. key derivation process in TEE 240 Key derivation process MUST be executed in TEE. 242 3.4. Mutual Authentication Procedure 244 Figure 2 illustrates the steps of TEE identification based on EAP- 245 TLS. From the view of EAP-TLS Server there are no changes of the 246 procedure. All the changes are in the EAP-TLS Peer side. This 247 document defines 6 middle layer messages from message 1 to message 6 248 which will be used for different purpose to communicate between IML 249 and EML. The specific steps are shown in bullets below. 251 EAP-TLS Peer 252 +--------------------+ 253 +-----+ +-----+ +-------+ 254 | TEE | | REE | |EAP|TLS| 255 +--+--+ +--+--+ |server | 256 | | +-------+ 257 | | | EAP-Request/ 258 | <-----------------------+ Identity 259 | EAP-Response/ | 260 | Identity(privacy-friendly) | 261 | Recommend random hex +-------> 262 | | | 263 | | EAP-Request/ 264 | <----------------+ EAP-Type=EAP-TLS 265 | | (TLS Start) 266 | Middle layer | 267 <----------------+ Message 1 | 268 | | | 269 Middle layer | | 270 Message 2 +--------------> | 271 | | | 272 | EAP-Response/ | 273 | EAP-Type=EAP-TLS+-----------> 274 | (TLS ClientHello) | 275 | | EAP-Request/ 276 | | EAP-Type=EAP-TLS 277 | | (TLS ServerHello, 278 | <----------------+ TLS EncryptedExtensions, 279 | | TLS CertificateRequest, 280 | | TLS Certificate, 281 | | TLS CertificateVerify, 282 | | TLS Finished) 283 | Middle Layer | 284 <---------------+Message 3 | 285 | | | 287 Middle Layer | | 288 Message 4 +----------------> | 289 | | | 290 | EAP-Response/ | 291 | EAP-Type=EAP-TLS | 292 | (TLS Certificate, | 293 | TLS CertificateVerify, | 294 | TLS Finished) +------------> 295 | | | 296 | | EAP-Request/ 297 | | EAP-Type=EAP-TLS 298 | | (TLS Application 299 | <---------------+ Data 0x00) 300 | | | 301 | Middle Layer | 302 <--------------+ Message 5 | 303 | | | 304 Middle Layer | | 305 Message 6 +---------------> | 306 | | | 307 | EAP-Response/ | 308 | EAP-Type=EAP-TLS+-------------> 309 | | | 310 | <------------------+EAP-Success 311 | | | 312 | | | 314 Figure 2: Mutual TEE Identification based on EAP-TLS 316 In order to complete ClientHello Message, the Key_Share Extension 317 message is needed. This message involves the key derivation function 318 which Must be executed in TEE. So the Middle Layer Message 1 is 319 KeyShareExtension request from EML to IML. 321 Middle Layer Message 2 from IML responses to message1 and returns the 322 KeyShareExtension response to EML. 324 Middle Layer Message 3 includes plaintext ServerHello message and 325 encrypted Server Params and Auth. Since EML does not carry the 326 relevant private key which is derived from KeyShareExtension, it will 327 transfer this message to IML to decode. Message 3 also includes the 328 entire handshake context which will be used to create 329 CertificateVerify and Finished context. 331 In Message 4, IML retains the KeyShareExtension, and other message 332 context will be transferred to EML as plaintext. Message 4 also 333 contains context the HMAC of (finished_key, Transcript-Hash(Handshake 334 Context, Certificate, CertificateVerify)), which can only be 335 generated by IML. 337 Message 5 is the encrypted application data 0x00, which will be sent 338 to IML to decode. 340 After decrypted the message 5, the plaintext will be packed in 341 message 6 and sent to EML. Then EML will make the determination if 342 the authentication procedure is finished. 344 3.5. Ticket Establishment 346 If the NewSessionTicket context is sent by EAP-TLS Server, it will be 347 packed in the middle of Server's TLS Finished message and TLS 348 Application Data 0x00 message. This context will be included in 349 message 5 by EML and conveyed to IML. After received message 5, IML 350 will decrypt and retain this ticket establishment context for 351 resumption. 353 3.6. Resumption 355 After the Client has received a NewSessionTicket message from the 356 EAP-TLS Server, the Client can use PSK mode to connect with EAP-TLS 357 Server. This action happens in TLS ClientHello message, in which the 358 Pre-shared-key extension will be used. Need to notice that the 359 action of resumption is deployed by EAP-TLS Client. EAP-TLS Client 360 determines if it will use NewSessionTicket to rebuild connection with 361 EAP-TLS Server. If do so, the message 1 will include the type of 362 NewSeesionTIcket request to IML. After received this request 363 message, IML will generate the Pre-shared key extension in Message2 364 for EMLREE to generate ClientHello Message. 366 3.7. Termination 368 TLS Error Alert could be sent both by EAP-TLS Server and Client. If 369 sent by Server, the message will be transferred to IML by EML to 370 decrypt. And the IML will notify EML in message 4 or 6. If the TLS 371 Error Alert message is sent by IML, it will be generate in message4, 372 which will be directly transferred to EML. 374 3.8. Hello Retry Request 376 This message happens after the EAP-TLS Server received ClientHello. 377 Since the negotiation is not successful, the Hello Retry Request 378 message will be sent in plaintext to EAP-TLS Client. 380 4. Security Considerations 382 This document used the concept of TEE, which can be considered as a 383 trusted anchor in device that cannot be tampered. But the REE of a 384 device cannot be fully trusted or it may be tampered by attackers. 385 The middle layer has two parts: the inner middle layer and the 386 external middle layer. Even though the message conveyed between IML 387 and EML is already encrypted, TEE cannot guarantee the integrity 388 message from EML and trust the behavior of EAP-TLS Client. As a 389 result this architecture can make sure that crucial information like 390 certificate or identity cannot be obtained by illegal parties, but 391 cannot deny DOS attack. In fact unless there is a trust channel that 392 directly connects between TEE and EAP-TLS Server, otherwise the DOS 393 attack cannot be prevented. For example, in the SUCI-SUPI 394 architecture in 5G system the ME is in charge of establishing 395 communications between USIM and AMF. If an attacker invaded into the 396 ME and tampered the SUCI message, a DOS attack will be implemented. 398 The other aspects of the security considerations will follow TLS1.3, 399 EAP-TLS, and RATs draft--ietf-rats-architecture. 401 5. IANA Considerations 403 TBD 405 6. Acknowledgement 407 TBD 409 7. Normative References 411 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 412 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 413 March 2008, . 415 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 416 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 417 . 419 Authors' Addresses 420 Penglin Yang 421 China Mobile 422 32, Xuanwumen West 423 BeiJing, BeiJing 100053 424 China 426 Email: 427 yangpenglin@chinamobile.com 429 Meiling Chen 430 China Mobile 431 32, Xuanwumen West 432 BeiJing, BeiJing 100053 433 China 435 Email: 436 chenmeiling@chinamobile.com 438 Li Su 439 China Mobile 441 32, Xuanwumen West 443 BeiJing 445 100053 447 China 449 Email: 450 suli@chinamobile.com