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 =-