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

With the mandates that Michael proposed adding, I can live with 
advancing the document.
Yours,
Joel

On 7/16/2019 4:31 PM, Brian E Carpenter wrote:
> 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 <jmh.direct@joelhalpern.com> 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
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>>
> 