Internet DRAFT - draft-lear-iotops-deep-thoughts-on-onboarding
draft-lear-iotops-deep-thoughts-on-onboarding
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
allows for appropriate credentials to be provisioned in the device,
such as a trust anchor or an SAE password.
As previously mentioned, the public key is provided to the user out
of band. In this sense, the public key is effectively a password, in
that anyone who holds it may onboard the device. If the user would
ned to scan the public key from a QR code or via OCR, we would not
call such a step "hands free". If the user needs to agree to
onboarding a device at the time it is enabled, then here again we
would not call this "hands free".
This leaves one additional possibility: communication of the public
key via electronic means for the device having been deployed. The
DPP standard doesn't discuss this method. This may provide a means
for zero-touch deployment. In this context, we might consider the
device that receives and stores public keys a form of a registrar.
While Internet connectivity is not required for DPP to function on
its own, transmission of an public key would require some
connectivity at some point.
The assumed endstate in all of this is that the device will be able
to authenticate to the network without the Internet being available.
While this may not be important in some cases, such as with devices
whose applications require Internet availability to function, it
would will be critical for other cases, such as disconnected
environments with critical control functions.
1.2. Bootstrapping Remote Key Infratructure (BRSKI)
BRSKI's flow is somewhat different. In this case, the endpoint sends
a voucher request to a registrar in the local deployment, who adorns
the request with is public key information. This request is then
forwarded to the device's manufacturer, who can take whatever choices
it will to determine whether the device belongs in a particular local
deployment. Those choices include:
o Nothing. It can just sign the voucher request, logging the
request.
Lear Expires September 10, 2021 [Page 3]
Internet-Draft Network Onboarding Challenges March 2021
o Validation that a particular device belongs in a particular
deployment.
The first step is problematic for wireless deployments because a
device would simply join the first network it heard, if it could
authenticate, and there is no reason to believe that the first
network would be the correct network.
The second step is not standardized. It is possible that an out-of-
band introduction is taking place on the first transaction, but that
would not be a zero-touch flow.
At some point, the deployment must also assign establish that the
device belongs on its network. This too is not specified by the
standard.
2. Discussion
In the case of both BRSKI and DPP, once the device is onboarded by
the network, no Internet connectivity is required. This is
important, as a matter of resiliency.
BRSKI and DPP barely differ the gaps they have to get to zero-touch
provisioning. In BRSKI's case, it's about establishing trust between
the registrar and the manufacturer, a one time affair, and then then
later the registrar having some reason to believe that particular
device belongs within a deployment. In the case of DPP, once one
decides that keys are going to be delivered in advance, whatever
service receives them has to have been introduced to the service
sending them.
One could perhaps envision a system in which credentials are
transmitted at time of sale to a registrar. In the case of BRSKI,
this would involve careful configuration of voucher requests, in
which the voucher is "nonceless", but yet bound to a particular
deployment.
This leads us to another concern.
3. Resale and Transfer
We should assume that device ownership and use will change over time.
This presents some additional problems. We assume, for purposes of
this discussion that both DPP and BRSKI have some form of a registrar
function. We also assume that zero-touch may or may not require a
device reset (a'la pin in the hole, type).
There are several ways to think about this problem:
Lear Expires September 10, 2021 [Page 4]
Internet-Draft Network Onboarding Challenges March 2021
o seller transmits something to the buyer registrar as part of a
transaction.
o seller provides buyer an artifact as part of a sale.
o original manufacturer records the sale.
o original manufacturer simply notes the transfer.
Let's dispense with the last option. It suffers all the same
wireless problems as the original case. Therefore, it is not further
considered in this discussion.
If the seller transmits something to the buyer registrar as part of a
transaction, this means that the seller must have identified the
buyer registrar. That in itself may be a trick. If the seller
provides the buyer with an artifact, the buyer must do something with
it. Both of these methods suffer a particular problem: if the
original owner went out of business, there is no chance for any
transfer to take place.
If the original manufacturer records the sale, this means that the
new owner would have to either know to query the manufacturer, or
that the manufacturer would have enough information to send an
appropriate credential to the new owner. This _also_ means that the
manufacturer is still in business.
3.1. Choices, Choices
The above models are not necessarily mutually exclusive. That is, it
might be possible to rely on automated means when they exist, and
otherwise rely on less automated means when they do not exist. This
is somewhat problematic for BRSKI, in that somehow or another a
voucher needs to be generated.
Alternatively we might ponder an additional actor whose role it is to
safeguard transfer credentials in the form of an escrow agent. The
existence of such an actor introduces a number of questions:
o How would the buyer know to use a particular escrow agent?
o Is there an incentive model that would bring such an agent into
creation? After all, someone has to pay for such a service.
o How is transaction privacy maintained (or is _that_ how the
service gets paid for)?
Lear Expires September 10, 2021 [Page 5]
Internet-Draft Network Onboarding Challenges March 2021
Another model, and the author writes this with great trepidation, is
the use of Merkle trees to record a transaction. This has the
benefit of being able to establish previous ownership, but has the
risks that the previous owner is no longer in existence to provide an
assertion that the device has transfered. On the third hand, perhaps
a claim by a known party is enough. Such transactions have privacy
implications as well, and there has to be an incentive model to
maintain a distributed ledger.
4. Beware too much mechanism
As this area of work advances, there will be the temptation to add a
vast amount of mechanism. The previous supposition of the use of
Merkel trees is a great example of just that. From an IoT device
standpoint, it's all but interolerable. We are, after all, talking
about a codespace that is generally considered to be constrainted.
5. This is really only about network onboarding
But that may not be the only problem. Rekeying will occasionally
happen for various reasons. How this takes places will depend on the
authentication mechanism used in a deployment. If EAP-TLS or TEAP
are used, the presumption is that there will be an EST server or
similar available for credential renewal.
For private shared keys, there currently is no great answer to this
question.
6. Normative References
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-45 (work in progress), November 2020.
[I-D.ietf-anima-brski-async-enroll]
Fries, S., Brockhaus, H., Lear, E., and T. Werner,
"Support of asynchronous Enrollment in BRSKI (BRSKI-AE)",
draft-ietf-anima-brski-async-enroll-01 (work in progress),
January 2021.
Appendix A. Changes from Earlier Versions
Draft -00:
o Initial revision
Lear Expires September 10, 2021 [Page 6]
Internet-Draft Network Onboarding Challenges March 2021
Author's Address
Eliot Lear
Cisco Systems
Richtistrasse 7
Wallisellen CH-8304
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
Lear Expires September 10, 2021 [Page 7]
