Hi Joel,
> On 16 Jul 2019, at 14:59, Joel Halpern Direct <[email protected]> > wrote: > > I am having trouble connecting your reply with my request. > Let's take the direct issue first, and then the analogy. > > I had suggested a specific enhancement to device behavior. The response was > "but that removes the theft protection." It is that form of theft protection > that I am objecting to. As far as I can tell, the mechanism I suggested does > not break zero touch. It allows someone who controls their network, and who > physically controls a new device, to put that new device in their network > without asking anyone's permission. > It does not permit someone with a device, but not network control, from > adding that device to the network. It does not permit someone with control > of the network, but not physical access to the device, to achieve anything > special. So it seems compatible with the goals. My apologies I took your statement as something more general than you intended. With respect to this from earlier: > I have assumed that what we needed is the ability for a buyer, who has > physical possession of the device, and possibly some simple (non > cryptographic) credentials provided by the seller to force the device to > reset what it thinks it is part of, and to emit in some accessible form the > information the buyer needs to be able to make this device part of his > network, using his authentication servers, etc. That was indeed what we discussed. We just got into means a bit more than perhaps necessary. I’ll point out that it’s always going to be a manufacturer call on how best to do this; and how to transport credentials, and how to keep them safe, even. > > In terms of the analogy, I would have problem with IEtF defining a new > protocol that added significant risk to the buyer when they buy from new > vendors. > And existing vendors do go out of businesses. And vendors do end-of-life > products. (You can't get a new key to your car because the vendor has > stopped supporting that model???) I wouldn’t implement a 1:1 mapping products->MASA server function. That seems excessive. And rare is the case when a vendor EOLs a product and then cripples it through an update mechanism. The only issue here is whether a database entry would stay around. > > Now it may be that the particular approach I suggested won't work. But it > seems to me that there needs to be a way for folks to keep using, and to keep > re-selling, devices without the support of the vendor. That usage may not > get all the zero-touch advantages that supported re-sale would get. But it > has to work. And putting the onus for that on the original vendor does NOT > seem an effective solution. I think you mean, “requiring the vendor to stay around for ever doesn’t seem like an effective solution.” Again, I don’t want to overgeneralize. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
