Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-17.txt
Michael Richardson <mcr+ietf@sandelman.ca> Tue, 06 November 2018 03:56 UTC
Return-Path: <mcr@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 99C23130DCC for <anima@ietfa.amsl.com>; Mon, 5 Nov 2018 19:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 k8xOYralZs2p for <anima@ietfa.amsl.com>; Mon, 5 Nov 2018 19:56:48 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7199127333 for <anima@ietf.org>; Mon, 5 Nov 2018 19:56:47 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:1998:a11:96ff:fe01:81e0]) by relay.sandelman.ca (Postfix) with ESMTPS id 0CA621F8BC for <anima@ietf.org>; Tue, 6 Nov 2018 03:56:46 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id C811EC17; Tue, 6 Nov 2018 09:26:17 +0530 (IST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org
In-reply-to: <154147591805.4253.8378352603197953513@ietfa.amsl.com>
References: <154147591805.4253.8378352603197953513@ietfa.amsl.com>
Comments: In-reply-to internet-drafts@ietf.org message dated "Mon, 05 Nov 2018 19:45:18 -0800."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 06 Nov 2018 10:56:17 +0700
Message-ID: <26270.1541476577@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/RctexQEJRu2z7-R1PzIJd5sPEp8>
Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-17.txt
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, 06 Nov 2018 03:56:51 -0000
internet-drafts@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-17 notes: new section 5.3. Registrar Authorization of Pledge new section 9.1. DoS against MASA also: 1.3.4. Bootstrapping is not Booting This document describes "bootstrapping" as the protocol used to obtain a local trust anchor. It is expected that this trust anchor, along with any additional configuration information subsequently installed, is persisted on the device across system restarts ("booting"). Bootstrapping occurs only infrequently such as when a device is transfered to a new owner or has been reset to factory default settings. The yang tree diagram changed from +---- to +--, and I don't know the signficance (if any) of that. 9.1. DoS against MASA There are uses cases where the MASA could be unavailable or uncooperative to the Registrar. They include active DoS attacks, planned and unplanned network partitions, changes to MASA policy, or other instances where MASA policy rejects a claim. These introduce an operational risk to the Registrar owner in that MASA behavior might limit the ability to bootstrap a pledge device. For example this might be an issue during disaster recovery. This risk can be mitigated by Registrars that request and maintain long term copies of "nonceless" vouchers. In that way they are guaranteed to be able to bootstrap their devices. The issuance of nonceless vouchers themselves creates a security concern. If the Registrar of a previous domain can intercept protocol communications then it can use a previously issued nonceless voucher to establish management control of a pledge device even after having sold it. This risk is mitigated by recording the issuance of such vouchers in the MASA audit log that is verified by the subsequent Registrar and by Pledges only bootstrapping when in a factory default state. This reflects a balance between enabling MASA independence during future bootstrapping and the security of bootstrapping itself. Registrar control over requesting and auditing nonceless vouchers allows device owners to choose an appropriate balance. The MASA is exposed to DoS attacks wherein attackers claim an unbounded number of devices. Ensuring a registrar is representative of a valid manufacturer customer, even without validating ownership of specific pledge devices, helps to mitigate this. Pledge signatures on the pledge voucher-request, as forwarded by the registrar in the prior-signed-voucher-request field of the registrar voucher-request, significantly reduce this risk by ensuring the MASA can confirm proximity between the pledge and the registrar making the request. This mechanism is optional to allow for constrained devices. Supply chain integration ("know your customer") is an additional step that MASA providers and device vendors can explore. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Anima] I-D Action: draft-ietf-anima-bootstrappin… internet-drafts
- Re: [Anima] I-D Action: draft-ietf-anima-bootstra… Michael Richardson