Subject: Re: [Netconf] zerotouch issues and fixes

From: Kent Watsen <[email-masked]>
Date: Mon, 2 Mar 2015 14:38:17 +0000

The cut-off date for draft-submissions is in 7 days.  I was hoping to get
some feedback before editing this draft.  Does anyone like the fixes
discussed below?

Thanks,
Kent

On 2/23/15, 5:32 PM, "Kent Watsen" <[email-masked]> wrote:

>
>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
>
>
>
>
>
>
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf