idnits 2.17.1 draft-chen-rats-tee-identification-02.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 241: '...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 (August 06, 2021) is 993 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: February 7, 2022 China Mobile 6 August 06, 2021 8 Use TEE Identification in EAP-TLS 9 draft-chen-rats-tee-identification-02 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 uses TEE and EAP-TLS 17 to create a secure and trusted procedure to authenticate a device's 18 identity. In this architecture, certificate protection and handshake 19 keys generation which are used for EAP-TLS authentication will be 20 executed in TEE. Communication establishment with EAP-TLS Server 21 will be executed in REE. A middle layer is introduced to communicate 22 between TEE and REE to compose the original function of EAP-TLS 23 Client. 25 TEE identification based on EAP-TLS could be used in different 26 network layers to implement identity authentication. 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 February 7, 2022. 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 . . . . . . . . . . . . . . . . . . 5 66 3.2. information pre-stored in TEE . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 8 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 In security considerations, identity of a device should be protected 82 and cannot be exposed in public in plaintext. The storage and 83 execution of identity in device also need to be protected during the 84 lifecycle. Even though the authentication protocol like EAP-TLS, 85 802.1X can guarantee the procedure of communication is security but 86 they are all built by the assumption that the device and the 87 implementation of procedure is trusted. In fact, security is the 88 result of multi-layer composition which could affect the security 89 both in protocol level and equipment level. Based on these 90 considerations, there is still no a unified and trusted mechanism 91 that can authenticate a remote device's identity in a trusted way in 92 Internet. So this document tries to use TEE and EAP-TLS to create a 93 secure and trusted procedure to authenticate a device's identity. 95 In this document, TEE (Trusted Execution Environment) described in 96 draft-ietf-teep-architecture-14 will be involved. This environment 97 emphasizes that any code within that environment cannot be tampered 98 with, and that any data used by such code cannot be read or tampered 99 with by any code outside that environment. On the contrary, REE 100 (Rich Execution Environment) is an environment that code and data in 101 that environment may be tampered with. Need to mention that in 102 device TEE is scarce resource which can only involve security 103 critical processes. 105 EAP-TLS1.3 protocol, defined in RFC RFC 8446[RFC8446] which is 106 recommended by IETF because of its swift and security features. This 107 protocol is treated as a security method that can provide client- 108 server mutual authentication. In this protocol there is an 109 assumption that both client and server are trusted or uncompromised 110 by any attacker. Usually the server of authentication is highly 111 protected and surveilled by operators, this means that the server 112 could be treated as a trust party. But client especially IoT device 113 is more likely to be vulnerable due to the lack of sufficient 114 security mechanisms. 116 The primary goal of this document is to provide a remote identity 117 authentication method which uses EAP-TLS as the essential 118 authentication protocol and TEE as the security shelter to store and 119 execute the certificate and private key derivations. The specific 120 method is to add a middle layer in REE and TEE to exchange data in 121 the form of EAP-TLS. In application scenarios, this method could be 122 used in transport layer authentication, application layer 123 authentication and other scenarios. 125 2. Terminology 127 The readers should be familiar with the terms defined in. 129 In addition, this document makes use of the following terms: 131 TEE: Trust Execution Environment. 133 REE: Rich Execution Environment. 135 ML: Middle Layer. 137 IML: Inner Middle Layer. 139 EML: External Middle Layer. 141 peer: The entity that responds to the authenticator. 143 backend authenticator server: A backend authentication server is an 144 entity that provides an authentication service to an 145 authenticator. When used, this server typically executes EAP 146 methods for the authenticator. 148 EAP server: The entity that terminates the EAP authentication method 149 with the peer. In the case where no backend authentication server 150 is used, the EAP server is part of the authenticator. In the case 151 where the authenticator operates in pass-through mode, the EAP 152 server is located on the backend authentication server. 154 3. Architecture Overview 156 This architecture brings in a Middle Layer which is implemented in 157 TEE and REE to translate information between TEE and REE. The 158 structure of this Middle Layer is shown below. 160 +------------------------------------------------------+ 161 | +----------------------------+ REE | 162 | | TEE | | 163 | | +---------------+ +------+ | +-------------------+ | +-------+ 164 | | | certificates| | | | |---------+ | | | | 165 | | +---------------+ | inner| | || | | | | | 166 | | +---------------+ |middle<---->external| EAP-TLS| | |EAP-TLS| 167 | | | key | | layer| | ||middle | Client <-----> server| 168 | | | derivation | | | | ||layer | | | | | 169 | | +---------------+ +------+ | |---------+ | | | | 170 | +----------------------------+ |-------------------+ | +-------+ 171 +------------------------------------------------------+ 173 Figure 1: architecture of middle layer 175 In figure 1, the middle layer is separated in two parts: Inner Middle 176 Layer (IML) and External Middle Layer (EML). The IML is responsible 177 for 179 a. Key derivation b. Response to EML about EAP-TLS encryption and 180 decryption relevant message. 182 In this document, the EML could be set as a part of EAP-TLS Client 183 function which is responsible for: 185 a. Communicate with EAP-TLS Server b. Request encryption and 186 decryption relevant messages from IML. 188 The communication mechanism between IML and EML should follow the 189 specific trust computing architecture like Intel Enclave and 190 TrustZone which is out of this document's scope. 192 3.1. Middle Layer Message 194 The message transmitted between IML and EML will follow the format of 195 TLS1.3, but not all TLS1.3 [RFC8446]message will be transmitted. The 196 IML only accept message relevant to encryption and decryption. The 197 structure of Middle Layer Message is shown below. 199 enum{ 200 Random; 201 keyshareExtension; 202 PreSharedKeyExchange 203 CertificateList 204 CertificateVerify 205 Finished 206 NewSessionTicket 207 ApplicationData 208 Alert 209 }ParameterType 211 Struct{ 212 bool request//true:request; false response. If it's request message, then the payload of message should be set as zero. 213 ParameterType type 214 uint24 length 215 select(type){ 216 case Random randomValue 217 case KeyshareExtension keyshareextensionValue 218 case PreSharedKeyExchange value; 219 case CertificateList 220 case CertificateVerify 221 case Finished 222 case NewSessionTicket 223 case ApplicationData 224 case Alert 225 } 226 }MiddleLayerMessage 228 3.2. information pre-stored in TEE 230 (1) Certificate that complies with X509.3. If using EAP-TLS as the 231 authentication protocol, then the ID of the TEE enabled device is the 232 certificate complies with X509.3. In this document, the certificate 233 of this device is the only item that needs to be stored in TEE before 234 the process of EAP-TLS starts. And regarding to how to get this 235 certificate or update this certificate is out of scope. The 236 certificate will never be allowed to be exposed outside the TEE in 237 plaintext. 239 3.3. key derivation process in TEE 241 Key derivation process MUST be executed in TEE. 243 3.4. Mutual Authentication Procedure 245 Figure 2 illustrates the steps of TEE identification based on EAP- 246 TLS. From the view of EAP-TLS Server there are no changes of the 247 procedure. All the changes are in the EAP-TLS Peer side. This 248 document defines 6 middle layer messages from message 1 to message 6 249 which will be used for different purpose to communicate between IML 250 and EML. The specific steps are shown in bullets below. 252 EAP-TLS Peer 253 +--------------------+ 254 +-----+ +-----+ +-------+ 255 | TEE | | REE | |EAP|TLS| 256 +--+--+ +--+--+ |server | 257 | | +-------+ 258 | | | EAP-Request/ 259 | <-----------------------+ Identity 260 | EAP-Response/ | 261 | Identity(privacy-friendly) | 262 | Recommend random hex +-------> 263 | | | 264 | | EAP-Request/ 265 | <----------------+ EAP-Type=EAP-TLS 266 | | (TLS Start) 267 | Middle layer | 268 <----------------+ Message 1 | 269 | | | 270 Middle layer | | 271 Message 2 +--------------> | 272 | | | 273 | EAP-Response/ | 274 | EAP-Type=EAP-TLS+-----------> 275 | (TLS ClientHello) | 276 | | EAP-Request/ 277 | | EAP-Type=EAP-TLS 278 | | (TLS ServerHello, 279 | <----------------+ TLS EncryptedExtensions, 280 | | TLS CertificateRequest, 281 | | TLS Certificate, 282 | | TLS CertificateVerify, 283 | | TLS Finished) 284 | Middle Layer | 285 <---------------+Message 3 | 286 | | | 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, encrypted TLS Client Certificate, TLS CertificateVerify 332 and TLS Finished message will be included. 334 Message 5 is the encrypted application data 0x00, which will be sent 335 to IML to decode. 337 After decrypted the message 5, the plaintext will be packed in 338 message 6 and sent to EML. Then EML will make the determination if 339 the authentication procedure is finished. 341 3.5. Ticket Establishment 343 If the NewSessionTicket context is sent by EAP-TLS Server, it will be 344 packed in the middle of Server's TLS Finished message and TLS 345 Application Data 0x00 message. This context will be included in 346 message 5 by EML and conveyed to IML. After received message 5, IML 347 will decrypt and retain this ticket establishment context for 348 resumption. 350 3.6. Resumption 352 After the Client has received a NewSessionTicket message from the 353 EAP-TLS Server, the Client can use PSK mode to connect with EAP-TLS 354 Server. This action happens in TLS ClientHello message, in which the 355 Pre-shared-key extension will be used. Need to notice that the 356 action of resumption is deployed by EAP-TLS Client. EAP-TLS Client 357 determines if it will use NewSessionTicket to rebuild connection with 358 EAP-TLS Server. If do so, the message 1 will include the type of 359 NewSeesionTIcket request to IML. After received this request 360 message, IML will generate the Pre-shared key extension in Message2 361 for EMLREE to generate ClientHello Message. 363 3.7. Termination 365 TLS Error Alert could be sent both by EAP-TLS Server and Client. If 366 sent by Server, the message will be transferred to IML by EML to 367 decrypt. And the IML will notify EML in message 4 or 6. If the TLS 368 Error Alert message is sent by IML, it will be generate in message4, 369 which will be directly transferred to EML. 371 3.8. Hello Retry Request 373 This message happens after the EAP-TLS Server received ClientHello. 374 Since the negotiation is not successful, the Hello Retry Request 375 message will be sent in plaintext to EAP-TLS Client. 377 4. Security Considerations 379 This document used the concept of TEE, which can be considered as a 380 trusted anchor in device that cannot be tampered. But the REE of a 381 device cannot be fully trusted or it may be tampered by attackers. 382 The middle layer has two parts: the inner middle layer and the 383 external middle layer. Even though the message conveyed between IML 384 and EML is already encrypted, TEE cannot guarantee the integrity of 385 the message that comes from EML and trust the behavior of EAP-TLS 386 Client. As a result this architecture can make sure that crucial 387 information like certificate or identity cannot be obtained by 388 illegal parties, but cannot deny DOS attack. In fact unless there is 389 a trust channel that directly connects between TEE and EAP-TLS 390 Server, otherwise the DOS attack cannot be prevented. For example, 391 in the SUCI-SUPI architecture in 5G system the ME is in charge of 392 establishing communications between USIM and AMF. If an attacker 393 invaded into the ME and tampered the SUCI message, a DOS attack will 394 be implemented. 396 The other aspects of the security considerations will follow TLS1.3, 397 EAP-TLS, and RATs draft--ietf-rats-architecture. 399 5. IANA Considerations 401 TBD 403 6. Acknowledgement 405 TBD 407 7. Normative References 409 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 410 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 411 . 413 Authors' Addresses 415 Penglin Yang 416 China Mobile 417 32, Xuanwumen West 418 BeiJing, BeiJing 100053 419 China 421 Email: yangpenglin@chinamobile.com 422 Meiling Chen 423 China Mobile 424 32, Xuanwumen West 425 BeiJing, BeiJing 100053 426 China 428 Email: chenmeiling@chinamobile.com 430 Li Su 431 China Mobile 432 32, Xuanwumen West 433 BeiJing 100053 434 China 436 Email: suli@chinamobile.com