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

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. That's why
Eliot's comment:

>> Many credentials are written on your wireless devices right now.

doesn't provide an acceptable answer, IMHO. (As it doesn't for
devices that are deployed where third parties might have physical
access to them.)

    Brian

> Have I got the wrong end of the stick?
> Joel
> 
> On 7/14/2019 5:33 PM, Michael Richardson wrote:
>>
>> Eliot Lear <lear@cisco.com> wrote:
>>      > Whether such a voucher would be pinned is something we do not have to
>>      > specify, with the risks of it not being pinned being born by the owner.
>>
>> I beg to differ!
>> I think that the security properties are vastly different.
>> It's why we decided when creating RFC8366 not to do bearer tokens.
>> We simply didn't think we were competent enough to specify it tightly enough
>> to not become a security disaster.
>>
>> An unpinned voucher is some kind of bearer token, and if disclosed has
>> significant operational risk.  As such, keeping it around/online is a serious
>> issue.
>>
>> A voucher pinned to the public part of a keypair whose private key is
>> kept offline (to be turned over to a new owner) is different because there
>> are potentially far fewer things to keep private.  Worse case, it's perhaps
>> the same, I would agree.
>>
>> The bigger problem is that I don't see a way to define such an artifact in a
>> timely fashion, nor do I know which WG we'd do it in.
>>
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
>>
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 