Bootstrapped TLS Authentication
draft-friel-tls-eap-dpp-00

Document Type Active Internet-Draft (individual)
Last updated 2020-03-06
Stream (None)
Intended RFC status (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
                       draft-friel-tls-eap-dpp-00

Abstract

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

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]
Show full document text