Subject: [Netconf] zerotouch issues and fixes

From: Kent Watsen <[email-masked]>
Date: Mon, 23 Feb 2015 22:32:07 +0000

Now that the call-home and server-model drafts have no more planned
updates before entering Last Call, I'm ready to focus on the zerotouch
draft again.  The good news is that I've been thinking about some issues
with the current draft and already have a proposal for how to fix them.
The issues I'm thinking about are:

1) Loss of privacy as NMS admins need to interact with 3rd-party signing
servers in order to get their Configlets signed.

2) Complexity in how 3rd-party signing server would be able to know who
owns which devices, the burden of its role.

3) Loss of flexibility as a Configlet has to encode the device identifiers
for the devices allowed to load it.

The proposal to fix the above issues is to replace the concept of a
3rd-party Signing Authority with 1) NMSs can sign their own configurations
with a Vendor-certified key and 2) Devices use a Vendor-provided ³voucher²
to authenticate NMSs.  Stepping through this in detail, we have the
following artifacts:

NMS Certificate:
  * the first time NMS wants to enroll in Vendor's ZeroTouch program:
    * NMS generates a private key
    * NMS generates a certificate signing request (CSR)
    * NMS sends to Vendor its CSR
    * Vendor signs the CSR, filling in an "Owner ID" value
    * Vendor signs the CSR with Vendor private key
    * Vendor sends to NMS the resulting NMS Certificate

Device-Owner Voucher:
  * at any time, Vendor can generate a Voucher that:
     * encodes an "Owner ID" (see NMS Certificate above)
     * encodes one or more device identifiers (e.g., serial-number)
     * encodes an expiration time (e.g. months, years, forever)
     * signed by Vendor private key

Configuration:
  * when NMS ready to stage ZeroTouch configuration:
     * NMS generates configuration
     * NMS signs configuration with private key
     * NMS places onto Configuration Server all of the following:
        1) signed Configuration
        2) Device-Owner Voucher
        3) NMS Certificate

With this setup, the device's boot up procedure is roughly:
  * download the 3 artifacts from Configuration Server
  * process the Device-Owner Voucher:
     * verify that it was signed by Vendor private key
     * verify that its device-identifier is listed
     * extract the encoded Owner ID
  * process the NMS Certificate:
     * verify that it was signed by Vendor private key
     * verify that the Owner ID is same as extracted from Voucher
     * extract NMS public key
  * process the signed Configuration
     * verify that it was signed by the NMS private key
     * commit configuration into running datastore

Please assume everything else in zerotouch-01 draft would remain the same.
 Note how this solution fixes all the above listed issues: 1) NMS admins
now signed their own configurations, 2) Vendors now only need to provide a
Voucher, 3) Configurations no longer has to encode which devices their for.

As a design consideration, note that all the zerotouch proposals emphasize
the use of static artifacts over protocol.  This is so the artifacts can
optionally be loaded from alternate sources (i.e. USB drive, over an L2
protocol, over a non-IP protocol, etc.).

So, what do you think?  - I'd like to get some feedback before posting a
-02 draft!

Thanks,
Kent