Great thread you all. Some key points for response follow. Additionally we’re working through each numbered comment specifically.
Generally lets keep the scope of BRSKI in mind. It is a new protocol for bootstrapping via vouchers. It does not preclude the use of a local console for bootstrapping/asserting ownership. The current voucher format is a starting point and there is already work in progress for various additional forms of vouchers to address the other use cases brought up. Re: Can vouchers be distributed directly rather than through the BRSKI-MASA sub-protocol Vouchers are signed messages and there are a number of distribution models available. This protocol describes a predominately online model. The netconf zerotouch draft describes a different method using the same vouchers with slightly different operational trade-offs. The intention is that between these a good foundation is set for all use cases (with a focus on anima and netconf; where these documents were working group items). As described below the current method and current BRSKI flow work with direct distribution as envisioned by some of the discussion on this thread (e.g. no MASA) but that is not a primary use case. The existing work on more constrained voucher formats could help to enable those ideas a more direct use cases but will not require BRSKI protocol exchanges to change. Re: Does BRSKI change the ownership model from the owner to the manufacturer? Absolutely not. BRSKI defines a scalable method of bootstrapping remote secure key infrastructures via the distribution of “vouchers” from the registrar to the device. It specifically attempts to ensure the registrar (owner) is in control of decisions and attempts to minimize supply chain integrations (e.g. how much the vendor even knows about who actually owns a device). The structure is such that a 3rd party could provide all the Manufacturer Authorized Signing Authority (MASA) responsibilities — thus enabling complete vendor independence from a BRSKI protocol perspective. It specifically supports models wherein the voucher is distributed in advance, on a 2d barcode or in sales material or whatever. There is no expectation of a secure connection between the device and the vendor (beyond an expectation that vouchers are signed). The goal here is to allow the vendor to help provide a scalable deployment model. Re: What about transfer of ownership; particularly if the MASA is antagonistic to resale? Because there is no expectation of sales-channel integration this is really limited to discussions of antagonistic vendors. I applaud purchasing decisions to avoid such vendors. Such vendors are only able to reject zero touch deployment — they can’t effect customers that use less scalable deployment models such as console access. All vendors have the option of leveraging security technologies to make resale difficult... the existence of BRSKI only exposes such attempts in the same way the signed image loading highlights similar attempts to avoid 3rd party code. As per the basic trust model the registrar can even provide the new owner 90% of the functionality even in the face of an antagonistic MASA: The owner can obtain a nonce-less voucher against a device specific registrar keypair. This then provides them a permanent method of bootstrapping the device that they can safely provide with the device during resale. This maintains the majority value of the protocol to the new owner while completely circumventing any future antagonism by the vendor. The device can be reset to factory defaults before the sale. Re: What happens if the MASA service is unavailable? BRSKI is for the transfer of trust to the current owner. There is no effect to deployed devices. As discussed in this thread there are facilities for nonce-less permanent vouchers including ones that can be used for resale. An owner that is worried about re-deploying in the future state can take this approach. Either using a common registrar or by using a registrar per device (depending on if they plan to resale). There will always be cases where a vendor goes away and a device is therefore limited. For example security updates to signed firmware can be impacted if the vendor no longer produces them. BRSKI does make this reality worse. - max On Oct 2, 2018, at 7:06 PM, Uri Blumenthal <[email protected]<mailto:[email protected]>> wrote: Based on this exchange, and the arguments presented here that I observed so far, I'm with Randy. I have not seen adequate answers to his concerns (which IMHO are reasonable). P.S. Feel free to trim the CC: list when/if responding. P.P.S. In one of my prior incarnations many years ago, we designed a somewhat similar system, and called it "Zero-Touch Provisioning". It was a very big company, so we did not consider the possibility of it/us going out of business (and leaving the customers stranded). But if Randy's arguments were presented to our team then, we'd probably accepted them and tried to address... Sent from my test iPhone On Oct 2, 2018, at 20:53, Randy Bush <[email protected]<mailto:[email protected]>> wrote: I think it's been thought through but badly articulated. In that sense, the Last Call is doing its job. does that mean that i can stop trying for a narten medal, go back to work, and christian will wake me up again when my two scenarios have clear answers; one hopes ones with which i can live? also, please tell me that i do not need to stick my nose into the rest of anima in order to let the user unequivocally own what they buy. i have my own rabbit holes to pursue in the ietf. randy _______________________________________________ secdir mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview _______________________________________________ Anima mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
