Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

"Max Pritikin (pritikin)" <pritikin@cisco.com> Fri, 05 October 2018 20:03 UTC

Return-Path: <pritikin@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753281274D0; Fri, 5 Oct 2018 13:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 iUl3qzESzRt6; Fri, 5 Oct 2018 13:03:08 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3171B126BED; Fri, 5 Oct 2018 13:03:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19586; q=dns/txt; s=iport; t=1538769788; x=1539979388; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tcTIQ3sROO5LNEj1gPk2H25pOHXfsf3JcO1xY8m+cfw=; b=c77b/ZnnRVE4t6T4t1oWnG1e1a9FD9cEud42ScA7hdzdX2BQl0JMd+DA 1PLzYbpq2xYgjW95WrVfkg+R7zajtezKdsCFnv3h/tiTqPb4EhHCrgR2t Rc44WSmXaMtoV7HjhmD+OI/jw21cMoDDGTCGnvYFPfirc+2wwL8cr8S58 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ALAAAhw7db/4UNJK1jDgsBAQEBAQEBAQEBAQEHAQEBAQEBgVIDAQEBAQELAYFbKmZ/KAqDapQ7gWiBHZAmhUAUgWYLAQEYAQqEA0YCF4QYITUMDQEDAQECAQECbRwMhToCAQMBASFLCxACAQg/AwICAiULFBECBAoEBYMhAYEdZA+kZYEuihmLMReCAIESJwwTghcHLoMbAQEDgTcQTYJLMYImAogzBzEWBYUDjwgOQwkChkqDEYRGgiMXgUxLhBqJQ4cFhRmJIQIRFIElHwI0gVVwFTsqAYJBCYIdFxFqAQyHUoUEOm+LeIEugR8BAQ
X-IronPort-AV: E=Sophos;i="5.54,345,1534809600"; d="scan'208,217";a="459035646"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Oct 2018 20:02:56 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w95K2uWX016804 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Oct 2018 20:02:56 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 5 Oct 2018 15:02:55 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1395.000; Fri, 5 Oct 2018 15:02:55 -0500
From: "Max Pritikin (pritikin)" <pritikin@cisco.com>
To: Uri Blumenthal <uri@mit.edu>
CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, "randy@psg.com" <randy@psg.com>, Eliot Lear <lear@cisco.com>, "anima@ietf.org" <anima@ietf.org>, Security Directorate <secdir@ietf.org>
Thread-Topic: [Anima] [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
Thread-Index: AQHUWrVmgB2wYYbock+QT5LGcM09j6URazOA
Date: Fri, 05 Oct 2018 20:02:55 +0000
Message-ID: <7A4C6D47-A343-4319-8EDD-8403530B3BD3@cisco.com>
References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <m2sh1qkebi.wl-randy@psg.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <m2murxi8ws.wl-randy@psg.com> <b4a32733-c2df-6bea-17d2-4d45ee4d5136@cisco.com> <m2wor0h9vu.wl-randy@psg.com> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <m2d0ssh661.wl-randy@psg.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com> <e23fefe6-fcad-6c5c-fbef-9dac9270b42c@joelhalpern.com> <ae654d8c-eb5e-95d5-f3ce-a24d6d8a71f4@gmail.com> <m21s97g8bd.wl-randy@psg.com> <F556CDA5-BDBB-4525-85C6-5960B3050092@mit.edu>
In-Reply-To: <F556CDA5-BDBB-4525-85C6-5960B3050092@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.99.106.4]
Content-Type: multipart/alternative; boundary="_000_7A4C6D47A34343198EDD8403530B3BD3ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/gVTTGT0blLKwvMmlgFmIWKSc8a8>
Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2018 20:03:12 -0000

Great thread you all. Some key points for response follow. Additionally we’re working through each numbered comment specifically.

Generally lets keep the scope of BRSKI in mind. It is a new protocol for bootstrapping via vouchers. It does not preclude the use of a local console for bootstrapping/asserting ownership. The current voucher format is a starting point and there is already work in progress for various additional forms of vouchers to address the other use cases brought up.

Re: Can vouchers be distributed directly rather than through the BRSKI-MASA sub-protocol

