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

From: [email-masked]
Date: Thu, 07 Mar 2019 09:31:37 -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-19.txt
	Pages           : 101
	Date            : 2019-03-07

Abstract:
   This document specifies automated bootstrapping of an Autonomic
   Control Plane.  To do this a remote secure key infrastructure (BRSKI)
   is created 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-19
https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-19

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

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: Thu, 07 Mar 2019 14:22:19 -0500

> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-19

While the 18 to 19 diff is probably of interest to those who have most
recently reviewed the document a diff against version 16 is probably most
useful to those who last read during the WGLC.
   https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-16&url2=draft-ietf-anima-bootstrapping-keyinfra-19

We believe that we dealt with all of the review comments raised during WGLC
and reviews, and we are ready to proceed to the IESG.

The reviews are at:
secdir:  https://mailarchive.ietf.org/arch/browse/anima/?gbt=1&index=NGsR9xGIL7k_j06FXkI_GBeJZMo
genart:  https://mailarchive.ietf.org/arch/msg/anima/iVg7MRMdBQBVFA5VFiksYFHchBU
iotdir:  https://mailarchive.ietf.org/arch/msg/anima/1N7AR8hqu2oIWuTFFd9OQOab8SI

The issues that were opened are at:
    https://github.com/anima-wg/anima-bootstrap/issues?utf8=%E2%9C%93&q=is%3Aissue+

In most cases, we have used the #issue notation that github (and trac, and..)
supports in order to link the diffs that we made to the issue number.

Major changes:
      1) new section 5.3: Registrar Authorization of Pledge
      2) new section 3.1: Nonceless Voucher Requests
      3) new section 8: Applicability to the Autonomic Control Plane (plus
      other details in the document)
      4) new section 9: Privacy Considerations:

   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  60
     9.1.  MASA audit log  . . . . . . . . . . . . . . . . . . . . .  60
     9.2.  What BRSKI-MASA reveals to the manufacturer . . . . . . .  61
     9.3.  Manufacturers and Used or Stolen Equipment  . . . . . . .  63
     9.4.  Manufacturers and Grey market equipment . . . . . . . . .  64
     9.5.  Some mitigations for meddling by manufacturers  . . . . .  64

      5) additions to Security Considerations:
           10.1.  DoS against MASA . . . . . . . . . . . . . . . . . . . .  66
           10.4.  Manufacturer Maintainance of trust anchors . . . . . . .  69

Issues that we have not dealt with using text.
If you want to re-open the ticket, please go ahead, but please also bring
some text that is in-scope for ANIMA ACP:

    https://github.com/anima-wg/anima-bootstrap/issues/112
    add discussion of each major mode of the protocol #112

        * We are focused on the proximity assertion that we think is the most
          secure version of the protocol.  We have described this in detail.
        * We have expanded discussion about the nonceless (offline) mechanism
          that vouchers can use.
        * There are some additional ways the protocol can be used, but we
          feel that they should be dealt with in other documents.

    https://github.com/anima-wg/anima-bootstrap/issues/110
    gen art issue #22: permanent vouchers... feature or bug. explain further
        * we think that further discussion about this is needed.
        * this is a "major mode" that belongs in an operational document.

    https://github.com/anima-wg/anima-bootstrap/issues/79
    security review issue 6: ship and forget not supported
        * a new major mode, which we do not support, and we don't know how.
        * it is out of scope for ANIMA.
        * we did add text that existing mechanisms (craft consoles) continue
          to be available.

    https://github.com/anima-wg/anima-bootstrap/issues/82
    security review issue 7: what if MASA always issues vouchers
        * "It is mentioned in
           section 6.4, which recommend that manufacturers should not do that. What
           are the consequences if they still do?"
        -> it's hard to say what will happen if implementers violate the protocol.
           Some other set of assumptions need to be made about how many
           violations the other components do.

    https://github.com/anima-wg/anima-bootstrap/issues/83
    security review issue 8: device refuses to be imprinted
        * we think the answer is that the customer ships it back.
        * we provide telemetry as to success, but if the device is broken,
          it's broken.

    https://github.com/anima-wg/anima-bootstrap/issues/86
    security review issue 13: individualization
        * the issue asks about the per-device step in manufacturing.
        *** we think that this is out-of-scope for ANI use ***
        * we considered talking about technology like:
          https://en.wikipedia.org/wiki/Physical_unclonable_function
          but ultimately, that's just another way to do TPM, so
          skirts the question.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-