Subject: Re: [Netconf] send 'version' in zerotouch url?

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Aug 2017 18:56:16 +0000

[Note: this issue is blocking the posting of an updated zerotouch draft, which would then be ready for a (presumably) final Last Call]

Second try  ;)

The issue regards when a device learns of a bootstrap server's address/port via an insecure mechanism (e.g., DHCP or a DNS record).  As such, the device will not have a trust-anchor certificate to authenticate the bootstrap server's TLS certificate with.  For such cases, the draft allows the device to establish the TLS connection with the bootstrap server anyways (e.g., by blindly accepting the server's certificate).  However, the concern is that the bootstrap server may "owned" by an attacker...

To safeguard against this scenario, the draft (1) says that the device MUST verify (via a signature) any data it obtains from the [untrusted] bootstrap server and (2) takes steps to limit the amount of data the device sends to the [untrusted] bootstrap server.  

Currently, the draft has robust support for goal #1 and partial support for goal #2.  For goal #1, the draft defines a signed-data solution (owner certificates, ownership vouchers, etc.).  For goal #2, the draft prevents the device from sending its IDevID certificate or POST-ing its 'update-progress' notifications when connected to untrusted servers, even though it inconsistently requires the device send its "unique-id" and now, maybe, per the subject line, its "version".  The question is, do we want to adhere to goal #2 or not.

What does adhering to goal #2 look like?  - we need to state that the "unique-id" and "version" (if we go for it) values in the URL are munged via a salted hashing algorithm (salt to prevent dictionary attacks).  Again, the *current* definition of "unique-id" has enough wiggle-room to enable vendors to hash these values if they want, but do we want to make it mandatory to be consistent?

What does NOT adhering to goal #2 look it? - I think that we say that devices MUST always send their IDevID certificate - this doesn't hurt (since the IDevID certificate doesn't contain much beyond serial number) while actually helping to prevent MiTM attacks (since a spoofed bootstrap server wouldn't know the device's IDevID private key).  But I'm conflicted if devices should send their progress updates to untrusted bootstrap servers, since the progress updates contain data above and beyond what devices would otherwise provide.  To address this, we might state that it's okay for devices to send progress updates to untrusted servers if and only if they are first able to verify the signature over the signed data, since that somewhat demonstrates the bootstrap server's authenticity.

Thoughts?

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Aug 2017 16:25:45 +0000

Another follow-up on this thread, regarding also defining a 'os-name' query param.

Both Radek and Dean raised a point about white-boxes on top of which software is installed to give it a personality.  For instance, a generic white-box might be a vendor-x router, or a vendor-y firewall, or a vendor-z switch.   This means is that the white-box's serial-number alone doesn't uniquely identify the device or, more specifically, what configuration to send it.  Of course, an inventory-tracking system should know which software was installed, but doing so isn't convenient.  Better would be to have a query parameter called something like "os-name" to indicate what software is install. Thoughts?

A related consideration to this regards the IDevID certificate.  In the case of a white-box, the IDevID certificate would presumably be set by the white-box manufacturer.  This isn't a problem, per se, as the bootstrap-server can also trust the white-box manufacturer's trust anchor cert, and thus still be assured that it's connected to the actual device.  However, it might be desirable if, at the time of installing software on the white-box, an LDevID certificate is configured and used instead.  There's no security issue here, the only issue is that the draft current only supports IDevID certs (a minor tweak is needed).  Any comments on this?

Thanks,
Kent