Re: [Anima] verification of manufacturer in BRSKI

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > Nonwithstanding the more detailled explanations you provided for Anoop,
    > what i wuild think to be helpful to write into the security ection is like this:

    > Domain trusting pledge/manufacturer:

I tried to use your text directly, but after some editing it looked
completely different. This is what it turned into.   Edits welcome,
and better references are sought.

+8.2.  Trusting manufacturers
+
+   The BRSKI extensions to EST permit a new pledge to be completely
+   configured with domain specific trust anchors.  The link from built-
+   in manufacturer-provided trust anchors to domain-specific trust
+   anchors is mediated by the signed voucher artifact.
+
+   If the manufacturer's IDevID signing key is not properly validated,
+   then there is a risk that the network will accept a pledge that
+   should not be a member of the network.  As the address of the
+   manufacturer's MASA is provided in the IDevID using the extension
+   from Section 2.3, the malicious pledge will have no problem
+   collaborating with it's MASA to produce a completely valid voucher.
+
+   BRSKI does not, however, fundamentally change the trust model from
+   domain owner to manufacturer.  Assuming that the pledge used its
+   IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs
+   to trust the manufacturer.
+
+   Establishing this trust between domain and manufacturer is outside
+   the scope of BRSKI.  There are a number of mechanisms that can
+   adopted including:
+
+   o  Manually configuring each manufacturer's trust anchor.
+
+   o  A Trust-On-First-Use (TOFU) mechanism.  A human would be queried
+      upon seeing a manufacturer's trust anchor for the first time, and
+      then the trust anchor would be installed to the trusted store.
+      There are risks with this; even if the key to name is validated
+      using something like the WebPKI, there remains the possibility
+      that the name is a look alike: e.g, c1sco.com, ..
+
+   o  scanning the trust anchor from a QR code that came with the
+      packaging (this is really a manual TOFU mechanism)
+
+   o  some sales integration process where trust anchors are provided as
+      part of the sales process, probably included in a digital
+      packing "slip", or a sales invoice.
+
+   o  consortium membership, where all manufacturers of a particular
+      device category (e.g, a light bulb, or a cable-modem) are signed
+      by an certificate authority specifically for this.  This is done
+      by CableLabs today.  It is used for authentication and
+      authorization as part of TR-79: [docsisroot] and [TR069].
+
+   The existing WebPKI provides a reasonable anchor between manufacturer
+   name and public key.  It authenticates the key.  It does not provide
+   a reasonable authorization for the manufacturer, so it is not
+   directly useable on it's own.
+

...

Perhaps there are better references, but I'm not particularly clued into
them.  If there is someone more involved in the CMTS specifications, perhaps
you can tell me how to cite this better.

+   [docsisroot]
+              CableLabs, , "CableLabs Digital Certificate Issuance
+              Service", February 2018,
+              <https://www.cablelabs.com/resources/digital-certificate-
+              issuance-service/>.

+   [TR069]    Broadband Forum, , "TR-69: CPE WAN Management Protocol",
+              February 2018, <https://www.broadband-forum.org/standards-
+              and-software/technical-specifications/tr-069-files-tools>.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-