Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Joel Halpern Direct <[e-mail]>]

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.

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???)

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.

Yours,
Joel

On 7/16/2019 7:21 AM, Eliot Lear wrote:
> Hi Joel,
> 
>> On 15 Jul 2019, at 23:42, Joel M. Halpern <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> I would probably go a step further than Adam.  Protecting the device 
>> so a thief can not use it in the thiefs' own network seems to me to be 
>> something that we should not be trying to achieve.  An active 
>> non-goal. It is not our problem.
> 
>>  And trying to achieve it has the implications that lead to this whole 
>> discussion about the original manufacturer controlling who can resell 
>> / re-buy the device.
> 
> I would rather we redressed this directly.  There is an entire work flow 
> that involves zero-touch provisioning that at least two, and likely four 
> large platforms are driving toward, that *all* require some sort of 
> manufacturer assertion for device ownership to be transferred.  This is 
> not just a good idea or an anti-theft mechanism, but an aspect that is 
> required for zero-touch, particularly with wireless, where network 
> selection has to occur.  While in that sense, you might say, “Anti-theft 
> wasn’t the goal”, it is certainly a nice add-on, and it seems like a 
> valuable function.
> 
> Personally I *like* that we had this discussion.  I think the BRSKI work 
> will be much improved because of it, and people have a better 
> understanding of how the mechanisms can be used/abused as a result.  I 
> only wish we had had it earlier.
> 
> So now let’s talk about anti-theft and counterfeiting.  BRSKI has an 
> interesting link to both.  If a manufacturer is able to show the 
> customer what devices have been registered, any device that seems to be 
> operational but is NOT registered has to be considered suspect by the 
> customer.  That’s a nice counterfeit protection, and it isn’t there by 
> accident.
> 
> Similarly having a way to say, “the thing won’t join an unauthorized 
> network” is a very strong theft deterrent, very much akin to the 
> electronic keys that we see now in cars.  You generally can no longer go 
> to the local locksmith to get a duplicate key for a great many cars, but 
> your theft insurance has dropped through the floor (particularly if you 
> own a Honda).  Might GM, Ford, BMW etc might fail?  Sure.  No more new 
> keys for those cars: the old ones had better suffice.
> 
> In this case we discussed several approaches to deal with the case where 
> the supplier drops dead.  IMHO that’s a good outcome.
> 
> Eliot
> 
> 
> 
> 
>>  While manufacturers may like that, it does not seem to be something 
>> we should get involved in. At all.
>>
>> Yours,
>> Joel
>>
>> On 7/15/2019 5:10 PM, Adam Roach wrote:
>>> On 7/15/19 3:38 PM, Brian E Carpenter wrote:
>>>> On 15-Jul-19 16:45, Joel M. Halpern wrote:
>>>>> I presume I am missing something basic.
>>>>> I have tried to follow this discussion, as it seems to be about a
>>>>> critical aspect of whether the BRSKI work is acceptable.
>>>>>
>>>>> 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.
>>>> Yes, but *not* a solution that works if the device is stolen.
>>> I'm actually a little ambivalent with respect to this use case. For 
>>> the kind of devices that the document purports to be targeting, I 
>>> would imagine that theft is in the range of parts-per-thousand (or 
>>> lower) as compared to things like post-bankruptcy liquidation. If you 
>>> can fix the first without ruining the second, great.
>>> /a
>