[Docs] [txt|pdf] [Tracker] [Email] [Nits]



  TLS Working Group                                            P. Urien
  Internet Draft                                          Telecom Paris
  Intended status: Experimental

                                                      September 15 2020
  Expires: March 2020

                    Secure Element for TLS Version 1.3
                         draft-urien-tls-se-00.txt


Abstract

   This draft presents ISO7816 interface for TLS1.3 stack running in
   secure element. It presents supported cipher suites and key exchange
   modes, and describes embedded software architecture. TLS 1.3 is the
   de facto security stack for emerging Internet of Things (IoT)
   devices. Some of them are constraint nodes, with limited computing
   resources. Furthermore cheap System on Chip (SoC) components don't
   usually provide tamper resistant features, so private or pre shared
   keys are exposed to hacking. According to the technology state of
   art, some ISO7816 secure elements are able to process TLS 1.3, but
   with a limited set of cipher suites. There are two benefits for TLS-
   SE; first fully tamper resistant processing of TLS protocol, which
   increases the security level insurance; second embedded software
   component ready for use, which relieves the software of the burden
   of cryptographic libraries and associated attacks.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

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 http://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 March 2021.
   .


   Urien                     Expires March 2021            [Page 1]


Copyright Notice

   Copyright (c) 2020 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
   (http://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.







































   Urien                       Expires March 2021            [page 2]


               Secure Element for TLS Version 1.3      September 2020

Table of Contents
   Abstract........................................................... 1
   Requirements Language.............................................. 1
   Status of this Memo................................................ 1
   Copyright Notice................................................... 2
   1 Overview......................................................... 4
   2 About Secure Elements............................................ 4
   3 Software components for TLS-SE................................... 5
      3.1 Cryptographic resources..................................... 5
      3.2 Data exchange............................................... 6
          3.2.1 Receiving Record Packet .............................. 6
          3.2.2 Sending Record Packet ................................ 7
          3.2.4 RECV and SEND procedure for open application AEAD .... 8
      3.3 TLS state machine........................................... 9
      3.4 TLS library................................................ 10
   4 ISO7816 interface............................................... 11
   5 ISO 7816 Use Case............................................... 12
   5 IANA Considerations............................................. 14
   6 Security Considerations......................................... 14
   7 References...................................................... 14
      7.1 Normative References....................................... 14
      7.2 Informative References..................................... 14
   8 Authors' Addresses.............................................. 14





























   Urien                     Expires March 2021             [Page 3]


               Secure Element for TLS Version 1.3      September 2020

1 Overview

   This draft presents ISO7816 interface for TLS1.3 stack running in
   secure element, it presents supported cipher suites and key exchange
   modes, and describes embedded software architecture. TLS 1.3
   [RFC8446] is the de facto security stack for emerging Internet of
   Things (IoT) devices. Some of them are constraint nodes, with
   limited computing resources. Furthermore cheap System on Chip (SOC)
   components don't usually provide tamper resistant features, so
   private or pre shared keys are exposed to hacking. The identity
   module (im) detailed in [IM] protects identity credentials. The TLS
   identity module [IM] MAY be based on secure element [ISO7816].
   According to the technology state of art, some secure elements are
   able to process TLS 1.3, but with a limited set of cipher suites.
   There are two benefits for TLS-SE; first fully tamper resistant
   processing of TLS protocol, which increases the security level
   insurance; second embedded software component ready for use, which
   relieves the software of the burden of cryptographic libraries and
   associated attacks.

           +-----------+ recv +------------+ RECV +-----------+
           |     IP    + ---> |   TCP/IP   | ---> |  TLS 1.3  |
           |  Network  +------+ Constraint +------+  Secure   |
           |           | <--- |    Node    | <--- |  Element  |
           +-----------+ send +------------+ SEND +-----------+
                          |                   |
                   Network Interface    ISO7816 interface

   Figure 1. TLS 1.3 Secure Element (TLS-SE)

2 About Secure Elements

   Secure elements are defined according to [ISO7816] standards. They
   support hash functions (sha256, sha384, sha512) and associated HMAC
   procedures. They also provide signatures and DH procedures in Z/pZ*
   groups, or elliptic curves (for example secp256r1). Open software
   can be released thanks to Javacard standards, such as JC3.04, or
   JC3.05. Most of secure elements use 8 bits Micro Controller Unit
   (MCU) and embedded cryptographic accelerator. Non volatile memory
   size is up to 100KB, and RAM size is up to 10KB.

   Below is an illustration of binary encoding rules for secure element
   according to the T=0 ISO7816 protocol.
   An ISO7816 request is a set of bytes comprising a five byte header
   and an optional payload (up to 255 bytes)
   The header comprises the following five bytes:
   - CLA, Class
   - INS, Instruction code
   - P1,  P1 byte
   - P2,  P2 byte
   - P3,  length of the optional payload, or number of expected bytes

   Urien                     Expires March 2021             [Page 4]


               Secure Element for TLS Version 1.3      September 2020


   The response comprises an optional payload (up to 256 bytes) and a
   two bytes status word (SW1, SW2), SW1=90, SW2=00 (SW=9000) meaning
   successful operation.

   The ISO7816 defines two main classes for data exchange (called
   transport protocol), T=0, and T=1.
   The T=0 transport protocol is a byte stream; a payload can be
   included in request or response, but not in both.
   The T=1 transport protocol is a frame stream; payload can be
   included both in request and response.

3 Software components for TLS-SE

                          +--------+
                          | Crypto +----------------+
      RECV +----------+   |   Lib  |                |
      ---> |   Data   |   +--------+     +----------+----------+
      <--- | Exchange |        +---------+       TLS Lib       |
      SEND +----+-----+        |         | Make  Record Packet |
                |        +-----+-----+   | Check Record Packet |
                |        | TLS State |   +---------------------+
                +--------+  Machine  |
                         +-----------+

   Figure 2. Software Components for TLS-SE

3.1 Cryptographic resources

   Many secure elements support hash functions sha256, sha384 and
   sha512 used by TLS1.3. Associated HMAC, HKDF-Extract and Derive-
   Secret, MUST be implemented by a dedicated cryptographic library.

   Many secure elements support the secp256r1 elliptic curve. Diffie-
   Hellman (DH )calculation are performed according to [IEEE1363] using
   the ECKAS-DH1 scheme with the identity map as the key derivation
   function, (KDF), so that the shared secret is the x-coordinate of
   the ECDH shared secret elliptic curve point represented as an octet
   string. ECDSA signature is also available for 256,384 and 512 hash
   size.

   AES-128 is usually implemented, by not AES-CCM. So this AEAD
   algorithm SHOULD be implemented by a dedicated cryptographic
   library.

   In summary, according to the state of art TLS-SE supports the
   secp256r1 ec group, associated ECDSA signature computing and
   checking, and ECDHE key establishment. It also implements the AES-
   128-CCM-SHA256 cipher suite.



   Urien                     Expires March 2021             [Page 5]


               Secure Element for TLS Version 1.3      September 2020

3.2 Data exchange

   TLS record layer packets are received and sent from/to TCP/IP
   networks thanks to well known socket procedures. The TLS-SE
   processes these packets according to a state machine.

  3.2.1 Receiving Record Packet

   Dedicated ISO7816 requests (named RECV) push incoming record
   messages in secure element. A fragmentation mechanism splits the
   record packet in one a several ISO7816 requests, whose payload size
   is less than 255 bytes. A 2 bits fragmentation-flag field indicates
   the fragment status; bit F-First notifies the first fragment, and
   bit F-Last notifies the last fragment.

   The ISO7816 RECV request COULD be encoded as
   CLA=00, INS=D8, P1=0, P2=fragmentation-flag, P3=fragment-length
   F-First=b01, F-Last=b10, F-More=b00

   When application AEAD is opened a two bits flag (F-Encrypt, F-
   Decrypt) indicates the cryptographic operation:
   - P2=b01= F-Decrypt, decryption
   - P2=b10= F-Encrypt, encryption

   If F-Last is not set, the ISO7816 response is always 9000 when no
   error occurs. For the last fragment five cases may occur:
   - sw-ok: no error, no record message returned, response = 9000.
   - sw-open, no error, no record message returned, TLS application
   AEAD is opened, for example response =9001.
   - sw-close: no error, , no record message returned, TLS application
   AEAD is closed, for example response =9002
   - sw-error: error, no record message returned.
   - sw-more(size): no error, a message or message fragment is ready.
   For example sw-more(size)= 61xy, in which xy is the size of the
   first fragment.

                 TCP/IP Node                   Secure Element
                     |                               |
                     |-RECV(F-First, Frag#1)-------->|
                     |<-------------------sw-ok 9000-|
                     |-RECV(F-More,  Frag#i)-------->|
                     |<------------------sw-ok= 9000-|
                     |-RECV(F-Last,  Frag#n)-------->|
                     |<------------------sw-ok= 9000-|
                     |<----------------sw-open= 9001-|
                     |<---------------sw-close= 9002-|
                     |<----------sw-more(size)= 61xy-|

   Figure 3. Receiving record packet, segmentation mechanism.



   Urien                     Expires March 2021             [Page 6]


               Secure Element for TLS Version 1.3      September 2020

  3.2.2 Sending Record Packet

   A sending procedure starts by the reception of a sw-more(size)
   status, ending a response. This event may occur at the end of RECV
   procedure (see figure 5) or after TLS state machine reset (see
   figure 4).

   A RECV(F-First, No-Frag) request resets the TLS state machine. For
   TLS client a sw-more(size) status is returned. For TLS server the
   sw-ok status is returned.

       TCP/IP Node                   Secure Element
           |                               |
           |-RECV(F-First, No-Frag)------->|=> Reset State Machine
           |<------------------sw-ok= 9000-| Server
           |<----------sw-more(size)= 61xy-| Client

   Figure 4. Starting the SEND procedure after RESET request.


       TCP/IP Node                   Secure Element
           |                               |
           |-RECV(F-Last, Last-Fragment)-->| => End of Message
           |<----------sw-more(size)= 61xy-| Client

   Figure 5. Starting SEND procedure after the end of RECV procedure.

   The SEND(size) reads a record fragment, whose length is equal to
   size. It MAY be necessary to adjust the SEND size (see figure 6).
   Typically at the end of RECV procedure, the size indicated by the
   sw-more(size) status is an expected fragment length. In that case
   the status sw-retry status (for example 6Cxy) indicates the fragment
   size.

       TCP/IP Node                   Secure Element
           |                               |
           |-RECV(F-Last, Last-Frag)------>| => End of Message
           |<----------sw-more(size)= 61xy-|
           | SEND(size)------------------->|
           | <------- sw-retry(size')=6Czt-|
           | SEND(size')------------------>|

   Figure 6. Adjusting SEND size.

   The SEND(size) request is encoded as :
   CLA=0, INS=C0, P1=0, P2=0, P3=size

   The SEND procedure (see Figure 7) is a set of SEND requests, which
   read record packet fragments.



   Urien                     Expires March 2021             [Page 7]


               Secure Element for TLS Version 1.3      September 2020


     TCP/IP Node                            Secure Element
       |                                          |
       |<--------------- ---sw-more(size#1)= 61xy-|
       |-SEND(size#1)---------------------------->|
       |<---------------Frag#1 || sw-more(size#2)-|
       |-SEND(size#i)---------------------------->|
       |<-----------Frag#i || sw-more(size#[i+1])-|
       |-SEND(size#n)---------------------------->|
       |<------------------------Frag#n || sw-ok)-|=> SEND End
       |<------------Frag#n || sw-more(next-size)-|=> SEND Continue
       |<----------------------Frag#n || sw-open)-|=> Open
       |<----------------------Frag#n || sw-close-|=> Close

   Figure 7. The SEND procedure

   At the end of SEND procedure four events MAY occur:
   - End of SEND procedure (status = sw-ok). No more record packets are
   available.
   - SEND procedure to be continued (status = sw-more(size)). Another
   record packet is available.
   - End of SEND procedure, application AEAD is ready for use (status =
   sw-open)
   - End of SEND procedure, application AEAD is closed (status = sw-
   close)

  3.2.4 RECV and SEND procedure for open application AEAD

   When the application AEAD is opened RECV performs decryption and
   encryption operations (see figure 8).

   For decryption operation (RECV(F-Decrypt)) the RECV procedure pushes
   the incoming record packet. The returned payload by the SEND
   procedure is the decrypted message ended by the protocol byte.

   For encryption operation (RECV(F-Encrypt)) the RECV procedure pushes
   the content to encrypt ended by the associated protocol byte. The
   returned payload by the SEND procedure is a record packet, including
   the encrypted content.













   Urien                     Expires March 2021             [Page 8]


               Secure Element for TLS Version 1.3      September 2020


    TCP/IP Node                                    Secure Element
       |                                                 |
       |-RECV(F-First, Frag#1)-------------------------->|
       |<------------------------------------sw-ok= 9000-|
       |-RECV(F-More,  Frag#i)-------------------------->|
       |<------------------------------------sw-ok= 9000-|
       |-RECV(F-Decrypt/F-Encrypt, F-Last, Frag#n)------>|
       |<--------------------------sw-more(size#1)= 61xy-|
       |-SEND(size#1)----------------------------------->|
       |<----------------------Frag#1 || sw-more(size#2)-|
       |-SEND(size#i)----------------------------------->|
       |<------------------Frag#i || sw-more(size#[i+1])-|
       |-SEND(size#n)----------------------------------->|
       |<-------------------------------Frag#n || sw-ok)-|=> SEND End
       |<-----------------------------Frag#n || sw-close-|=> Close

   Figure 8. Decryption/Encryption operations.


3.3 TLS state machine

   The state machine manages TLS flights, it determines the next record
   packet to be received & checked, and the next record packet to be
   built and sent. The number of states and their order is dependent on
   the TLS-SE role (client or server), and on the supported working
   mode (pre shared key, server with certificate, server and client
   with certificate). Figure 9 details an example of state machine for
   TLS-SE server, using pre-shared key. The ordered list of states
   comprises: S-Ready, S-Extensions, S-SFinished, S-ClientCCS, S-
   CFinished and S-Open.





















   Urien                     Expires March 2021             [Page 9]


               Secure Element for TLS Version 1.3      September 2020



          TCP/IP Node                   Secure Element
              |                               |
              |-RESET------------------------>|
              |<------------------------sw-ok-| state = S-Ready
       Client |-RECV(F-First,Frag#1)--------->|
       Hello  |<------------------------sw-ok-|
              |-RECV(F-Last,Frag#2)---------->|
              |                               | Check-ClientHello
              |                               | Make-ServerHello
              |<----------------sw-more(size)-| state= S-Extensions
              |-SEND(size)------------------->|
       Server |<--------Packet||sw-more(size)-|
       Hello  |                               |
              |-SEND(size)------------------->| Make-Extensions
    Server    |<--------Packet||sw-more(size)-| state= S-SFinished
    Encrypted |                               |
    Extension |-SEND(size)------------------->|
              |                               | Make-ServerFinished
     Server   |<----------------Packet||sw-ok-| state= S-ClientCCS
     Finished |                               |
              |                               |
    ClientCCS |-RECV(F-First,F-Last,Packet)-->| Check-Client, Check CCS
              |<------------------------sw-ok-| state= S-CFinished
              |                               |
              |                               |
    Client    |-RECV(F-First,F-Last,Packet)->-| Check-CFinished
    Finished  |<----------------------sw-open-| state= S-Open
              |                               |
       Packet |-RECV(F-Decrypt,Packet)------->| Decrypt Packet
              |<----------------sw-more(size)-| Clear Form Message
              |-SEND(size)------------------->|
              |<------ -Message||ptcol||sw-ok-|
              |                               |
      Message |-RECV(F-Encrypt,Message)------>| Encrypt
              |<----------------sw-more(size)-| Record Packet
              |-SEND(size)------------------->|
              |<------ -Record Packet ||sw-ok-|
              |                               |

   Figure 9. TLS-SE server with pre-share key state machine

3.4 TLS library

   The TLS-SE library is a set of procedures that check, according to
   the state machine, incoming record packets and build outgoing record
   packets. In figure 9 the TLS library comprises the following
   elements: Check-ClientHello, Check-ClientCCS, Check-ClientFinished,
   Make-ServerHello, Make-EncryptedExensions, and MakeServerFinished.


   Urien                     Expires March 2021             [Page 10]


               Secure Element for TLS Version 1.3      September 2020

4 ISO7816 interface

   The RECV and SEND binary encoding is shown by figure 10

   +------+-----+-----+-------------+-----------+----------+---------+
   + name | CLA | INS |      P1     |     P2    |     P3   | Payload |
   +------+-----+-----+-------------+-----------+----------+---------+
   | RECV |  00 |  D8 | 01= Decrypt | 01= First | Fragment |         |
   |      |           | 02= Encrypt | 02= Last  |  Length  |   Yes   |
   |      |     |     |             |           | 0= RESET |         |
   +------+-----+-----+-------------+-----------+----------+---------+
   | SEND |  00 |  C0 |     00      |    00     | Incoming |    No   |
   |      |     |     |             |           |  Length  |         |
   +------+-----+-----+-------------+-----------+----------+---------+

   Figure 10. RECV and SEND ISO7816 requests binary encoding

   The status word binary encoding is shown by figure 11. Two binary
   encoding of sw-more MUST be supported. In the T=0 context, SE
   operating system returns the 61xy status when a request including a
   payload, induces a response with a payload. The status 9Fxy is
   managed by the application in order to notify response size to be
   returned. The TLS-SE application MAY use 61xy status, but this could
   induce interoperability issues.

   +----------------+-----+------+
   |      name      | SW1 |  SW2 |
   +----------------+-----+------+
   |      sw-ok     |  90 |  00  |
   +----------------+-----+------+
   |  sw-more(size) |  61 | size |
   |                |  9F | size |
   +----------------+-----+------+
   | sw-retry(size) |  6C + size |
   +----------------+-----+------+
   |    sw-open     |  90 |  01  |
   +----------------+-----+------+
   |    sw-close    |  90 |  02  |
   +----------------+-----+------+
   |    sw-error    |  6D |error |
   |                |  6F |number|
   +----------------+-----+------+

   Figure 11. ISO7816 status word binary encoding








   Urien                     Expires March 2021             [Page 11]


               Secure Element for TLS Version 1.3      September 2020


5 ISO 7816 Use Case

   Below is an illustration of TLS-SE server, using a pre-shared key
   (PSK) with DHE over the secp256r1 curve, and the cipher suite AES-
   128-CCM-SHA256. The time consumed by handshake is about 1.4s.

   PSK=
   0102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F20
   DHE=
   037E6E633541EC03DB700A28E7DABB74F8E84D4A28E5F024B46F468A7821305D

   RECV(Client Hello)

   Tx: 00 D8 00 01 F0 16 03 03 00 F2 01 00 00 EE 03 03
       4E 65 53 05 52 AB 3E 83 14 0B 2F 9C 2F D7 BC 16
       F9 F5 C4 A9 86 CA 3F C8 8C 6E 8C D1 10 BB B1 57
       00 00 02 13 04 01 00 00 C3 00 2D 00 03 02 00 01
       00 2B 00 03 02 03 04 00 0D 00 1E 00 1C 06 03 05
       03 04 03 02 03 08 06 08 0B 08 05 08 0A 08 04 08
       09 06 01 05 01 04 01 02 01 00 33 00 47 00 45 00
       17 00 41 04 9A 1E 0A D8 40 88 D4 21 D1 55 D7 F2
       8F 78 4C 28 75 F5 19 CA 12 71 96 92 C4 07 8F B4
       35 42 57 E7 64 24 C1 BC 5D 89 0E F4 08 FD 25 8D
       24 F4 64 BB C3 F4 80 D3 BF 2C 23 A0 F9 2D A7 88
       0C 5B 44 53 00 0A 00 06 00 04 00 18 00 17 00 29
       00 3A 00 15 00 0F 43 6C 69 65 6E 74 5F 69 64 65
       6E 74 69 74 79 00 00 00 00 00 21 20 CC 05 4A 9F
       DE 70 E9 96 D6 01 69 61 F5 9A 78 20 D9 FC 6D ED
       4C C6 0A 7B 0D
   Rx: 90 00  [47 ms]
   Tx: 00 D8 00 02 07 4B 68 8F 4E B9 B2 CA

   Rx: 61 86  [879 ms]

   SEND(Server Hello)

   Tx: 00 C0 00 00 86
   Rx: 16 03 03 00 81 02 00 00 7D 03 03 5C 78 A4 E1 93
       34 D7 D9 64 B2 85 64 1B E4 76 63 94 39 1F 4A 15
       27 0A A4 C6 A0 C6 93 D9 E2 16 4D 00 13 04 00 00
       55 00 29 00 02 00 00 00 33 00 45 00 17 00 41 04
       25 C9 16 94 8B 39 51 D2 8E 88 70 F7 F5 4E 6C 31
       62 93 B1 65 55 2C 30 B2 5E 75 6C D8 FE AF DA A7
       67 D8 AD A7 BE 68 54 EA 3E A0 0B 4D CC 62 93 96
       38 07 68 29 3E D5 E6 0C 25 4A EA 12 C9 F8 99 7F
       00 2B 00 02 03 04 9F 1C  [32 ms]





   Urien                     Expires March 2021             [Page 12]


               Secure Element for TLS Version 1.3      September 2020

   SEND(Server Encrypted Extensions)

   Tx: 00 C0 00 00 1C


   Rx: 17 03 03 00 17 E6 04 4A 52 1A 50 B5 54 D8 73 5E
       00 F4 FD 66 BB B3 74 50 99 36 C8 08 9F 3A  [78 ms]

   SEND(Server Encrypted Finished)

   Tx: 00 C0 00 00 3A

   Rx: 17 03 03 00 35 CB CA 03 3E E4 34 7E D2 0C 7C 24
       C1 8F 39 A2 74 39 24 47 78 BE 94 95 7A 31 EC 03
       D5 0C A8 1C 46 04 05 F2 83 3E 99 0D AD D6 66 63
       60 23 F8 5D 7B 77 0F 95 18 35 90 00  [185 ms]

   RECV(Client Encrypted Finished)

   Tx: 00 D8 00 03 3A 17 03 03 00 35 BC 29 18 D1 B8 4B
       C0 3F 6F 81 79 D9 7E FD 58 E3 76 EA 61 13 9C 3E
       40 0F 34 CD 94 CE C1 44 CB 76 70 7D DA 8A 54 69
       41 D9 80 CD 5D 52 8F E5 38 D8 52 92 20 54 5E
   Rx: 90 01  [389 ms]

   TLS13 session is open

   Decryption of incoming Record Packet
   RECV(Decrypt, Packet)
   Tx: 00 D8 01 03 24 17 03 03 00 1F 56 E2 D5 B5 C4 A6
       E2 3E 54 56 5A C4 2D E9 99 F3 58 22 34 15 15 A7
       96 FD 0E B0 61 60 4C 52 87
   Rx: 61 0F  [78 ms]

   SEND(Message)

   Tx: 00 C0 00 00 0F

   Rx: 68 65 6C 6C 6F 20 77 6F 72 6C 64 21 0D 0A 17 90
       00  [15 ms]
   Rx: hello world! ptcol=17


   Encryption of message

   RECV(Encrypt,Message)
   Tx: 00 D8 02 03 0F 68 65 6C 6C 6F 20 77 6F 72 6C 64
       21 0D 0A 17

   Rx: 61 24  [79 ms]


   Urien                     Expires March 2021             [Page 13]


               Secure Element for TLS Version 1.3      September 2020

   SEND(Record Packet)

   Tx: 00 C0 00 00 24
   Rx: 17 03 03 00 1F 6F 78 FF 68 0F CA 9E 31 53 2C 96
       B3 FA D7 B0 51 1B 92 81 35 3D DB FE E9 18 A7 DF
       36 2F A5 27 90 00  [16 ms]


5 IANA Considerations

   TODO

6 Security Considerations

   TODO

7 References

7.1 Normative References

   [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.

   [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards
   with Contacts", The International Organization for Standardization
   (ISO).

   [IEEE1363] IEEE, "IEEE Standard Specifications for Public Key
   Cryptography", IEEE Std. 1363-2000, DOI 10.1109/IEEESTD.2000.92292.

7.2 Informative References

   [IM] Urien, P., "Identity Module for TLS Version 1.3", draft-urien-
   tls-im-03.txt, July 2020.

8 Authors' Addresses

   Pascal Urien
   Telecom Paris
   19 place Marguerite Perey
   91120 Palaiseau           Phone: NA
   France                    Email: Pascal.Urien@telecom-paris.fr









   Urien                     Expires March 2021             [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/