Up-levelling the topic a little bit: It seems to me that from the amount of interest and discussion, BRSKI is going to be quite important (or a resounding failure, in which case this is all beside the point). Assuming it's a success, there will inevitably be updates and enhancements.
So, I'd prefer that we don't try to solve all problems now. I'd rather get the first version to Proposed Standard next week... Regards Brian Carpenter On 17-Jul-19 01:57, Joel M. Halpern wrote: > I can't tell from this whether you agree that it is reasonable to put in > some mechanism to address this issue? > > Yours, > Joel > > On 7/16/2019 9:40 AM, Eliot Lear wrote: >> 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 >> > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
