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

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Sep 2019 14:25:47 -0400

{clearing out todo items in my inbox}

Joel M. Halpern <[email-masked]> 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.

    > Have I got the wrong end of the stick?

Joel, you have gotten the resale problem exactly correct.

BRSKI is primarily a protocol for a buyer, who does not wish to be forced
to assert physical possession, to assert ownership of the device.

The #1 reason why they don't want to resort to physical means is that the
local entities possessing ("remote hands") the device don't have the skills
and/or equipment to set the device up.

The #2 reason is that the device is in partial public access, and
it would be a bad thing if the physical possession interface was too easily
accessed. (Bank ATM, Airport checkin kiosk, hotel room interfaces, etc.)
This has been extended to IoT devices.

A third reason is that the devices may be difficult to actually reach
physically due to the structure and activity of the factory/plant/etc. that
they are in.  A temperature sensor 50m up a distillation tower in a refinery,
for instance.

The physical mechanisms that make the device hard to physically attack may
also make it hard for the second owner to take control of the device without
the cooperation of the first owners and/or manufacturer.

The current solution in the document is that one should, for enterprise/ISP
equipment that ANIMA applies to, continue to provide the same onboarding
processes that existed prior to ANIMA.  Specifically, a "craft" or serial console.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Sep 2019 14:49:35 -0400

Adam, Alexey,
  version -28 of the document contains a CDDL definiton for the audit-log
  response.

https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-27&url2=draft-ietf-anima-bootstrapping-keyinfra-28

I hope that I'm done now!

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Sep 2019 15:39:33 +0200

> On 16 Jul 2019, at 21:29, Barry Leiba <[email-masked]> wrote:
> 
>>> I would personally not suggest using IRIs here, given that the scheme
>>> (https) is expected to retrieve a resource at a well-known location and
>>> thus will always have to be mapped to a URI to do the retrieval (rather
>>> than used in a string comparison or something similar) .  RFC 5280,
>>> which this cites, actually goes through the steps pretty well, and I
>>> think the complexity there demonstrates the advantage for constrained
>>> devices of always using the URI form.
>> 
>> I have changed the references from IRI to URL, and the components from
>> iauthority to 'authority'.
> 
> I think the best thing for IETF documents is to use "URI" (rather than
> "URL"), and to cite RFC 3986.

And that really is what this is: it’s a URI.  Call them RESTful calls or call them something else but they look and smell quite RESTful to me, and REST requires URIs, and 3986 is a great reference.

Eliot

> 
> The W3C, via the WHATWG, is (re-)defining "URL", and we *could* cite
> that work.  That would not be my preference here.
> 
> Barry
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima