Deep Thoughts on Network Onboarding Challenges
draft-lear-iotops-deep-thoughts-on-onboarding-00

Document Type Active Internet-Draft (individual)
Author Eliot Lear 
Last updated 2021-03-09
Replaces draft-lear-iotops-onboard-intr
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized (tools) 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                                            E. Lear
Internet-Draft                                             Cisco Systems
Intended status: Informational                            March 09, 2021
Expires: September 10, 2021

             Deep Thoughts on Network Onboarding Challenges
            draft-lear-iotops-deep-thoughts-on-onboarding-00

Abstract

   With various onboarding methods being built out, one aspect that has
   been overlooked is the trust relationship between the deployment and
   the manufacturer.  This document asks questions about how that trust
   should be established, and how it can be leveraged.

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 10, 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.

Lear                   Expires September 10, 2021               [Page 1]
Internet-Draft        Network Onboarding Challenges           March 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Device Provisioning Protocol  . . . . . . . . . . . . . .   2
     1.2.  Bootstrapping Remote Key Infratructure (BRSKI)  . . . . .   3
   2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Resale and Transfer . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Choices, Choices  . . . . . . . . . . . . . . . . . . . .   5
   4.  Beware too much mechanism . . . . . . . . . . . . . . . . . .   6
   5.  This is really only about network onboarding  . . . . . . . .   6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Changes from Earlier Versions  . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   A number of network onboarding technologies are currently beginning
   to mature in the market place.  The questions they all seek to answer
   are these:

   o  How does the device know that it should join a particular network?

   o  How does the network know that it should trust a particular
      device?

   Let's examine two protocols to understand how these questions are
   answered and what questions may also be interesting to ask.  We will
   begin with looking at the Wifi Alliance's Device Provisioning
   Protocol, and then take a gander at Bootstrapping Remote Secure Key
   Infrastructure (BRSKI)[I-D.ietf-anima-bootstrapping-keyinfra], with a
   quick review of the operation model of each.  We focus our attention
   to zero touch provisioning.

   Zero touch provisioning in this context means that the device
   receives network credentials that it will use to bidirectionally
   authenticate with an appropriate network without any human direction
   or validation at the time that the device is first powered at the
   deployment.

1.1.  Device Provisioning Protocol

   As is described in its specification, Device Provisioning Protocol or
   DPP makes use of a public/private key pair.  The private key is
   stored in the device, and the public key is provided to the user out
   of band.

   In the current specification, either side may initiate communciation,
   but for battery saving reasons, it is generally preferred that the

Lear                   Expires September 10, 2021               [Page 2]
Internet-Draft        Network Onboarding Challenges           March 2021

   endpoint initiate, and thus be in a position to disable its
   transceiver at other times.

   Several validations then take place.  The network is able to prove to
   the endpoint that it has the correct public key, and the device is
   able to prove to the network that it has the correct private key.
   Thus, mutual authentication has taken place.  The next exchange
Show full document text