Zero Touch Provisioning for Networking Devices
draft-ietf-netconf-zerotouch-24
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8572.
|
|
|---|---|---|---|
| Authors | Kent Watsen , Mikael Abrahamsson , Ian Farrer | ||
| Last updated | 2018-09-05 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | Mahesh Jethanandani | ||
| IESG | IESG state | Became RFC 8572 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | Bert Wijnen <bwijnen@bwijnen.net>, Bert Wijnen <bwietf@bwijnen.net>, Mahesh Jethanandani <mjethanandani@gmail.com> |
draft-ietf-netconf-zerotouch-24
#x27;s devices initiates an
enrollment process with the manufacturer. This process includes
the following:
* Regardless how the prospective owner intends to bootstrap
their devices, they will always obtain from the manufacturer
the trust anchor certificate for the IDevID certificates.
This certificate will is installed on the prospective owner's
Watsen, et al. Expires March 9, 2019 [Page 73]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
NMS so that the NMS can authenticate the IDevID certificates
when they are presented to subsequent steps.
* If the manufacturer hosts an Internet based bootstrap server
(e.g., a redirect server) such as described in Section 4.4,
then credentials necessary to configure the bootstrap server
would be provided to the prospective owner. If the bootstrap
server is configurable through an API (outside the scope of
this document), then the credentials might be installed on the
prospective owner's NMS so that the NMS can subsequently
configure the manufacturer-hosted bootstrap server directly.
2. If the manufacturer's devices are able to validate signed data
(Section 5.4), and assuming that the prospective owner's NMS is
able to prepare and sign the bootstrapping data itself, the
prospective owner's NMS might set a trust anchor certificate onto
the manufacturer's bootstrap server, using the credentials
provided in the previous step. This certificate is the trust
anchor certificate that the prospective owner would like the
manufacturer to place into the ownership vouchers it generates,
thereby enabling devices to trust the owner's owner certificate.
How this trust anchor certificate is used to enable devices to
validate signed bootstrapping data is described in Section 5.4.
3. Some time later, the prospective owner places an order with the
manufacturer, perhaps with a special flag checked for zero touch
handling. At this time, or perhaps before placing the order, the
owner may model the devices in their NMS, creating virtual
objects for the devices with no real-world device associations.
For instance the model can be used to simulate the device's
location in the network and the configuration it should have when
fully operational.
4. When the manufacturer fulfills the order, shipping the devices to
their intended locations, they may notify the owner of the
devices' serial numbers and shipping destinations, which the
owner may use to stage the network for when the devices power on.
Additionally, the manufacturer may send one or more ownership
vouchers, cryptographically assigning ownership of those devices
to the owner. The owner may set this information on their NMS,
perhaps binding specific modeled devices to the serial numbers
and ownership vouchers.
C.2. Owner Stages the Network for Bootstrap
The following diagram illustrates how an owner might stage the
network for bootstrapping devices.
Watsen, et al. Expires March 9, 2019 [Page 74]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
+----------+ +------------+
|Deployment| |Manufacturer| +------+ +------+
| Specific | | Hosted | | Local| | Local| +---------+
+---+ |Bootstrap | | Bootstrap | | DNS | | DHCP | |Removable|
|NMS| | Server | | Server | |Server| |Server| | Storage |
+---+ +----------+ +------------+ +------+ +------+ +---------+
| | | | | |
1. | | | | | |
activate| | | | | |
modeled | | | | | |
device | | | | | |
------->| | | | | |
| 2. (optional) | | | |
| configure | | | |
| bootstrap | | | |
| server | | | |
|------->| | | | |
| | | | | |
| 3. (optional) configure | | |
| bootstrap server | | | |
|--------------------->| | | |
| | | | | |
| | | | | |
| 4. (optional) configure DNS server| | |
|---------------------------------->| | |
| | | | | |
| | | | | |
| 5. (optional) configure DHCP server | |
|------------------------------------------->| |
| | | | | |
| | | | | |
| 6. (optional) store bootstrapping artifacts on media |
|----------------------------------------------------->|
| | | | | |
| | | | | |
Each numbered item below corresponds to a numbered item in the
diagram above.
1. Having previously modeled the devices, including setting their
fully operational configurations and associating device serial
numbers and (optionally) ownership vouchers, the owner might
"activate" one or more modeled devices. That is, the owner tells
the NMS to perform the steps necessary to prepare for when the
real-world devices power up and initiate the bootstrapping
process. Note that, in some deployments, this step might be
combined with the last step from the previous workflow. Here it
Watsen, et al. Expires March 9, 2019 [Page 75]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
is depicted that an NMS performs the steps, but they may be
performed manually or through some other mechanism.
2. If it is desired to use a deployment specific bootstrap server,
it must be configured to provide the bootstrapping information
for the specific devices. Configuring the bootstrap server may
occur via a programmatic API not defined by this document.
Illustrated here as an external component, the bootstrap server
may be implemented as an internal component of the NMS itself.
3. If it is desired to use a manufacturer hosted bootstrap server,
it must be configured to provide the bootstrapping information
for the specific devices. The configuration must be either
redirect or onboarding information. That is, either the
manufacturer hosted bootstrap server will redirect the device to
another bootstrap server, or provide the device with the
onboarding information itself. The types of bootstrapping
information the manufacturer hosted bootstrap server supports may
vary by implementation; some implementations may only support
redirect information, or only support onboarding information, or
support both redirect and onboarding information. Configuring
the bootstrap server may occur via a programmatic API not defined
by this document.
4. If it is desired to use a DNS server to supply bootstrapping
information, a DNS server needs to be configured. If multicast
DNS-SD is desired, then the server must reside on the local
network, otherwise the DNS server may reside on a remote network.
Please see Section 4.2 for more information about how to
configure DNS servers. Configuring the DNS server may occur via
a programmatic API not defined by this document.
5. If it is desired to use a DHCP server to supply bootstrapping
data, a DHCP server needs to be configured. The DHCP server may
be accessed directly or via a DHCP relay. Please see Section 4.3
for more information about how to configure DHCP servers.
Configuring the DHCP server may occur via a programmatic API not
defined by this document.
6. If it is desired to use a removable storage device (e.g., USB
flash drive) to supply bootstrapping information, the information
would need to be placed onto it. Please see Section 4.1 for more
information about how to configure a removable storage device.
Watsen, et al. Expires March 9, 2019 [Page 76]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
C.3. Device Powers On
The following diagram illustrates the sequence of activities that
occur when a device powers on.
+----------+
+-----------+ |Deployment|
| Source of | | Specific |
+------+ | Bootstrap | |Bootstrap | +---+
|Device| | Data | | Server | |NMS|
+------+ +-----------+ +----------+ +---+
| | | |
| | | |
| 1. if zerotouch bootstrap service | | |
| is not enabled, then exit. | | |
| | | |
| 2. for each source supported, check | | |
| for bootstrapping data. | | |
|------------------------------------>| | |
| | | |
| 3. if onboarding information found, | | |
| initialize self and, only if | | |
| source is a trusted bootstrap | | |
| server, send progress reports. | | |
|------------------------------------># | |
| # webhook | |
| #----------------------->|
| | |
| 4. else if redirect-information found, for each | |
| bootstrap server specified, check for data. | |
|-+------------------------------------------------->| |
| | | |
| | if more redirect-information is found, recurse | |
| | (not depicted), else if onboarding-information | |
| | found, initialize self and post progress reports | |
| +-------------------------------------------------># |
| # webhook |
| #-------->|
|
| 5. retry sources and/or wait for manual provisioning.
|
The interactions in the above diagram are described below.
1. Upon power being applied, the device checks to see if zerotouch
bootstrapping is configured, such as must be the case when
running its "factory default" configuration. If zerotouch
Watsen, et al. Expires March 9, 2019 [Page 77]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
bootstrapping is not configured, then the bootstrapping logic
exits and none of the following interactions occur.
2. For each source of bootstrapping data the device supports,
preferably in order of closeness to the device (e.g., removable
storage before Internet based servers), the device checks to see
if there is any bootstrapping data for it there.
3. If onboarding information is found, the device initializes itself
accordingly (e.g., installing a boot-image and committing an
initial configuration). If the source is a bootstrap server, and
the bootstrap server can be trusted (i.e., TLS-level
authentication), the device also sends progress reports to the
bootstrap server.
* The contents of the initial configuration should configure an
administrator account on the device (e.g., username, ssh-rsa
key, etc.), and should configure the device either to listen
for NETCONF or RESTCONF connections or to initiate call home
connections [RFC8071], and should disable the zerotouch
bootstrapping service (e.g., the "enabled" leaf in data model
presented in Appendix A).
* If the bootstrap server supports forwarding device progress
reports to external systems (e.g., via a webhook), a
"bootstrap-complete" progress report (Section 7.3) informs the
external system to know when it can, for instance, initiate a
connection to the device. To support this scenario further,
the "bootstrap-complete" progress report may also relay the
device's SSH host keys and/or TLS certificates, with which the
external system can use to authenticate subsequent connections
to the device.
If the device successfully completes the bootstrapping process,
it exits the bootstrapping logic without considering any
additional sources of bootstrapping data.
4. Otherwise, if redirect information is found, the device iterates
through the list of specified bootstrap servers, checking to see
if it has bootstrapping data for the device. If the bootstrap
server returns more redirect information, then the device
processes it recursively. Otherwise, if the bootstrap server
returns onboarding information, the device processes it following
the description provided in (3) above.
5. After having tried all supported sources of bootstrapping data,
the device may retry again all the sources and/or provide
manageability interfaces for manual configuration (e.g., CLI,
Watsen, et al. Expires March 9, 2019 [Page 78]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
HTTP, NETCONF, etc.). If manual configuration is allowed, and
such configuration is provided, the configuration should also
disable the zerotouch bootstrapping service, as the need for
bootstrapping would no longer be present.
Appendix D. Change Log
D.1. ID to 00
o Major structural update; the essence is the same. Most every
section was rewritten to some degree.
o Added a Use Cases section
o Added diagrams for "Actors and Roles" and "NMS Precondition"
sections, and greatly improved the "Device Boot Sequence" diagram
o Removed support for physical presence or any ability for
configlets to not be signed.
o Defined the Zero Touch Information DHCP option
o Added an ability for devices to also download images from
configuration servers
o Added an ability for configlets to be encrypted
o Now configuration servers only have to support HTTP/S - no other
schemes possible
D.2. 00 to 01
o Added boot-image and validate-owner annotations to the "Actors and
Roles" diagram.
o Fixed 2nd paragraph in section 7.1 to reflect current use of
anyxml.
o Added encrypted and signed-encrypted examples
o Replaced YANG module with XSD schema
o Added IANA request for the Zero Touch Information DHCP Option
o Added IANA request for media types for boot-image and
configuration
Watsen, et al. Expires March 9, 2019 [Page 79]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
D.3. 01 to 02
o Replaced the need for a configuration signer with the ability for
each NMS to be able to sign its own configurations, using
manufacturer signed ownership vouchers and owner certificates.
o Renamed configuration server to bootstrap server, a more
representative name given the information devices download from
it.
o Replaced the concept of a configlet by defining a southbound
interface for the bootstrap server using YANG.
o Removed the IANA request for the boot-image and configuration
media types
D.4. 02 to 03
o Minor update, mostly just to add an Editor's Note to show how this
draft might integrate with the draft-pritikin-anima-bootstrapping-
keyinfra.
D.5. 03 to 04
o Major update formally introducing unsigned data and support for
Internet-based redirect servers.
o Added many terms to Terminology section.
o Added all new "Guiding Principles" section.
o Added all new "Sources for Bootstrapping Data" section.
o Rewrote the "Interactions" section and renamed it "Workflow
Overview".
D.6. 04 to 05
o Semi-major update, refactoring the document into more logical
parts
o Created new section for information types
o Added support for DNS servers
o Now allows provisional TLS connections
o Bootstrapping data now supports scripts
Watsen, et al. Expires March 9, 2019 [Page 80]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
o Device Details section overhauled
o Security Considerations expanded
o Filled in enumerations for notification types
D.7. 05 to 06
o Minor update
o Added many Normative and Informative references.
o Added new section Other Considerations.
D.8. 06 to 07
o Minor update
o Added an Editorial Note section for RFC Editor.
o Updated the IANA Considerations section.
D.9. 07 to 08
o Minor update
o Updated to reflect review from Michael Richardson.
D.10. 08 to 09
o Added in missing "Signature" artifact example.
o Added recommendation for manufacturers to use interoperable
formats and file naming conventions for removable storage devices.
o Added configuration-handling leaf to guide if config should be
merged, replaced, or processed like an edit-config/yang-patch
document.
o Added a pre-configuration script, in addition to the post-
configuration script from -05 (issue #15).
D.11. 09 to 10
o Factored ownership voucher and voucher revocation to a separate
document: draft-kwatsen-netconf-voucher. (issue #11)
Watsen, et al. Expires March 9, 2019 [Page 81]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
o Removed <configuration-handling> options "edit-config" and "yang-
patch". (issue #12)
o Defined how a signature over signed-data returned from a bootstrap
server is processed. (issue #13)
o Added recommendation for removable storage devices to use open/
standard file systems when possible. (issue #14)
o Replaced notifications "script-[warning/error]" with "[pre/post]-
script-[warning/error]". (goes with issue #15)
o switched owner-certificate to be encoded using the PKCS #7 format.
(issue #16)
o Replaced md5/sha1 with sha256 inside a choice statement, for
future extensibility. (issue #17)
o A ton of editorial changes, as I went thru the entire draft with a
fine-toothed comb.
D.12. 10 to 11
o fixed yang validation issues found by IETFYANGPageCompilation.
note: these issues were NOT found by pyang --ietf or by the
submission-time validator...
o fixed a typo in the yang module, someone the config false
statement was removed.
D.13. 11 to 12
o fixed typo that prevented Appendix B from loading the examples
correctly.
o fixed more yang validation issues found by
IETFYANGPageCompilation. note: again, these issues were NOT found
by pyang --ietf or by the submission-time validator...
o updated a few of the notification enumerations to be more
consistent with the other enumerations (following the warning/
error pattern).
o updated the information-type artifact to state how it is encoded,
matching the language that was in Appendix B.
Watsen, et al. Expires March 9, 2019 [Page 82]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
D.14. 12 to 13
o defined a standalone artifact to encode the old information-type
into a PKCS #7 structure.
o standalone information artifact hardcodes JSON encoding (to match
the voucher draft).
o combined the information and signature PKCS #7 structures into a
single PKCS #7 structure.
o moved the certificate-revocations into the owner-certificate's
PKCS #7 structure.
o eliminated support for voucher-revocations, to reflect the
voucher-draft's switch from revocations to renewals.
D.15. 13 to 14
o Renamed "bootstrap information" to "onboarding information".
o Rewrote DHCP sections to address the packet-size limitation issue,
as discussed in Chicago.
o Added Ian as an author for his text-contributions to the DHCP
sections.
o Removed the Guiding Principles section.
D.16. 14 to 15
o Renamed action "notification" to "update-progress" and, likewise
"notification-type" to "update-type".
o Updated examples to use "base64encodedvalue==" for binary values.
o Greatly simplified the "Artifact Groupings" section, and moved it
as a subsection to the "Artifacts" section.
o Moved the "Workflow Overview" section to the Appendix.
o Renamed "bootstrap information" to "update information".
o Removed "Other Considerations" section.
o Tons of editorial updates.
Watsen, et al. Expires March 9, 2019 [Page 83]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
D.17. 15 to 16
o tweaked language to refer to "initial state" rather than "factory
default configuration", so as accommodate white-box scenarios.
o added a paragraph to Intro regarding how the solution primarily
regards physical machines, but could be extended to VMs by a
future document.
o added a pointer to the Workflow Overview section (recently moved
to the Appendix) to the Intro.
o added a note that, in order to simplify the verification process,
the "Zerotouch Information" PKCS #7 structure MUST also contain
the signing X.509 certificate.
o noted that the owner certificate's must either have no Key Usage
or the Key Usage must set the "digitalSignature" bit.
o noted that the owner certificate's subject and subjectAltName
values are not constrained.
o moved/consolidated some text from the Artifacts section down to
the Device Details section.
o tightened up some ambiguous language, for instance, by referring
to specific leaf names in the Voucher artifact.
o reverted a previously overzealous s/unique-id/serial-number/
change.
o modified language for when ZTP runs from when factory-default
config is running to when ZTP is configured, which the factory-
defaults should set .
D.18. 16 to 17
o Added an example for how to promote an untrusted connection to a
trusted connection.
o Added a "query parameters" section defining some parameters
enabling scenarios raised in last call.
o Added a "Disclosing Information to Untrusted Servers" section to
the Security Considerations.
Watsen, et al. Expires March 9, 2019 [Page 84]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
D.19. 17 to 18
o Added Security Considerations for each YANG module.
o Reverted back to the device always sending its DevID cert.
o Moved data tree to "get-bootstrapping-data" RPC.
o Moved the "update-progress" action to a "report-progress" RPC.
o Added an "untrusted-connection" parameter to "get-bootstrapping-
data" RPC.
o Added the "ietf-zerotouch-device" module.
o Lots of small updates.
D.20. 18 to 19
o Fixed "must" expressions, by converting "choice" to a "list" of
"image-verification", each of which now points to a base identity
called "hash-algorithm". There's just one algorithm currently
defined (sha-256). Wish there was a standard crypto module that
could identify such identities.
D.21. 19 to 20
o Now references I-D.ietf-netmod-yang-tree-diagrams.
o Fixed tree-diagrams in Section 2 to always reflect current YANG
(now they are now dynamically generated).
o The "redirect-information" container's "trust-anchor" is now a CMS
structure that can contain a chain of certificates, rather than a
single certificate.
o The "onboarding-information" container's support for image
verification reworked to be extensible.
o Added a reference to the "Device Details" section to the new
example-zerotouch-device module.
o Clarified that the device must always pass its IDevID certificate,
even for untrusted bootstrap servers.
o Fixed the description statement for the "script" typedef to refer
to the [pre/post]-script-[warning/error] enums, rather than the
legacy script-[warning/error] enums.
Watsen, et al. Expires March 9, 2019 [Page 85]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
o For the get-bootstrapping-data RPC's input, removed the "remote-
id" and "circuit-id" fields, and added a "hw-model" field.
o Improved DHCP error handling text.
o Added MUST requirement for DHCPv6 client and server implementing
[RFC3396] to handle URI lists longer than 255 octets.
o Changed the "configuration" value in onboarding-information to be
type "binary" instead of "anydata".
o Moved everything from PKCS#7 to CMS (this shows up as a big
change).
o Added the early code point allocation assignments for the DHCP
Options in the IANA Considerations section, and updated the RFC
Editor note accordingly.
o Added RFC Editor request to replace the assigned values for the
CMS content types.
o Relaxed auth requirements from device needing to always send
IDevID cert to device needing to always send authentication
credentials, as this better matches what RFC 8040 Section 2.5
says.
o Moved normative module "ietf-zerotouch-device" to non-normative
module "example-zerotouch-device".
o Updated Title, Abstract, and Introduction per discussion on list.
D.22. 20 to 21
o Now any of the three artifact can be encrypted.
o Fixed some line-too-long issues.
D.23. 21 to 22
o Removed specifics around how scripts indicate warnings or errors
and how scripts emit output.
o Moved the Zero Touch Device Data Model section to the Appendix.
o Modified the YANG module in the Zero Touch Device Data Model
section to reflect the latest trust-anchors and keystore drafts.
Watsen, et al. Expires March 9, 2019 [Page 86]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
o Modified types in other YANG modules to more closely emulate what
is in draft-ietf-netconf-crypto-types.
D.24. 22 to 23
o Rewrote section 5.6 (processing onboboarding information) to be
clearer about error handling and retained state. Specifically:
* Clarified that a script, upon having an error, must gracefully
exit, cleaning up any state that might hinder subsequent
executions.
* Added ability for scripts to be executed again with a flag
enabling them to clean up state from a previous execution.
* Clarified that the conifguration commit is atomic.
* Clarified that any error encountered after committing the
configuration (e.g., in the "post-configuration-script") must
rollback the configuration to the previous configuration.
* Clarified that failure to successfully deliver the "bootstrap-
initiated" and "bootstrap-complete" progress types must be
treated as an error.
* Clarified that "return to bootstrapping sequence" is to be
interpreted in the recursive context. Meaning that the device
rolls-back one loop, rather than start over from scratch.
o Changed how a device verifies a boot-image from just "MUST match
one of the supplied fingerprints" to also allow for the
verification to use an cryptographic signature embedded into the
image itself.
o Added more "progress-type" enums for visibility reasons, enabling
more strongly-typed debug information to be sent to the bootstrap
server.
o Added Security Considerations based on early SecDir review.
o Added recommendation for device to send warning if the initial
config does not disable the bootstrapping process.
D.25. 23 to 24
o Follow-ups from SecDir and Shepherd.
o Added "boot-image-complete" enumeration.
Watsen, et al. Expires March 9, 2019 [Page 87]
Internet-Draft Secure Zero Touch Provisioning (SZTP) September 2018
Acknowledgements
The authors would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Michael Behringer,
Dean Bogdanovic, Martin Bjorklund, Joe Clarke, Toerless Eckert,
Stephen Farrell, Stephen Hanna, Wes Hardaker, David Harrington, Radek
Krejci, David Mandelberg, Russ Mundy, Reinaldo Penno, Randy Presuhn,
Max Pritikin, Michael Richardson, Phil Shafer, Juergen Schoenwaelder.
Special thanks goes to Steve Hanna, Russ Mundy, and Wes Hardaker for
brainstorming the original I-D's solution during the IETF 87 meeting
in Berlin.
Authors' Addresses
Kent Watsen
Juniper Networks
EMail: kwatsen@juniper.net
Mikael Abrahamsson
T-Systems
EMail: mikael.abrahamsson@t-systems.se
Ian Farrer
Deutsche Telekom AG
EMail: ian.farrer@telekom.de
Watsen, et al. Expires March 9, 2019 [Page 88]