Adam Roach <a...@nostrum.com> 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.

I mostly agree!

While a great deal of the ACP use case deals with physically large devices
which are in datacenters, in locked cages, there are aspects where we are
dealing with devices in significantly more vulnerable places.  This ranges
From FTTN equipment in a box on a nearby curb, to ISP owned CPE devices
physically in people's homes [%].

But, the more vulnerable devices are also of lower dollar value.
We are mandating vendors to provide *A* way, but that doesn't have to
be an enable prompt with no password.
There could be a one-time-password on the port. 
S/Key would fine given the initial seed provided in the packaging.

draft-wkumari-opsawg-sdi would also work, the initial configuration could
include "est-enroll [2001:db8:0:1]:443".

[%] the CPE CMTS use case is the domain of TR-069. I don't know what DSL
providers do, some have service PPPoE username/password that they use.

Let other use cases write different requirements for access.

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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to