Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-17.txt

From: [email-masked]
Date: Mon, 05 Nov 2018 19:45:18 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF.

        Title           : Bootstrapping Remote Secure Key Infrastructures (BRSKI)
        Authors         : Max Pritikin
                          Michael C. Richardson
                          Michael H. Behringer
                          Steinthor Bjarnason
                          Kent Watsen
	Filename        : draft-ietf-anima-bootstrapping-keyinfra-17.txt
	Pages           : 92
	Date            : 2018-11-05

Abstract:
   This document specifies automated bootstrapping of a remote secure
   key infrastructure (BRSKI) using manufacturer installed X.509
   certificate, in combination with a manufacturer's authorizing
   service, both online and offline.  Bootstrapping a new device can
   occur using a routable address and a cloud service, or using only
   link-local connectivity, or on limited/disconnected networks.
   Support for lower security models, including devices with minimal
   identity, is described for legacy reasons but not encouraged.
   Bootstrapping is complete when the cryptographic identity of the new
   key infrastructure is successfully deployed to the device but the
   established secure connection can be used to deploy a locally issued
   certificate to the device as well.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-17
https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-17

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Nov 2018 10:56:17 +0700

> 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-