Randy Armstrong (OPC) <randy.armstr...@opcfoundation.org> wrote:
> 1) As it stands today BRSKI is pull model only and the push model is
> out of scope but I don't see why that has to be the case once you allow
> for different protocols between the Device and the Registrar. With our
> proposed OPC mapping we would define a Registrar that supports both
> models. Is this of any interest to the IETF or would it be an OPC only
> thing?There are a number of reasons to think a push model is also workable. I'm unclear if OPC needs to onboard devices into a wireless network or if everything is wired. This matters because the new device has to announce its presence to the Registrar for push to work. For instance, you could take a look at: https://tools.ietf.org/html/draft-richardson-6tisch-dtsecurity-secure-join-01 which is an old version of the constrained-BRSKI mechanism. Section 3, (3.2) explains how the Registrar would reach out to the Pledge using the 6tisch 6p protocol (when it ran over IPv6). > 2) Perhaps the most value from BRSKI comes not from the MASA per se but > the voucher format (i.e. a digitally signed document with a standard > format). We could meet a lot of our requirements if we had a voucher > which has a list of nonce-less or bearer vouchers shipped to a > particular location for use by a particular end user. We could create > workflows where the manufacturer/distributor has to create this > document when devices are delivered. The document could be delivered > via the MASA or via some other B2B exchange or even on a USB > stick. However it is delivered it can then be read by the Registrar and > use it to build a whitelist of Devices allowed on the network. RFC 8572 -- Secure Zero Touch Provisioning (SZTP) may suit you better. It also uses RFC8366 vouchers. > I am also thinking that this voucher would be a good application for > block chain where instead of a bearer voucher we define a mechanism > where the owner the device could append a "block" to the original > voucher which authorizes the transfer to new owner. We considered distributed ledgers for the audit log. In all distributed ledgers, you have to ask: 1) are there mutually distrusting parties? 2) what do they need to agree upon? 3) what is the incentive for a third party to validate the chain? What you have described above, however, is just a certificate chain. No Block Required. https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00 Describes an early notion of how vouchers work, and notice how it delegates at each step. Subsequent sales just extend the chain. We didn't go this way because: 1) it mandates sales channel integration, and we think that this will be rare at the beginning. 2) any party in the chain can issue a new sale certificate, effectively stealing the device from the current owner. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
