Subject: [Anima] splitting up richardson-anima-masa-considerations into two pieces

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2020 00:33:43 -0400

We have split up richardson-anima-masa-considerations into two pieces:

1) the MASA operational considerations.  This is the BRSKI specific part
   which was part two of the original document.

   It deals with generating vouchers, and how to create and manage the
   trust anchors that need to be built-into the firmware.

[email-masked] wrote:
    > A new version of I-D, draft-richardson-anima-masa-considerations-04.txt
    > has been successfully submitted by Michael Richardson and posted to the
    > IETF repository.

    > URL:
    > https://www.ietf.org/internet-drafts/draft-richardson-anima-masa-considerations-04.txt

I would welcome more discussion in ANIMA on this part.

2) draft-richardson-secdispatch-idevid-considerations

which deals with how do build and operate the IDevID needed to make BRSKI
operate.  This document is not intended to be BRSKI specific, but deal with
any use for IDevID certificates.  Clearly other uses may have other needs,
but it should be possible to build a superset system that makes everyone
happy.

  https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/

Abstract:
   This document provides a number of operational modes that a
   manufacturer of devices that include IEEE 802.1AR IDevID certificates
   may choose from.  Different ways of generating and signing the needed
   keypairs are detailed, and the security tradeoffs of each method are
   considered.  This document provides a nomenclature for each mode.

   IDevID certificates are used in ANIMA's BRSKI Manufacturer Authorized
   Signing Authority (MASA) process.

I will be asking secdispatch to consider what to do with this document.
I say that there is a nomenclature, but I don't yet have a clue how to name
the three (at least) ways of doing key generation.   Part of the reason to
split this document up is to make it easier to get this part reviewed widely.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Jun 2020 11:51:46 -0400

Dear Secdispatch chairs and WG, (and various people in the BCC who are
encouraged to forward)

EXEC SUM:  https://datatracker.ietf.org/doc/draft-richardson-secdispatch-idevid-considerations/

While working on ANIMA's BRSKI enrollment system, and the associated
mechanisms that create the ACP, it became clear that there was possibly a
wealth of useful advice on operating the Manufacturer and Owner components
(the MASA and Registrar).  As these thoughts grew, it became clear that there
were many non-normative, non-wire-protocol level design considerations.
Two documents were originally created:
    a) draft-richardson-anima-masa-considerations
    b) draft-richardson-anima-registrar-considerations

Both situations involve operation of a certificate authority.
On the manufacturer side, this involves the Manufacturer Installed
Certificate, the IDevID.  There are multiple users of the IDevID and there
are many entities building a variety of trust models based upon having
that trust model.  For instance, the Kumari/Doyle Secure Device
Install/draft-ietf-opsawg-sdi-12 leverages built-in certificates as much as
BRSKI does.

Much of the RATS work requires some kind of known signing key to
be built-in, secured deep into a hardware or firmware TPM/enclave.
If you want to (asymmetrically) encrypt firmware for SUIT, you may need
keys built in too.  Many other protocols also depend upon keys to be deployed,
but can deal with having them deployed as part of configuration, but as we
all experienced, actually getting them deployed can be difficult.

As discussed at the RATS/SUIT/TEEP Hackathon, and later in a few WGs, there
seems to be three ways to deploy matching private-key/certificates. a)
generate key onboard, sign with EST/SCEP/CMP/magic<%>, b) generate keypair in
CA, deploy with EST/SCEP/JTAG/magic, c) simultaneously/deterministically
generate keypair from shared secret, deploy certificate via magic.
I don't have good names for these three methods, nor sufficient proof that
there isn't a reasonable fourth method.    One reason (among many) to have
names for these three methods is so that it is possible in Supply Chain
Security discussions to be able to easily state the inherent security vested
in the device, and to thus #include the risk/threat landscape of devices
(particularly MCUs) that are included in designs.

I believe that EST (RFC7030), SCEP (draft-gutmann-scep) and some lightweight
profile of CMP (such as is in LAMPS) are reasonable protocols for factory
time onboarding, but require very strict profiling to get right.  This makes
it IETF business.
I would want to have a champion for (a)/(b)/(c) X {EST,SCEP,CMP}., ideally
said champion would be describing active experience from a real factory.

As publically anchored enterprise (intermediate) CAs seem to be a thing of
the past, many have discussed how appropriate it might be for manufacturers
to use ACME to provision IDevIDs directly. {In fact, I have running code}

There are however many aspects of this effort which might reasonably be
considered outside of the IETF perview.  Fundamentally, these are PKIX
objects that are being provisioned, and it is at the IETF that potential
successors to PKIX (CoID, JWTs, etc.) are being developed.

One of the major difficulties I have experienced in trying to assemble this
document is that current methods are often buried in a Silicon
vendor/OEM-board vendor interaction fearing many NDAs. This is particularly
acute for method (c).  This makes it difficult to ascertain what level of
care has been taken with the sensitive symmetric keys, which results in a
difficulty to compare audit results across the industry.

In order to get better and wider review, as well as detailing the required
magic, I've split the MASA considerations document into two pieces.
One is BRSKI MASA RFC8366 voucher generation specific, which I intend to
leave in the ANIMA WG (should the chairs agree), and the other part which is
IDevID generation specific, which I am looking for advice from secdispatch to
determine what to do with it.

The second document is:

and it is still rather drafty.

I will note that draft-richardson-anima-registrar-considerations also
discusses an Operator/Enterprise/Home-router having/operating a CA,
(among many other things), and I am undecided whether or not to extract
that advice and merge it into idevid-considerations.  At this point, I think
that it is not of general interest and it is better kept isolated.

<%> leveraging Clarke's third law, but possibly also 1st and 2nd law as well.