Re: [Anima-bootstrap] ownership vouchers?

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

inline, 

> On Apr 28, 2016, at 2:36 PM, Kent Watsen <[e-mail]> wrote:
> 
> 
> 
> 
> 
> 
> On 4/26/16, 2:51 PM, "Max Pritikin (pritikin)" <[e-mail]> wrote:
> 
>>> 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.
> 
> But it seems from below you do get it...   :)
> 
> 
>> 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.
> 
> Right, but if there were a standard format for Ownership Voucher, the need to pass Vendor Class Identifier for DHCP, or the equivalent (if there were one) for DNS, disappears.  This is my point for why the NETCONF Zero Touch draft might like to see the Ownership Voucher standardized (answering Michael's original question).  Of course, there is the additional reason that we haven't started discussing yet, which is that a standardized format could be shared by the ANIMA draft...
> 
> 
>> 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?
> 
> It's a "fallback" only in the context below.  From a draft perspective, they're just options on equal footing; implementations can decide which they want to use.
> 
> Off topic: what happened to the 'R' in BSKI?  I really liked the idea of calling it brewski  ;)

We all agree ‘brewski’ is the best name. But defining the ‘BRSKI’ backronym never really happened. Not too late to change it… :)

>> 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?
> 
> It knows because of the URL the device uses, when accessing the bootstrap server, encodes the device's serial number.  E.g., GET https://example.com/restconf/data/ietf-zerotouch-bootstrap-server:devices/device=123456.

This is of course not secured, but I understand that its just a hint and worse case is a DoS which was an option to the attacker anyway.

Any comment about the netconf s4.4 normative text rejecting the primary device authentication method of BrSKI? Is that a problem we should resolve?  

>>> 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. It's a hard call but I’d prefer to leak information about the new, untrusted, device rather than leaking information about my network.
> 
> Fair enough
> 
> 
> 
>>> 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.
> 
> Right.  The draft defines the option for completeness, but implementations may not use that option very often.

This option introduces a lot of complexity to the message format. Is it worth it?

- max

> 
> 
> Kent