Re: [Anima-bootstrap] ownership vouchers?

["Max Pritikin (pritikin)" <[e-mail]>]

> On Apr 25, 2016, at 4:05 PM, Kent Watsen <[e-mail]> wrote:
> 
> [Changing subject line]
> 
> 
> 
> 
> On 4/18/16, 2:40 PM, "Michael Richardson" <[e-mail]> wrote:
> 
>> 
>> Kent Watsen <[e-mail]> wrote:
>>> Though I may not be a regular, I think that we could use a meeting or
>>> two to discuss how to modify the Ownership Voucher definition to suit
>>> ANIMA bootstrap.
>> 
>> I agree that this is an important thing to do.
>> Should we detail why this needs to be standardized?
> 
> 
> I have one reason outside of ANIMA, which is to enable multi-vendor devices to pull signed data from DNS-SD.  Specifically, look at the very last paragraph in Section 4.2 of the zerotouch draft (https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-08#section-4.2).
> 
> Let's says we have two devices, from two different vendors.  If they both do a DNS-SD lookup for say "_zerotouch._tcp.example.com", they'll both get the same signed data and, more to the point, the same ownership voucher.  While a single voucher can span many devices, unless standardized, it could never span more than one vendor.

I’m confused by this. 

The first paragraph of s4.2 indicates that "data provided using DNS-SD can only be redirect information (not bootstrap information)” so what we’re talking about is the normal DNS-SD service name to FQDN server name redirection? Because the device hasn’t been bootstrapped yet it can’t use DNS-SEC to secure this. We can’t even use the RFC6125 s6.5 SVR-ID work, again since we are not bootstrapped yet. 

There are two ways to proceed. We can either use message based protections around the redirection or we can use message based protections around the actual bootstrapping message. In the former case the DNS server needs to know the appropriate signed message format to respond with so it would need to know the type of device requesting the information. In s4.3 this is provided to a DHCP server, to address a similar problem, via "The device SHOULD again pass the Vendor Class Identifier (option 60) field in its DHCP lease request” but of course this isn’t secured for DHCP and doesn’t exist for DNS! I think we run into a rat hole of edge cases to deal with. The later case of course already exists.

Does it make more sense to proceed with a provisional attempt to obtain the bootstrapping information you describe as “fallback” below but which anima BSKI takes as the primary flow? 

Interestingly what Anima BSKI does there conflicts with s4.4 where it says that, "When
   the device connects to an untrusted bootstrap server, the device MUST
   NOT send its IDevID certificate in the form of a client certificate,
   and MUST NOT send any notifications to the bootstrap server, using
   the "notification" action defined in Section 7.4”. In this case how does the boostrap server know what type of device to respond to? 

> That said, we may want to extend to concept of a "voucher" to a "bundle of vouchers" as, even with a single vendor case, the vouchers may by issued over time such that a single voucher doesn't span all the devices in a network.  If there were support for bundles, all the vouchers within the bundle would have to have a common format, or else be tagged as to which [vendor-specific] format they're in.  This might be a way to not have to standardize vouchers, but it seems easier to have a single format.

I lean away from bundling because when you do so you’re leaking information about the network infrastructure. Its a hard call but I’d prefer to leak information about the new, untrusted, device rather than leaking information about my network. 

> I don't know how realistic it is that a single voucher would span all the devices in a domain at a given time, or how likely it is that anyone would configure their DNS server to return signed data.  On that latter point, it certainly seems like a lot of effort given that the fallback position is to 1) return unsigned data, 2) let the device establish a provisional TLS connection to the bootstrap server, from which 3) it downloads signed data, potentially with a device-specific voucher.

Yes, agreed. Plus if you have multiple vouchers each spanning different groups of devices then you have to select which voucher based on the client identity anyway. So I agree with where you’re thinking — to me the “fallback” is really the primary flow. 

- max 

> 
> Just thinking out loud here...
> 
> Kent
> 
> 
>