Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Oct 17, 2019 at 07:08:49AM -0700, Benjamin Kaduk via Datatracker wrote:
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> % (1) The text of the document suffers from lack of clarity throughout about
> % whether the nonce-ful operation is mandatory or not, with several
> % figures and discussions making declarative statements about nonce usage
> % and others saying that nonce usage is optional. (See COMMENT.)
> 
> [keep in mind when reading]

This was just supposed to be a note to myself and should be ignored; I was
in a hurry and forgot to trim it before pushing "send".  Sorry about that.

I also have some more comments that didn't make it into my ballot position;
please consider them as well.  I will put them in the datatracker for
posterity, but will have it not generate an additional mail since the
mostly-duplicate contents would be confusing.

Section 2

Should the "Drop Ship" arrow in Figure 1 be unidirectional instead of
bidirectional?

   3.  Request to join the discovered registrar.  A unique nonce is
       included ensuring that any responses can be associated with this
       particular bootstrapping attempt.

This still seems to assume nonce-ful operation, which IIUC remains
required for pledge voucher-requests; only registrar-voucher-requests
have the option of being nonceless.  So, this seems okay as-is, right?

   4.  Imprint on the registrar.  This requires verification of the
       manufacturer service provided voucher.  A voucher contains

nit: hyphenate "manufacturer-service-provided"

Section 2.3.1

   The serialNumber fields is defined in [RFC5280], and is a SHOULD
   field in [IDevID].  IDevID certificates for use with this protocol
   MUST include the "serialNumber" attribute with the device's unique
   serial number (from [IDevID] section 7.2.8, and [RFC5280] section
   4.1.2.4's list of standard attributes).

This is 4.1.2.2 (or just 4.1.2) from RFC 5280.

Section 2.4

I note that both Figure 2 and Figure 4 have a step labeled "Identity",
but the description accompanying Figure 2 describes the step as
"Identify itself"; perhaps the 'f' form is more appropriate everywhere?

Section 2.8

   Note that the registrar can only select the configured MASA URL based
   on the trust anchor -- so manufacturers can only leverage this
   approach if they ensure a single MASA URL works for all pledge's
   associated with each trust anchor.

nit: s/pledge's/pledges/

Section 3

   Voucher-requests are how vouchers are requested.  The semantics of
   the vouchers are described below, in the YANG model.

nit: semantics of vouchers, or voucher requests?

Section 3.3

         Figure 6: JSON representation of example Voucher-Request

I suggest adding "(unsigned)" or "prior to CMS wrapping".

Section 3.4

      refine "voucher/assertion" {
        mandatory false;
        description "Any assertion included in voucher
              requests SHOULD be ignored by the MASA.";

If this is true, why do we propagate the assertion from pledge
voucher-request to registrar voucher-request?

Section 4.1

   Each possible proxy offer SHOULD be attempted up to the point where a
   voucher is received: while there are many ways in which the attempt
   may fail, it does not succeed until the voucher has been validated.

nit: I suggest "valid voucher is received".

Section 5

   o  The pledge requests and validates a voucher using the new REST
      calls described below.

nit: I think the validation is local and does not use the REST call.

   o  The registrar forwards the voucher to the pledge when requested.

I suggest "validates and forwards" to cover the case where the registrar
applies policy.

Section 5.2

   nonce:  The pledge voucher-request MUST contain a cryptographically
      strong random or pseudo-random number nonce. (see [RFC4086]) Doing
      so ensures Section 2.6.1 functionality.  The nonce MUST NOT be

This section reference reads kind of strangely.  (Also, full stop after
parenthetical, not before.)

   proximity-registrar-cert:  In a pledge voucher-request this is the
      first certificate in the TLS server 'certificate_list' sequence
      (see [RFC5246]) presented by the registrar to the pledge.  That
      is, it is the end-entity certificate.  This MUST be populated in a
      pledge voucher-request if the "proximity" assertion is populated.

nit: there is no "proximity" field to be populated; it's the "assertion"
field that's populated with the value "proximity".

Section 5.5

   serial-number:  The serial number of the pledge the registrar would
      like a voucher for.  The registrar determines this value by
      parsing the authenticated pledge IDevID certificate.  See
      Section 2.3.  The registrar MUST verify that the serial number
      field it parsed matches the serial number field the pledge
      provided in its voucher-request.  This provides a sanity check
      useful for detecting error conditions and logging.  The registrar
      MUST NOT simply copy the serial number field from a pledge voucher
      request as that field is claimed but not certified.

(Just to be clear, the serial-number field is optional in the pledge's
voucher-request.)

Section 5.6.2

   intervals according to the backoff timer described earlier.  Attempts
   SHOULD be repeated as failure may be the result of a temporary
   inconsistently (an inconsistently rolled registrar key, or some other
   mis-configuration).  The inconsistently could also be the result an
   active MITM attack on the EST connection.

nit: only one of these "inconsistently"s is correct; the others should
be "inconsistency".

Section 5.8

   although it results in additional network traffic.  The relying MASA
   implementation MAY leverage internal state to associate this request
   with the original, and by now already validated, voucher-request so
   as to avoid an extra crypto validation.

It seems that doing so would turn the voucher-request into a bearer
token for retrieving audit-log information (if the MASA accepts
unauthenticated clients).

Section 5.8.2

   If the "pinned-domain-cert" certificate includes the
   SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
   used as the domainID.  If not, then it is the SPKI Fingerprint as
   described in [RFC7469] section 2.4 is to be used.  This value needs
   to be calculated by both MASA (to populate the audit-log), and by the
   Registrar (to recognize itself).

nit: maybe "to recognize itself in the audit log"?

Section 5.9

   The pledge SHOULD follow the BRSKI operations with EST enrollment
   operations including "CA Certificates Request", "CSR Attributes" and
   "Client Certificate Request" or "Server-Side Key Generation", etc.
   This is a relatively seamless integration since BRSKI REST calls

(I think we decided to not call this REST.)

Section 7.3

   4.  A registrar MAY ignore unrecognized nonceless log entries.  This
       could occur when used equipment is purchased with a valid history
       being deployed in air gap networks that required permanent
       vouchers.

"nonceless" and "permanent" are related but subtly different concepts,
given the potential for an expiration date in a nonceless voucher.

Section 7.4.3

   As a third option, the manufacturer's trust anchors could be entirely
   overwitten with local trust anchors.  A factory default would never
   restore those anchors.  This option comes with a lot of power, but
   also a lot of responsability: if the new anchors are lost the
   manufacturer may be unable to help.

nit: perhaps we refer to the private key portions of the anchors.

Section 11

I am somewhat embarassed that I did not previously note that the
mechanism used to generate the domainID needs to be
second-preimage-resistant or an attacker can claim to be a registrar for
a domain that already exists.

Section 11.2

   Although the nonce used by the Pledge in the voucher-request does not
   require a strong cryptographic randomness, the use of TLS in all of
   the protocols in this document does.

We discuss the need for strong randomness in the nonce in Section 11.3,
so it's not clear this is actually true.

Thanks!

-Ben