Subject: Re: [Netconf] zerotouch issues and fixes

From: Joe Clarke <[email-masked]>
Date: Mon, 02 Mar 2015 10:08:10 -0500

On 2/23/15 5:32 PM, Kent Watsen 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!

I think this approach is reasonable.  The interaction with the vendor is 
minimal (only to claim the device-IDs and get the voucher).  Though, the 
time-to-live of the voucher needs to be accounted for by the device.  It 
needs to confirm the voucher is still "alive."  Would it make sense to 
have a per-device TTL in the voucher?

I also think there needs to be a way for the NMS to request an owner ID. 
  The reason for this is what happens if I have to replace the NMS.  I 
would need a new private key and a new CSR.  While I could get a new 
voucher with the new owner ID, this would likely be more of a hassle as 
the vendor will likely associate the devices with one owner ID.

Joe

---

From: Kent Watsen <[email-masked]>
Date: Mon, 2 Mar 2015 15:43:10 +0000

>minimal (only to claim the device-IDs and get the voucher).

Exactly, this solution optimizes for the vendor - it's very low-touch and
doesn't rely on a realtime lookup service.  But "reasonable" sounds
uncommitted - what we need to know is it's better - what do you think?

>Though, the 
>needs to confirm the voucher is still "alive."

Yes, there is a presumption that the device has an accurate clock.  Such
it is with PKI in general.  For instance, CRLs are only useful if they're
relatively fresh (a year-old CRL is not very useful).

>Would it make sense to

This would be doable.  As a voucher is a data file (not a X.509
certificate), for which we could define schema for, and thus it could take
any form we deem best.  That said, I question if it makes sense for a
vendor to issue a voucher with varying TTLs.  Is the vendor suppose to
know that some device's ownership is more volatile than others?  - or do
you see this as user-input?

>the vendor will likely associate the devices with one owner ID.

Yes, vendors would have to be able to reissue the NMS certificates.
Vendors could re-assign the same Owner ID the NMS had before or generate a
new one.  If a new Owner ID is generated, then the vendor would also need
to reissue Vouchers for devices that have not yet been claimed (e.g., gone
through the zerotouch process).

Thanks,
Kent

---

From: Joe Clarke <[email-masked]>
Date: Tue, 03 Mar 2015 11:15:31 -0500

> uncommitted - what we need to know is it's better - what do you think?

Sorry, didn't mean to sound noncommittal.  I like it.  I just think the 
questions I had raised need to be addressed (i.e., around Owner ID and 
verifying expiry on the device's part).

> relatively fresh (a year-old CRL is not very useful).

Of course.  It's just you didn't mention that in your rough 
walk-through.  That needs to be part of the process.

> you see this as user-input?

I see this as user input.  The use case I envision is that the owner 
might set a certain timeline for other devices to give a safety net to 
prevent old devices from bootstrapping.  It may not be common, and thus 
this could be a MAY.  It just offers flexibility.

> through the zerotouch process).

How do we state this in the draft?  I think it deserves a callout.  The 
Owner ID can't simply be a random thing, but needs to tie to the owner 
entity (yet still be unique between entities).  Can we say that the 
owner entity can suggest an Owner ID?

Joe

---

From: Kent Watsen <[email-masked]>
Date: Fri, 6 Mar 2015 18:31:01 +0000

OK, it seems that there is some support for this approach.  I'd plan to
post an updated draft that captures the idea more completely.  We can
always roll it back if needed...

Thanks,
Kent