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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 16 July 2019 19:35 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2664E12011B; Tue, 16 Jul 2019 12:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiO5hKIXoBVT; Tue, 16 Jul 2019 12:35:37 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBBC120114; Tue, 16 Jul 2019 12:35:36 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 5FA3B3808A; Tue, 16 Jul 2019 15:35:31 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1FBBFB52; Tue, 16 Jul 2019 15:35:34 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Adam Roach <adam@nostrum.com>
cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Eliot Lear <lear@cisco.com>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, anima-chairs@ietf.org, The IESG <iesg@ietf.org>, Toerless Eckert <tte+ietf@cs.fau.de>, anima@ietf.org
In-Reply-To: <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com>
References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <ACEB4033-707F-47AF-B58A-5227B444BEAB@cisco.com> <E2DA8D30-805E-478D-925D-534C04A0727F@cisco.com> <8869.1563140002@dooku.sandelman.ca> <cedc515e-22ab-94a9-e6ef-c55b345687ba@joelhalpern.com> <376eee31-0264-38a8-1d32-901bb1a0671b@gmail.com> <9e341730-dc47-8860-47d4-6421ab04d0dc@nostrum.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 16 Jul 2019 15:35:34 -0400
Message-ID: <2025.1563305734@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/3uKcnbv7ez2G0bGw-BH8-u2ejjI>
Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 19:35:39 -0000

Adam Roach <adam@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   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [