[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02 03                                                   
EMU                                                              P. Yang
Internet-Draft                                                   M. Chen
Intended status: Standards Track                                  Li. Su
Expires: November 29, 2021                                  China Mobile
                                                            May 28, 2021


                   Use TEE Identification in EAP-TLS
                 draft-chen-rats-tee-identification-00

Abstract

   In security considerations, identity of a device should be protected
   and cannot be exposed in public.  Based on this purpose, this
   document specifies the architecture of TEE(Trust Execution
   Environment) identification based on EAP-TLS.  In this architecture,
   TEE is in charge of protecting the certificate and generating
   handshake keys which will be used for EAP-TLS authentication.
   REE(Rich Execution Environment) is in charge of building
   communication with EAP-TLS Server.  A middle layer is introduced to
   communicate with separate parts of EAP-TLS in TEE and REE to
   implement its original functionality.

   This architecture could be used in data link layer and also
   application layer to implement identity authentication under the
   protection of TEE and EAP-TLS.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 29, 2021.








Yang, et al.            Expires November 29, 2021               [Page 1]


Internet-Draft            EAP TLS TEE identity                  May 2021


Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Middle Layer Message  . . . . . . . . . . . . . . . . . .   4
     3.2.  information pre-stored inTEE  . . . . . . . . . . . . . .   5
     3.3.  key derivation process in TEE . . . . . . . . . . . . . .   6
     3.4.  Mutual Authentication Procedure . . . . . . . . . . . . .   6
     3.5.  Ticket Establishment  . . . . . . . . . . . . . . . . . .   8
     3.6.  Resumption  . . . . . . . . . . . . . . . . . . . . . . .   8
     3.7.  Termination . . . . . . . . . . . . . . . . . . . . . . .   8
     3.8.  Hello Retry Request . . . . . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Identity of a device in security region is always important.
   However, there is still no a unified and secure mechanism that can
   attest a remote device's identity.  Another issue is how to store and
   protect this attest process is still undetermined.  This document
   tries to use TEE and EAP-TLS to create a secure procedure to attest a
   device's identity.

   In this document, TEE (Trusted Execution Environment) described in
   draft-ietf-teep-architecture-14 will be involved.  This environment
   emphasizes that any code within that environment cannot be tampered
   with, and that any data used by such code cannot be read or tampered
   with by any code outside that environment.  On the contrary, REE



Yang, et al.            Expires November 29, 2021               [Page 2]


Internet-Draft            EAP TLS TEE identity                  May 2021


   (Rich Execution Environment) is an environment that code and data in
   that environment may be tampered with.  TEE is a scarce resource in
   devices, not every step or relative processes can be included in TEE.

   EAP-TLS1.3 protocol, defined in RFC 5216[RFC5216], which is
   recommended by IETF because of its swift and security features is
   treated as a security method that can provide client-server mutual
   authentication.  This method is based on the assumption that both
   client and server are trusted or uncompromised by any attacker.
   Usually, the server of authentication is highly protected and
   surveilled by operators, which could be considered as a trust party.
   But client, especially IoT device, is more likely to be vulnerable
   due to the lack of sufficient security mechanisms.

   The primary goal of this document provides a remote identity
   attestation method which uses EAP-TLS as the essential authentication
   protocol and TEE as the security shelter to store and execute the
   certificate and private key derivations.  The specific method is to
   add a middle layer in REE to exchange data in the form of EAP-TLS
   between EAP-TLS server and TEE/REE.  In application scenarios, this
   method could be used in transport layer authentication, application
   layer authentication and other scenarios.

2.  Terminology

   The readers should be familiar with the terms defined in.

   In addition, this document makes use of the following terms:

   TEE:  Trust Execution Environment.

   REE:  Rich Execution Environment.

   IML:  Inner Middle Layer.

   EML:  External Middle Layer.

   peer:  The entity that responds to the authenticator.

   backend authenticator server:  A backend authentication server is an
      entity that provides an authentication service to an
      authenticator.  When used, this server typically executes EAP
      methods for the authenticator.

   EAP server:  The entity that terminates the EAP authentication method
      with the peer.  In the case where no backend authentication server
      is used, the EAP server is part of the authenticator.  In the case




Yang, et al.            Expires November 29, 2021               [Page 3]


Internet-Draft            EAP TLS TEE identity                  May 2021


      where the authenticator operates in pass-through mode, the EAP
      server is located on the backend authentication server.

3.  Architecture Overview

   This architecture will bring in a Middle Layer which is implemented
   in TEE and REE to translate information between TEE and EAP-TLS
   Client.  The structure of this Middle Layer is shown below.

   In figure one, the middle layer is separated in two parts: inner
   middle layer (IML) and external middle layer (EML).  The IML is
   responsible for:

   +------------------------------------------------------+
   | +----------------------------+                 REE   |
   | |    TEE                     |                       |
   | | +---------------+ +------+ | +-------------------+ |   +-------+
   | | |   certificates| |      | | |---------+         | |   |       |
   | | +---------------+ | inner| | ||        |         | |   |       |
   | | +---------------+ |middle<---->external|  EAP-TLS| |   |EAP-TLS|
   | | |    key        | | layer| | ||middle  |  Client <-----> server|
   | | |    derivation | |      | | ||layer   |         | |   |       |
   | | +---------------+ +------+ | |---------+         | |   |       |
   | +----------------------------+ |-------------------+ |   +-------+
   +------------------------------------------------------+

         Figure 1: architecture of middle layer

   a.  Key derivation b.  Response to EML when relevant to encryption
   and decryption.

   In this document, the EML could be set as a part of EAP-TLS Client
   function which is responsible for:

   a.  Communicate with EAP-TLS Server b.  Request encryption and
   decryption relevant messages from IML.

   The communication mechanism between IML and EML should follow the
   specific trust computing architecture like Intel Enclave or TCG TSS
   which is out of this document's scope.

3.1.  Middle Layer Message

   The message transmitted between IML and EML will follow the format of
   TLS1.3[RFC8446], but not all TLS1.3 message will be transmitted.  The
   IML only accept message related to encryption and decryption.  The
   structure of Middle Layer Message is shown below.




Yang, et al.            Expires November 29, 2021               [Page 4]


Internet-Draft            EAP TLS TEE identity                  May 2021


                   enum{
       Random;
       keyshareExtension;
       PreSharedKeyExchange
       CertificateList
       CertificateVerify
       Finished
       NewSessionTicket
       ApplicationData
       Alert
   }ParameterType


                   Struct{
     bool request// true:request; false response
       ParameterType type
       uint24 length
       select(type){
         case Random randomValue
         case KeyshareExtension keyshareextensionValue
         case PreSharedKeyExchange value;
         case CertificateList
         case CertificateVerify
         case Finished
         case NewSessionTicket
         case ApplicationData
         case Alert
   }
   }MiddleLayerMessage

3.2.  information pre-stored inTEE

   (1) Certificate that complies with X509.3.  In general, the ID of the
   TEE enabled device is the certificate.  In specific, the ID of the
   device is "subject name" and "subjectUniqueID".  In this
   architecture, the certificate of this device is the only item that
   needs to be stored in TEE before the process of EAP-TLS starts.  And
   regarding to how to get this certificate or update this certificate
   is out of scope.  The EAP-TLS will never allowed to afford outside
   the TEE in plain text.

   (2) Handshake Context during EAP-TLS procedure.  During the EAP-TLS
   procedure TEE need to store the handshake context which is generated
   by REE.  This is because EAP-TLS procedure needs handshake context
   and certain private key to generate CertificateVerify and Finished
   information.





Yang, et al.            Expires November 29, 2021               [Page 5]


Internet-Draft            EAP TLS TEE identity                  May 2021


3.3.  key derivation process in TEE

   Key derivation process MUST be executed in TEE.

3.4.  Mutual Authentication Procedure

   In figure 2, there are two steps that need the TEE to be invoked.
   The first is TLS-ClientHello Parameter Response which will provide
   parameters of key_share, signature_algorithm, psk_key_exchange_modes,
   and pre_shared_key.  These parameters will be sent to REE, and REE
   will use process of TLS-ClientHello to send these messages to EAP-TLS
   Server.  The second step is TLS-Finished Parameter Response which
   will provide parameters of TLS Certificate, TLS CertificateVerify,
   and TLS Finished(not confirmed yet).  The specific description of
   these two steps will be discussed in section 2.2 and 2.3.

   Divisions of Responsibility: TEE is in charge of the cipher security,
   REE is in charge of the conversation integrity.  And there may have
   some tamper-like dos attacks, but there have no phony attack and leak
   of keys.

             EAP-TLS Peer
        +--------------------+
    +-----+               +-----+                +-------+
    | TEE |               | REE |                |EAP|TLS|
    +--+--+               +--+--+                |server |
       |                     |                   +-------+
       |                     |                       | EAP-Request/
       |                     <-----------------------+  Identity
       |                  EAP-Response/              |
       |            Identity(privacy-friendly)       |
       |               Recommend random hex  +------->
       |                     |                       |
       |                     |                  EAP-Request/
       |                     <----------------+ EAP-Type=EAP-TLS
       |                     |                  (TLS Start)
       |                  Middle layer               |
       <----------------+ Message 1                  |
       |                     |                       |
    Middle layer             |                       |
    Message 2 +-------------->                       |
       |                     |                       |
       |                 EAP-Response/               |
       |                 EAP-Type=EAP-TLS+----------->
       |                 (TLS ClientHello)           |
       |                     |                  EAP-Request/
       |                     |                  EAP-Type=EAP-TLS
       |                     |                  (TLS ServerHello,



Yang, et al.            Expires November 29, 2021               [Page 6]


Internet-Draft            EAP TLS TEE identity                  May 2021


       |                     <----------------+ TLS EncryptedExtensions,
       |                     |                  TLS CertificateRequest,
       |                     |                  TLS Certificate,
       |                     |                  TLS CertificateVerify,
       |                     |                  TLS Finished)
       |                Middle Layer                 |
       <---------------+Message 3                    |
       |                     |                       |
 Middle Layer                |                       |
 Message 4  +---------------->                       |
       |                     |                       |
       |               EAP-Response/                 |
       |               EAP-Type=EAP-TLS              |
       |               (TLS Certificate,             |
       |               TLS CertificateVerify,        |
       |               TLS Finished)    +------------>
       |                     |                       |
       |                     |                 EAP-Request/
       |                     |                 EAP-Type=EAP-TLS
       |                     |                 (TLS Application
       |                     <---------------+ Data 0x00)
       |                     |                       |
       |                 Middle Layer                |
       <--------------+  Message 5                   |
       |                     |                       |
   Middle Layer              |                       |
   Message 6 +--------------->                       |
       |                     |                       |
       |               EAP-Response/                 |
       |               EAP-Type=EAP-TLS+------------->
       |                     |                       |
       |                     <------------------+EAP-Success
       |                     |                       |
       |                     |                       |

     Figure 2: Mutual TEE Identification based on EAP-TLS


   In order to complete ClientHello Message, the Key_Share Extension
   message is needed.  This message involves the key derivation function
   which Must be executed in TEE.  So the Middle Layer Message 1 is
   KeyShareExtension requirement.

   Middle Layer Message 2 responses to message1 and returns the
   KeyShareExtension to REE.

   Middle Layer Message 3 includes plaintext ServerHello message and
   encrypted Server Params and Auth.  Since REE does not carry the



Yang, et al.            Expires November 29, 2021               [Page 7]


Internet-Draft            EAP TLS TEE identity                  May 2021


   relevant private key, it will transfer this message to TEE to decode.
   Message 3 also include all the context handshake in this session, in
   which will be used to create CertificateVerify and Finished context.

   In Message 4, TEE retains the key_share extension, and other message
   context will be transferred to REE as plaintext.  Message 4 also
   contains context the HMAC of (finished_key, Transcript-Hash(Handshake
   Context, Certificate, CertificateVerify)), which can only be
   generated in TEE.

   Message 5 is the encrypted application data 0x00, which will be sent
   to TEE to indicate the authentication procedure is finished.

   After decrypted the message 5, the plaintext will be packed in
   message 6 and sent to REE.  Then REE will make the determination if
   the authentication procedure is finished

3.5.  Ticket Establishment

   If the ticket establishment context is sent by EAP-TLS Server, it
   will be packed in the middle of Server's TLS Finished message and TLS
   Application Data 0x00 message.  This context will be included in
   message 5 by REE and conveyed to TEE.  After received message 5, TEE
   will decrypt and retain this ticket establishment context for
   resumption.

3.6.  Resumption

   After the Client has received a NewSessionTicket message from the
   EAP-TLS Server, the Client can use PSK mode to connect with EAP-TLS
   Server.  This action happens in TLS ClientHello message, in which the
   Pre-shared-key extension will be used.  Need to notice that the
   action of resumption is deployed by REE.  REE determines if it will
   use NewSessionTicket to rebuild connection with EAP-TLS Server.  If
   do so, the message 1 will include the type of NewSeesionTIcket to
   TEE.  After received this message, TEE will generate the Pre-shared
   key extension in Message2 for REE to generate ClientHello Message.

3.7.  Termination

   TLS Error Alert could be sent both by EAP-TLS Server and Client.  If
   sent by Server, the message will be transferred to TEE to decrypt.
   And the TEE will notify REE in message 4 or 6.  If the TLS Error
   Alert message is sent by TEE, it will be generate in message4, which
   will be directly transferred to REE.






Yang, et al.            Expires November 29, 2021               [Page 8]


Internet-Draft            EAP TLS TEE identity                  May 2021


3.8.  Hello Retry Request

   This message happens after the EAP-TLS Server received ClientHello.
   Since the negotiation is not successful, the Hello Retry Request
   message will be sent in plaintext.

4.  Security Considerations

   This document used the concept of TEE, which can be considered as a
   trusted anchor in device that cannot be tampered.  But the REE of a
   device cannot be fully trusted or it may be tampered by attackers.
   The middle layer has two parts: the inner middle layer and the
   external middle layer.  Even though the message from inner middle
   layer and external middle layer is already encrypted, TEE cannot
   guarantee the integrity of these messages and the behavior of EAP-TLS
   Client.  So this architecture can make sure that crucial information
   like certificate or identity cannot be obtained by illegal party, but
   cannot deny DOS attack.  In fact unless there is trust channel that
   directly connect between TEE and EAP-TLS Server, otherwise the DOS
   attack cannot be prevented.  For example, in the SUCI-SUPI
   architecture in 5G system the ME is in charge of establishing
   communications between USIM and NG RAN.  If an attacker invaded into
   the ME and tampered the SUCI message, a DOS attack will be
   implemented.

   The other aspects of the security considerations will follow TLS1.3,
   EAP-TLS, and RATs draft--ietf-rats-architecture.

5.  IANA Considerations

   TBD

6.  Acknowledgement

   TBD

7.  Normative References

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <https://www.rfc-editor.org/info/rfc5216>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.






Yang, et al.            Expires November 29, 2021               [Page 9]


Internet-Draft            EAP TLS TEE identity                  May 2021


Authors' Addresses

   Penglin Yang
   China Mobile
   32, Xuanwumen West
   BeiJing, BeiJing  100053
   China

   Email:
            yangpenglin@chinamobile.com


   Meiling Chen
   China Mobile
   32, Xuanwumen West
   BeiJing, BeiJing  100053
   China

   Email:
            chenmeiling@chinamobile.com


   Li Su
   China Mobile

               32, Xuanwumen West


               BeiJing

               100053


               China


   Email:
             suli@chinamobile.com













Yang, et al.            Expires November 29, 2021              [Page 10]