Vouchers are signed messages and there are a number of distribution models available. This protocol describes a predominately online model. The netconf zerotouch draft describes a different method using the same vouchers with slightly different operational trade-offs. The intention is that between these a good foundation is set for all use cases (with a focus on anima and netconf; where these documents were working group items). As described below the current method and current BRSKI flow work with direct distribution as envisioned by some of the discussion on this thread (e.g. no MASA) but that is not a primary use case. The existing work on more constrained voucher formats could help to enable those ideas a more direct use cases but will not require BRSKI protocol exchanges to change.

Re: Does BRSKI change the ownership model from the owner to the manufacturer?

Absolutely not. BRSKI defines a scalable method of bootstrapping remote secure key infrastructures via the distribution of “vouchers” from the registrar to the device. It specifically attempts to ensure the registrar (owner) is in control of decisions and attempts to minimize supply chain integrations (e.g. how much the vendor even knows about who actually owns a device). The structure is such that a 3rd party could provide all the Manufacturer Authorized Signing Authority (MASA) responsibilities — thus enabling complete vendor independence from a BRSKI protocol perspective. It specifically supports models wherein the voucher is distributed in advance, on a 2d barcode or in sales material or whatever. There is no expectation of a secure connection between the device and the vendor (beyond an expectation that vouchers are signed). The goal here is to allow the vendor to help provide a scalable deployment model.

Re: What about transfer of ownership; particularly if the MASA is antagonistic to resale?

Because there is no expectation of sales-channel integration this is really limited to discussions of antagonistic vendors. I applaud purchasing decisions to avoid such vendors. Such vendors are only able to reject zero touch deployment — they can’t effect customers that use less scalable deployment models such as console access. All vendors have the option of leveraging security technologies to make resale difficult... the existence of BRSKI only exposes such attempts in the same way the signed image loading highlights similar attempts to avoid 3rd party code.

As per the basic trust model the registrar can even provide the new owner 90% of the functionality even in the face of an antagonistic MASA: The owner can obtain a nonce-less voucher against a device specific registrar keypair. This then provides them a permanent method of bootstrapping the device that they can safely provide with the device during resale. This maintains the majority value of the protocol to the new owner while completely circumventing any future antagonism by the vendor. The device can be reset to factory defaults before the sale.

Re: What happens if the MASA service is unavailable?

BRSKI is for the transfer of trust to the current owner. There is no effect to deployed devices.
As discussed in this thread there are facilities for nonce-less permanent vouchers including ones that can be used for resale. An owner that is worried about re-deploying in the future state can take this approach. Either using a common registrar or by using a registrar per device (depending on if they plan to resale).

There will always be cases where a vendor goes away and a device is therefore limited. For example security updates to signed firmware can be impacted if the vendor no longer produces them. BRSKI does make this reality worse.

- max

On Oct 2, 2018, at 7:06 PM, Uri Blumenthal <uri@mit.edu<mailto:uri@mit.edu>> wrote:

Based on this exchange, and the arguments presented here that I observed so far, I'm with Randy. I have not seen adequate answers to his concerns (which IMHO are reasonable).

P.S. Feel free to trim the CC: list when/if responding.

P.P.S. In one of my prior incarnations many years ago, we designed a somewhat similar system, and called it "Zero-Touch Provisioning". It was a very big company, so we did not consider the possibility of it/us going out of business (and leaving the customers stranded). But if Randy's arguments were presented to our team then, we'd probably accepted them and tried to address...

Sent from my test iPhone

On Oct 2, 2018, at 20:53, Randy Bush <randy@psg.com<mailto:randy@psg.com>> wrote:

I think it's been thought through but badly articulated. In that sense,
the Last Call is doing its job.

does that mean that i can stop trying for a narten medal, go back to
work, and christian will wake me up again when my two scenarios have
clear answers; one hopes ones with which i can live?

also, please tell me that i do not need to stick my nose into the rest
of anima in order to let the user unequivocally own what they buy.  i
have my own rabbit holes to pursue in the ietf.

randy

_______________________________________________
secdir mailing list
secdir@ietf.org<mailto:secdir@ietf.org>
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
_______________________________________________
Anima mailing list
Anima@ietf.org<mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima