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

Toerless Eckert <tte@cs.fau.de> Thu, 11 July 2019 14:33 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 8F2CC120180; Thu, 11 Jul 2019 07:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Level:
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 cNDipXdl-CX4; Thu, 11 Jul 2019 07:33:24 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ADB12014F; Thu, 11 Jul 2019 07:33:24 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D368F54807D; Thu, 11 Jul 2019 16:33:19 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id C4699440041; Thu, 11 Jul 2019 16:33:19 +0200 (CEST)
Date: Thu, 11 Jul 2019 16:33:19 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Alissa Cooper <alissa@cooperw.in>
Cc: The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, anima@ietf.org
Message-ID: <20190711143319.vzt3zfsooi72f6jb@faui48f.informatik.uni-erlangen.de>
References: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <156279135063.15552.18154602951583265728.idtracker@ietfa.amsl.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/I_7qjJIqS5FqJthaMDlNsiNwuhE>
Subject: Re: [Anima] Alissa Cooper'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: Thu, 11 Jul 2019 14:33:28 -0000

On Wed, Jul 10, 2019 at 01:42:30PM -0700, Alissa Cooper via Datatracker wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I apologize if I'm misunderstanding how this works, but I didn't see much
> discussion in the document about the implications of the manufacturer going out
> of business. Specifically, it seems like if a device ships with BRSKI as its
> only available mechanism for bootstrapping and the manufacturer goes out of
> business before the device is enrolled, the ability for the device to function
> securely on the network may be significantly impaired if not impossible. It
> seems like this document needs to make clear to manufacturers that a fallback
> manual enrollment mechanism of some sort needs to be implemented along with
> BRSKI in order to avoid this situation.

Alissa,

This is not a BRSKI specific issue/question. This is a question that
equally applies to system design across pledge/client, server/registrar
and masa when using Netconf Zerotouch (RFC8572). Or any
other protocol relying on the RFC8366 voucher security architecture.

In fact, BRSKI already answers a lot more system design issues in
section 7 than RFC8572 does and RFC8572 did (appropriately) make it through
to RFC without these system design options being elaborated on in that RFC.

I consider all the system design aspects already covered in BRSKI to
be somewhat opportunistic by now. In hindsight we could have a much shorter
BRSKI protocol spec and a more comprehensive voucher architecture
document applicable to netconf/BRSKI and other protocols (that leverage
vouchers), but we didn't knew this when we started, and then it was too late.
And of course WG reviewers kep hammering to answer questions ;-)

So, to the extend that authors have not already spent cycles to write
up things in BRSKI that really are not specific to BRSKI (such as section 7),
i would appreciate if we would put put generic voucher security architecture
option discussions into followup work written in a way that its
understood how to apply to BRSKI, Netconf and any other (future) protocols.

Btw: 

Primarily, as a customer i do not worry about the problem, because i want to use
BRSKI to AVOID having to buy and store equipment. The typical use case
is to do just-in-time-order of equipment shipped to insecure deployment
location. If at all, its an issue of the reseller if the reseller wants to buy
bulk, store and sell potentially years later. Something no sane reseller
does these days with electronics equipment that quickly deteriorates in
value. 

Now, when i need to (factory) reset a device years later i might run into the
issue, and there are various solutions, but the best way for IETF to
deal with this would be to have appropriate trust storage YANG models
that express behaviour for such system reset or other operational device
procedures.

> = Section 1.3.1 =
> 
> "But this solution is not exclusive to large equipment: it is intended
>    to scale to thousands of devices located in hostile environments,
>    such as ISP provided CPE devices which are drop-shipped to the end
>    user."
> 
> I don't quite understand how this squares with the scope limitation described
> in Section 1 and Section 9. If the whole network is professionally managed by
> the ISP, what part would be the "hostile environment"?

https://media04.kreiszeitung-wochenblatt.de/article/2017/10/24/8/277508_L.jpg?1554098709

(obviously BRSKI doesn't help against the explosives, that part of the
 picture is just for fun, but there are more subtle physical attack vectors
 against these physcially badly secured locations where BRSKI helps. And
 beside ATMs there are a lot more even less well protected retail
 locations with small routers in them connecting to corporate networks).

I'll not answer to your discuss individually (leave it to the authors),
but would like to mention that a coupe of your asks also relate to the
"not BRSKI specific" or "better for a "BRSKI operations" document than
further bloating the protocol spec.

Cheers
    Toerless

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I think this document would benefit from two concise lists, with notes about
> which items in each list are defined in this document and which ones are not
> defined: (1) what is operationally required of a manufacturer to support BRSKI,
> and (2) what is operationally required of a domain owner to support BRSKI.
> 
> = Section 2.3.1 =
> 
> What precisely is meant by "TPM identification"? Could a citation be provided?
> 
> = Section 10.1 =
> 
> "The domain can maintain some privacy since it has not necessarily been
>    authenticated and is not authoritatively bound to the supply chain."
> 
> What does this mean? That the domain can expect the manufacturer not to trust
> the domainID because it hasn't been authenticated?
> 
> = Section 10.2 =
> 
> "The above situation is to be distinguished from a residential/
>    individual person who registers a device from a manufacturer: that an
>    enterprise/ISP purchases routing products is hardly worth mentioning.
>    Deviations would, however, be notable."
> 
> What does the last sentence mean?