Bootstrapped TLS Authentication

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Owen Friel  , Dan Harkins 
Last updated 2020-03-06
Stream (None)
Formats plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           O. Friel
Internet-Draft                                                     Cisco
Intended status: Standards Track                              D. Harkins
Expires: September 7, 2020                    Hewlett-Packard Enterprise
                                                          March 06, 2020

                    Bootstrapped TLS Authentication


   This document defines a TLS extension that enables a server to prove
   to a client that it has knowledge of the public key of a key pair
   where the client has knowledge of the private key of the key pair.
   Unlike standard TLS key exchanges, the public key is never exchanged
   in TLS protocol messages.  Proof of knowledge of the public key is
   used by the client to bootstrap trust in the server.  The use case
   outlined in this document is to establish trust in an EAP server.

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

   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 September 7, 2020.

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
   ( 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

Friel & Harkins         Expires September 7, 2020               [Page 1]
Internet-Draft                   TLS-POK                      March 2020

   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
     1.1.  Bootstrap Key Pair  . . . . . . . . . . . . . . . . . . .   2
     1.2.  Alignment with Wi-Fi Alliance Device Provisioning Profile   3
   2.  Bootstrapping in TLS 1.3  . . . . . . . . . . . . . . . . . .   4
     2.1.  Server Ephemeral Key Options  . . . . . . . . . . . . . .   4
     2.2.  Bootstrap Key Extension . . . . . . . . . . . . . . . . .   4
     2.3.  Changes to TLS 1.3 Handshake  . . . . . . . . . . . . . .   4
     2.4.  Changes to TLS 1.3 Key Schedule . . . . . . . . . . . . .   5
   3.  Using TLS Bootstrapping in EAP  . . . . . . . . . . . . . . .   6
   4.  Summary of Work . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   On-boarding of devices with no, or limited, user interface can be
   difficult.  Typically, a credential is needed to access the network
   and network connectivity is needed to obtain a credential.  This
   poses a catch-22.

   If trust in the integrity of a device's public key can be obtained in
   an out-of-band fashion, a device can be authenticated and provisioned
   with a usable credential for network access.  While this
   authentication can be strong, the device's authentication of the
   network is somewhat weaker.  [Stajano]] presents a functional
   security model to address this asymmetry.

   There are on-boarding protocols, such as [DPP], to address this use
   case but they have drawbacks.  [DPP] for instance does not support
   wired network access.  This document describes an on-boarding
   protocol, which we refer to as TLS Proof of Knowledge or TLS-POK.

1.1.  Bootstrap Key Pair

   The mechanism for on-boarding of devices defined in this document
   relies on bootstrap key pairs.  A client device has an associated
   elliptic curve (EC) key pair.  The key pair may be static and baked
   into device firmware at manufacturing time, or may be dynamic and
   generated at on-boarding time by the device.  If this public key,
   specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5280],

Friel & Harkins         Expires September 7, 2020               [Page 2]
Internet-Draft                   TLS-POK                      March 2020

   can be shared in a trustworthy manner with a TLS server, a form of
   "origin entity authentication" (the step from which all subsequent
   authentication proceeds) can be obtained.

   The exact mechanism by which the server gains knowledge of the public
   key is out of scope of this specification, but possible mechanisms
   include scanning a QR code to obtain a base64 encoding of the
   ASN.1-formatted public key or upload of a Bill of Materials (BOM).
   If the QR code is physically attached to the client device, or the
   BOM is associated with the device, the assumption is that the public
   key obtained in this bootstrapping method belongs to the client.  In
   this model, physical possession of the device implies legitimate

   The server may have knowledge of multiple bootstrap public keys
   corresponding to multiple devices, and TLS extensions are defined in
   this document that enable the server to identity a specific bootstrap
   public key correspinding to a specific device.

   Using the extensions defined herein, the client proves to the server
   that it has possession of the private analog to its public
   bootstrapping key.  Provided that the mechanism in which the server
   obtained the bootstrapping key is trustworthy, a commensurate amount
   of authenticity of the resulting connection can be obtained.  The
   server also proves that it knows the client's public key which, if
   the client does not gratuitously expose its public key, can be used
   to obtain a modicum of correctness, that the client is connecting to
   the correct network (see [Stajano]).

1.2.  Alignment with Wi-Fi Alliance Device Provisioning Profile

   The definition of the boostrap public key aligns with that given in
   [DPP].  This, for example, enables the QR code format as defined in
   [DPP] to be reused for TLS-POK.  Therefore, a device that supports
   both wired LAN and Wi-Fi LAN connections can have a single QR code
   printed on its label, and the bootstrap key can be used for DPP if
   the device bootstraps against a Wi-Fi network, or TLS-POK if the
   device bootstraps against a wired network.  Similarly, a common
   bootstrap public key format could be imported in a BOM into a server
   that handles devices connecting over both wired and Wi-Fi networks.

   Any bootstrapping method defined for, or used by, [DPP] is compatible
   with TLS-POK.

Friel & Harkins         Expires September 7, 2020               [Page 3]
Internet-Draft                   TLS-POK                      March 2020

2.  Bootstrapping in TLS 1.3

   The bootstrapping modifications introduce an extension to identify a
   "bootstrapping" key into the TLS 1.3 handshake.  This key MUST be
   from a cryptosystem suitable for doing (EC)DH.  When using the
   bootstrapping extension, two (EC)DH operations are performed, a
   static-ephemeral (using the client's bootstrapping key and an
   ephemeral key generated by the server) and an ephemeral-ephemeral
   (using the client's ephemeral key and an ephemeral key generated by
   the server).

2.1.  Server Ephemeral Key Options

   [[ TODO: Need to decide which mechanism to use here ]]

   There are two options for generation of the server's ephemeral key.

   o  server generates one ephemeral key pair: the key pair is reused by
      the server for both static-ephemeral (bootstrap) and ephemeral-
      ephemeral (TLS key_share) ECDH exchanges.  This means that the
      bootstrap and key_share keys MUST be on the same curve.

   o  server generates two ephemeral key pairs: one that is used for the
      static-ephemeral (bootstrap) ECDH exchange, and one that is used
      for the ephemeral-ephemeral (TLS key_share) DH exchange.  The
      bootstrap and key_share keys are independent.  The key_share keys
      may be Finite Field DH keys.

   This document assumes the latter and that the server generates unique
   ephemeral key pairs for bootstrap and key_share.

2.2.  Bootstrap Key Extension

     struct {
         opaque bskey[32];
     } BootstrapKey;

   The bootstrapping key of the client is specified using the
   BootstrapKey extension.  The 'bskey' field of this extension SHALL
   consist of the base64 encoded SHA256 digest of the DER-encoded ASN.1
   subjectPublicKeyInfo representation of the bootstrapping public key.

2.3.  Changes to TLS 1.3 Handshake

   The client identifies the bootstrapping key in the ClientHello using
   the BootstrapKey extension.  The server looks up the client's
   bootstrapping key in its database by checking the SHA256 hash of each

Friel & Harkins         Expires September 7, 2020               [Page 4]
Internet-Draft                   TLS-POK                      March 2020

   entry with the value received in the ClientHello.  If no match is
   found, the server SHOULD respond with an unknown_bskey error alert.

   If the server found the matching bootstrap key, the server generates
   an ephemeral ECDH keypair on the curve indicated in the bootstrap
   public key information, and performs an ECDH operation using the
   client bootstrap key and the server's ephemeral keypair.  The server
   echos the BootstrapKey extension back to the client in the
   ServerHello to explicitly confirm to the client that it has performed
   an ECDH using the bootstrap key, and has injected the output into the
   key schedule.

   This is in addition to, and independent from, the (EC)DH that the
   server carries out when handling the key_share extension.

   The handshake is shown in Figure 1.

            Client                                            Server
            --------                                          --------
            + bskey
            + key_share                -------->
                                                           + bskey
                                                           + key_share
                                       <--------   [Application Data*]
            {Finished}                 -------->
            [Application Data]         <------->    [Application Data]

                   Figure 1: TLS 1.3 TLS-POK Handshake

2.4.  Changes to TLS 1.3 Key Schedule

   [[ TODO: The key schedule mechanism needs to closed. ]]

   Multiple options for modifying the TLS 1.3 key schedule have been
   proporsed recently including [I-D.stebila-tls-hybrid-design] and
   [I-D.jhoyla-tls-extended-key-schedule].  The key schedule used for
   TLS-POK will align with the final direction chosen by the TLS WG.

   This document proposes aligning with the model outlined in
   [I-D.jhoyla-tls-extended-key-schedule] where the shared secrets
   derived from the bskey and key_share key exchanges are injected in
   sequence into the key schedule.

   The key schedule for TLS-POK is as follows:

Friel & Harkins         Expires September 7, 2020               [Page 5]
Internet-Draft                   TLS-POK                      March 2020

                            PSK ->  HKDF-Extract = Early Secret
                                          +-----> Derive-Secret(...)
                                          +-----> Derive-Secret(...)
                                          +-----> Derive-Secret(...)
                                    Derive-Secret(., "derived", "")
                           bskey_input -> HKDF-Extract
                                    Derive-Secret(., "derived", "")
                   (EC)DHE -> HKDF-Extract = Handshake Secret
                                          +-----> Derive-Secret(...)
                                          +-----> Derive-Secret(...)
                                    Derive-Secret(., "derived", "")
                               0 -> HKDF-Extract = Master Secret
                                          +-----> Derive-Secret(...)
                                          +-----> Derive-Secret(...)
                                          +-----> Derive-Secret(...)
                                          +-----> Derive-Secret(...)

3.  Using TLS Bootstrapping in EAP

   Enterprise deployments typically require an 802.1X/EAP-based
   authentication to obtain network access.  Protocols like [RFC7030]
   can be used to enroll devices into a Certification Authority to allow
   them to authenticate using 802.1X/EAP.  But this creates a Catch-22
   where a certificate is needed for network access and network access
   is needed to obtain certificate.

   Devices whose bootstrapping key can been obtained in an out-of-band
   fashion can perform an EAP-TLS-based exchange, for instance
   [RFC7170], and authenticate the TLS exchange using the bootstrapping
   extensions defined in Section 2.  This network connectivity can then

Friel & Harkins         Expires September 7, 2020               [Page 6]
Internet-Draft                   TLS-POK                      March 2020

   be used to perform an enrollment protocol (such as provided by
   [RFC7170]) to obtain a credential for subsequent network connectivity
   and certificate lifecycle maintenance.

   Upon "link up", an Authenticator on an 802.1X-protected port will
   issue an EAP Identify request to the newly connected peer.  For
   unprovisioned devices that desire to take advantage of TLS-POK, there
   is no initial realm in which to construct an NAI (see [RFC4282]) so
   the initial EAP Identity response SHOULD contain simply the name
   "TLS-POK" in order to indicate to the Authenticator that an EAP
   method that supports TLS-POK SHOULD be started.

              Authenticating Peer     Authenticator
              -------------------     -------------
                                       <- EAP-Request/

               Identity (TLS-POK) ->

                                       <- EAP-Request/
                                       (TLS Start)

4.  Summary of Work

   [TODO: agree with WG chairs where this work lives and where it should
   be documented.]

   The protocol outlined here can be broadly broken up into 3 distinct

   o  TLS extensions to transport the bootstrap public key identifier

   o  TLS key schedule enhancements to inject bootstrap public key
      keying material

   o  TEAP extensions to leverage the new TLS-POK handshake for trust

   This document captures all 3 areas, but it may be more appropriate to
   split the work into multiple documents e.g.:

   o  piggy back on top of [I-D.jhoyla-tls-extended-key-schedule] for
      TLS key schedule enhancements

Friel & Harkins         Expires September 7, 2020               [Page 7]
Internet-Draft                   TLS-POK                      March 2020

   o  include the TEAP extensions in Eliot's TEAP-BRSKI
      [I-D.lear-eap-teap-brski] draft

5.  IANA Considerations

   IANA will allocated an ExtensionType for the bskey extension from the
   appropriate TLS 1.3 repository and replace TBD in this document with
   that number.

6.  Security Considerations

   Bootstrap and trust establishment by the TLS server is based on proof
   of knowledge of the client's bootstrap public key.  An attack on the
   bootstrapping method which substitutes the public key of a corrupted
   device for the public key of an honest device can result in the TLS
   sever on-boarding and trusting the corrupted device.

   Trust on the part of the client is not strong and is based on an
   assumption that the public bootstrapping key is not widely
   disseminated.  If an adversary has knowledge of the bootstrap public
   key, the adversary may be able to make the client bootstrap against
   the adversary's network.  For example, if an adversary intercepts and
   scans QR labels on clients, and the adversary can force the client to
   connect to its server, then the adversary can complete the TLS-POK
   handshake with the client and the client will connect to the
   adversary's server.  Since physical possession implies ownership,
   there is nothing to prevent a stolen device from being on-boarded.

7.  Informative References

   [DPP]      Wi-Fi Alliance, "Device Provisioning Profile", 2020.

              Hoyland, J. and C. Wood, "TLS 1.3 Extended Key Schedule",
              draft-jhoyla-tls-extended-key-schedule-00 (work in
              progress), November 2019.

              Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP
              Update and Extensions for Bootstrapping", draft-lear-eap-
              teap-brski-05 (work in progress), November 2019.

              Steblia, D., Fluhrer, S., and S. Gueron, "Hybrid key
              exchange in TLS 1.3", draft-stebila-tls-hybrid-design-03
              (work in progress), February 2020.

Friel & Harkins         Expires September 7, 2020               [Page 8]
Internet-Draft                   TLS-POK                      March 2020

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282,
              DOI 10.17487/RFC4282, December 2005,

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,

   [RFC7170]  Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
              "Tunnel Extensible Authentication Protocol (TEAP) Version
              1", RFC 7170, DOI 10.17487/RFC7170, May 2014,

   [Stajano]  Anderson, S., "The Ressurecting Ducking: Security Issues
              for Ad-Hoc Wireless Networks", 1999.

Authors' Addresses

   Owen Friel


   Dan Harkins
   Hewlett-Packard Enterprise


Friel & Harkins         Expires September 7, 2020               [Page 9]