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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 17 Oct 2019 07:08:49 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the time and attention to detail put into addressing my previous
Discuss and Comment points.  I have one new Discuss-level point and one
that I think may have been missed (probably because I inadvertently numbered
two points with the same number).

(16) The audit log response (Section 5.8.1) describes the nonce as a JSON
string, but the RFC 8366 nonce is a binary value.  I think we need to
describe some mapping procedure (such as always base64-encoding as is
done for domainID, even if the original nonce is itself base64-encoded
random data) in order to be fully functional.

% (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]

% (5.1) the new /enrollstatus EST endpoint seems under-specified.

Shame on me, I reused (5) for two points and have renumbered this to
(5.1) so we don't miss it again.  We don't anywhere give a formal
description of the contents of the POST body; there's just an example
JSON object.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[All new comments for the -28]

Please respond to the secdir re-review.

Abstract

nit: hyphenate "manufacturer-installed"

   or on limited/disconnected networks.  Support for lower security
   models, including devices with minimal identity, is described for

nit: maybe "deployment models with less-stringent security requirements"?

Section 1

   [I-D.ietf-anima-autonomic-control-plane].  This bootstrap process
   satisfies the [RFC7575] section 3.3 of making all operations secure
   by default.  Other users of the BRSKI protocol will need to provide

nit: missing "requirement"

   between manufacturer and owner: in it's default modes it provides a
   cryptographic transfer of control to the initial owner.  In it's
   strongest modes, it leverages sales channel information to identify

nit: s/it's/its/

Section 1.2

   domainID:  The domain IDentity is a unique hash based upon the
      Registrar CA's certificate.  Section 5.8.2 specifies how it is
      calculated.

nit: the grammar here is weird; I'd suggest s/hash based upon/value
derived from/

   MASA Audit-Log:  A list of previous owners maintained by the MASA on
      a per device (per pledge) basis.  Described in Section 5.8.1.

nit: maybe "anonymized list" since the MASA doesn't really track owners
directly?

   Ownership Tracker:  An Ownership Tracker service on the global
      Internet.  The Ownership Tracker uses business processes to
      accurately track ownership of all devices shipped against domains
      that have purchased them.  Although optional, this component
      allows vendors to provide additional value in cases where their
      sales and distribution channels allow for accurately tracking of
      such ownership.  Ownership tracking information is indicated in

nit: either "accurate tracking of" or "accurately tracking"

   ANI:  The Autonomic Network Infrastructure as defined by
      [I-D.ietf-anima-reference-model].  This document details specific
      requirements for pledges, proxies and registrars when they are
      part of an ANI.

Maybe refer to section 9 specifically?

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

nit: s/fields/field/

Section 2.5.1

   The pledge is the device that is attempting to join.  The pledge can
   talk to the Join Proxy using link-local network connectivity.  In
   most cases, the pledge has no other connectivity until the pledge
   completes the enrollment process and receives some kind of network
   credential.

I'd consider s/can talk to/is assumed to talk to/.

Section 2.5.3

   The registrar uses an Implicit Trust Anchor database for
   authenticating the BRSKI-MASA TLS connection MASA certificate.  The
   registrar uses a different Implicit Trust Anchor database for
   authenticating the BRSKI-EST TLS connection pledge client
   certificate.  Configuration or distribution of these trust anchor
   databases is out-of-scope of this specification.

   Configuration or distribution of this trust anchor databases is out-
   of-scope of this specification.  Note that the trust anchors in/
   excluded from the database will affect which manufacturers' devices
   are acceptable to the registrar as pledges, and can also be used to
   limit the set of MASAs that are trusted for enrollment.

We seem to duplicate the "out-of-scope" text at the end/start of the two
paragraphs (and the second paragraph uses the definite article "the" as
if it was only talking about one of the two trust anchor databases).

Section 2.6.1

   A pledge with a real time clock in which it has confidence in, MUST
   check the above time fields in all certificates and signatures that
   ir processes.

nits: s/ir/it/, and s/in// from "in which it has confidence in" (your
choice which one).

Section 2.6.2

   year certificate lifetimes.  Registrars SHOULD be configurable on a
   per-manufacturer basis to ignore pledge lifetimes when they did not
   follow the RFC5280 recommendations.

nit: we want "they" to be the manufacturer, not the registrar, so we
can't use this pronoun.

Section 2.7

   be more important in the future.  In the ANIMA ACP scope, new devices
   will be quarantined behind a Join Proxy.

I can't decide whether the reader would benefit from being hit with a
hammer of "and as such will only have link-local connectivity, to the
Join Proxy".  The use of "quarantined" makes me lean towards "not"...

Section 3

In my previous comment, I said:

%    The "proximity-registrar-cert" leaf is used in the pledge voucher-
%    requests.  This provides a method for the pledge to assert the
%    registrar's proximity.
%
% "proximity" in what sense?  How much verification/confidence needs to be
% done?  (Also, I would have expected the assertion to go the other way;
% that the registrar asserts the pledge's proximity -- how does the pledge
% have a way to know that the registrar is nearby when the proxy is
% transparent?)

We talked about this some, but I think we're still making an unstated
assumption that there is a link-local or pre-ACP connection involved.
Making that an explicit assumption would be helpful.

Section 3.3

   Example (2)  The following example illustrates a registrar voucher-
                request.  The 'prior-signed-voucher-request' leaf is
                populated with the pledge's voucher-request (such as the
                prior example).  The pledge's voucher-request is a
                binary CMS signed object.  In the JSON encoding used
                here it must be base64 encoded.  The nonce and assertion
                MAY be carried forward from the pledge request to the
                registrar request.  The serial-number is extracted from
                the pledge's Client Certificate from the TLS connection.
                See Section 5.5.

Since this is an example, the "MAY be carried forward" feels out of
place -- while it's true in the general case, this is not the place to
say it; we can just describe what the example does, here.

Also, we should probably give a reference for base64 (not necessarily
here), such as Section 4 of RFC 4648.

Section 4

   This section applies is normative for uses with an ANIMA ACP.  The

nit: pick one of "applies to" or "is normative for".

   use of GRASP mechanism part of the ACP.  Other users of BRSKI will

nit: missing "is"

Section 4

   Registrar itself.  In this scenario the pledge is unaware that there
   is no proxing occurring.  This is useful for Registrars which are

nit: s/proxing/proxying/

Section 4.3

   The M_FLOOD message MUST be sent periodically.  The default SHOULD be
   60 seconds, the value SHOULD be operator configurable but SHOULD be
   not smaller than 60 seconds.  The frequency of sending MUST be such

nits: "default period" (or similar); s/be not/NOT be/

Section 5

   While EST section 3.2 does not insist upon use of HTTP persistent
   connections, ([RFC7230] section 6.3) BRSKI-EST connections SHOULD use

nit: comma after parenthetical, not before.

Section 5.1

   Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
   REQUIRED.

How painful would it be to require 1.3 at this point?  RFC 8446 has been
out for more than a year, and the TLS WG is leaning on me to tighten up
on this...

   IDevID certificate is out-of-scope of this specification.  Note that
   the trust anchors in/excluded from the database will affect which
   manufacturers' devices are acceptable to the registrar as pledges,
   and can also be used to limit the set of MASAs that are trusted for
   enrollment.

I can't tell if we want to bring the division into two distinct trust
anchor databases into this discussion as well.

   A self-signed certificate for the Registrar is acceptable as the
   voucher will validate it.

nit: "will" applies only when everything works, so maybe "can" or "will
validate it in the case of successful enrollment".

   A pledge that can connect to multiple registries concurrently SHOULD

nit: s/registries/Regitstrars/

Section 5.3

   on the authenticated identity presented.  For different networks,
   examples of Automated acceptance may include:

nit: s/A/a/

Section 5.4

   Section 2.8.  The mechanisms in [RFC6125] SHOULD be used
   authentication of the MASA.  Some vendors will establish explicit (or

nit: s/used/used for/
Also, we tend to require that people using 6125 specify what name type
in the cert to verify (e.g., DNS-ID) against what expected name.  It
would be pretty easy to convince me that we don't need to do that here,
though.

Section 5.4

   Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is
   REQUIRED.

As above, how painful would requiring 1.3 be?

   client certificate.  Registrars SHOULD also permit an HTTP Basic and
   Digest authentication to be configured.

nit: s/an//

Section 5.4.1

   be uniquely identified.  This can be done by any stateless method
   that HTTPS supports: such as with HTTP Basic or Digest authentication

nit: this colon is not appropriate usage.

   Stateful methods involving API tokens, or HTTP Cookies are not
   recommended.

nit: zero commas or two, around "or HTTP Cookies", but one is right out.

   This document does not make a specific recommendation as there is
   likely different tradeoffs in different environments and product

nit: s/is/are/

Section 5.5

   idevid-issuer:  The Issuer value from the pledge IDevID certificate
      is included to ensure a uniqueness of the serial-number.  In the
      case of nonceless (offline) voucher-request, then an appropriate
      value needs to be configured from the same out-of-band source as
      the serial-number.

nit: I suggest s/a uniqueness of/a unique interpretation of/ (but if you
don't take that, the "a" is superfluous in the current formulation).

   prior-signed-voucher-request:  The signed pledge voucher-request
      SHOULD be included in the registrar voucher-request.  The entire
      CMS signed structure is to be included, base64 encoded for
      transport in the JSON structure.

I think we need a ref for (which) base64.

   The MASA verifies that the registrar voucher-request is internally
   consistent but does not necessarily authenticate the registrar
   certificate since the registrar MAY not be known to the MASA in
   advance.  The MASA performs the actions and validation checks

I suggest s/MAY not be known/MAY be unknown/.

Section 5.5.2

   The registrar's certificate chain is extracted from the signature
   method.  The entire registrar certificate chain was included in the
   CMS structure, as specified in Section 5.5.  This CA certificate will
   be used to populate the "pinned-domain-cert" of the voucher being
   issued.

By saying "this CA certificate", are we excluding use cases where the
pinned-domain-cert is not the global root CA of the organization (or is
the implication just that you don't send the rest of the chain)?

Section 5.5.5

   voucher-request MUST include a 'proximity-registrar-cert' that is
   consistent with to the certificate used to sign the registrar

nit: s/to// (first one)

Section 5.5.6

   The MASA populates the audit-log with the nonce that was verified.
   If a nonceless voucher is issued, then the audit-log is to be
   populated with the JSON value "null".

The quotes around "null" are perhaps anti-helpful.

Section 5.6.1

   The pledge MUST verify that the voucher nonce field is accurate and
   matches the nonce the pledge submitted to this registrar, or that the
   voucher is nonceless (see Section 7.2).

In my previous Discuss position I had asked:
% Is the pledge supposed to accept a nonceless voucher in response to a
% nonce-ful voucher request?
and we had some discussion that helped clarify the intent.  I just have
a suggested rewording, that I *think* is entirely editorial and might
reduce the potential for confusion:
NEW
   The pledge MUST verify the nonce information in the voucher.  If
   present, the nonce in the voucher must match the nonce the pledge
   submitted to the registrar; vouchers with no nonce can also be
   accepted (according to local policy).

Section 5.7

   The Status field indicates if the voucher was acceptable.  Boolean
   values are acceptable.

nit: I suggest """acceptable, as a boolean, where "true" indicates the
voucher was acceptable""".

   The version, and status fields MUST be present.  The Reason field
   SHOULD be present whenever the status field is negative.  The Reason-
   Context field is optional.

nit: no comma after "version".
nit: s/negative/false/

   The keys to this JSON hash are case-insensitive.  Figure 15 shows an
   example JSON.

This (case-insensitivity) seems to be a drastic divergence from the RFC
8259 standard behavior and as such would require some justification.
nit: s/hash/object/

Section 5.8.1

It's hard to call Figure 17 an "example" when it doesn't conform to the
CDDL schema...

   The domainID is a binary value calculated SubjectKeyIdentifier
   according to Section 5.8.2.  It is encoded once in base64 in order to
   be transported in this JSON container.

nit: I suggest "binary SubjectKeyIdentifier value calculated"

Section 5.8.2

   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

nit: drop "is to be used" or "then it is".

Section 5.8.3

   A relatively simple policy is to white list known (internal or
   external) domainIDs.  To require all vouchers to have a nonce.

nit: sentence fragment.

   Alternatively to require that all nonceless vouchers be from a subset

nit: comma after "alternatively".  (Hmm, this is also a sentence
fragment.)

Section 5.9.4

   In order to communicate this indicator, the client HTTP POSTs the
   following to the server at the new EST endpoint at "/.well-known/est/
   enrollstatus".

"The following" is just more text, not a formal description of a
protocol element.

     "reason-context": "Additional information"

Is this supposed to be a string or a JSON object similar to
/voucher_status?

Section 6

   When used within BRSKI, the original RFC7030 EST endpoints remain
   Base64 encoded, but the new BRSKI end points which send and receive
   binary artifacts (specifically, /requestvoucher) are binary.  That

The other two occurrences spell this "/.well-known/est/requestvoucher".

Section 7.2

   The following are a list of alternatives behaviours that the pledge
   can be programmed to implement.  These behaviours are not mutually
   exclusive, nor are they dependant upon other.  Some of these methods

nits: singular/plural mismatch "are"/"list"; "upon each other"

Section 7.3

   A registrar can choose to accept devices using less secure methods.
   These methods are acceptable when low security models are needed, as
   the security decisions are being made by the local administrator, but
   they MUST NOT be the default behavior:

I'm having a hard time parsing "low security models"; the best I can
come up with is "threat models where low security is adequate".

Section 7.4.1

   A MASA has the option of not including a nonce is in the voucher,

nit: s/is//

   and/or not requiring one to be present in the voucher-request.  This
   results in distribution of a voucher that never expires and in effect

"expires-on" is distinct from the nonce-ful freshness check, so I think
some additional wordsmithing is in order.

   This is useful to support use cases where registrars might not be
   online during actual device deployment.

nit: there's enough intervening text that we should probably replace
"this is" with "nonceless vouchers are".

   authorized to provide this functionality to this customer.  The MASA
   is RECOMMENDED to use this functionality only in concert with an
   enhanced level of ownership tracking (out-of-scope.)

I suggest s/out-of-scope/the details of which are out of scope for this
document/.

Section 7.4.2

   functionality.  This provides a proof-of-proximity check that reduces
   the need for ownership verification.

I suggest reiterating the assumption that pledge and JP are on a
link-local connection; whether or not to reiterate that JP and registrar
have a trust relationship (with respect to not falsifying proximity
information) is less clear to me.

Section 7.4.3

We might benefit from some introductory text here to suggest that
updating/extending trust anchors would be desirable in the case of a
vanished or uncooperative manufacturer.

   This weaker factor reset might leave valuable credentials on the
   device and this may be unacceptable to some owners.

nit: s/factor/factory/

Section 9

   Provider organizations.  Equivalent enterprises that has significant
   layer-3 router connectivity also will find significant benefit,

nit: s/has/have/

   In the ACP, the Join Proxy is found to be proximal because
   communication between the pledge and the join proxy is exclusively on

nit(?) My dictionary doesn't list anything for "proximal" that is a good
match for "with proximity"; might be worth double-checking.

   asssertion is satisfied.  Other uses of BRSKI will need make similar
   analysis if they use proximity.

nit: maybe "proximity information" or "proximity assertions".

Section 10.3

   While the contents of the signed part of the pledge voucher request
   can not be changed, they are not encrypted at the registrar.  The
   ability to audit the messages by the owner of the network a mechanism
   to defend against exfiltration of data by a nefarious pledge.  Both

nit: missing verb ("is a mechanism", "provides a mechanism", etc.)

   The manufacturer knows the IP address of the Registrar, but it can
   not see the IP address of the device itself.  The manufacturer can
   not track the device to a detailed physical or network location, only
   to the the location of the Registrar itself.  That is likely to be at

nit: we probably don't need the last "itself".

   is likely on the same network as the device.  A manufacturer that
   sells switching/routing products to enterprises should hardly be
   surprised if additional purchases switching/routing products are
   purchased.  Deviations from a historical trend or an establish

nit: we probably only need one of "purchases" and "purchased".

Section 10.6

   Section Section 7.4.3 describes some ways in which a manufacturer

nit: duplicate "Section".

Section 10.7

   existing products.  Said products might be previous deployed and need
   to be re-initialized, purchased used, or just kept in a warehouse as
   long-term spares.

nit: s/previous deployed and need/previously deployed that need/

Section 11.2

   In particular implementations should pay attention to the advance in
   [RFC4086] section 3, particulary section 3.4.  Devices which are
   reset to factory default in order to perform a second bootstrap with
   a new owner MUST NOT seed their random number generators in the same
   way.

nit: s/same way/same way across bootstraps/

Section 11.3

We had some discussion around my previous comment:

%    Additionally, in order to successfully use the resulting voucher the
%    Rm would have to attack the pledge and return it to a bootstrapping
%    enabled state.  This would require wiping the pledge of current
%
% ... and I think there is a different attack if the Rm is in a position
% to delay or drop network traffic between the  pledge and the intended
% registrar, to cause Rm's voucher to be delivered first even though it is
% generated after the intended registrar's authorization process.  The
% intended registrar would need to require reports on voucher processing
% status (or investigate their absence) in order to detect such a case.

but I can't remember if we decided that we didn't need to discuss the
risk in the document.

Section 11.5

   This next section examines the risk due to a compromised MASA key.
   This is followed by examination of the risk of a compromised
   manufacturer IDevID signing key.  The third section sections below

nit: I think these appear in the other order.

Section 13.1

[cabforumaudit] and [dnssecroot] probably would be fine as just
informative references.

Appendix D.2

An RFC Editor note about the RFC 8366 assignment of OID
1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples
properly use that assigned OID now?

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 17 Oct 2019 18:23:52 -0700

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Oct 2019 16:23:51 -0400

Hi, this got quite long.
I've split this up into nits and substantive comments.
This email is about the nits... it should all be boring and uncontroversial,
requiring no answers from you, I hope.
Please see a diff at: https://tinyurl.com/y5l4xz3z

    > nit: hyphenate "manufacturer-installed"

done.

    > nit: maybe "deployment models with less-stringent security

I had actually edited the abstract into leaving that sentence incomplete, now fixed.

    > satisfies the [RFC7575] section 3.3 of making all operations secure by
    > default.  Other users of the BRSKI protocol will need to provide

    > nit: missing "requirement"

already fixed it seems

    > nit: s/it's/its/

already fixed.

    > nit: the grammar here is weird; I'd suggest s/hash based upon/value

done.

    > nit: maybe "anonymized list" since the MASA doesn't really track owners

done.

    > Internet.  The Ownership Tracker uses business processes to accurately
    > track ownership of all devices shipped against domains that have
    > purchased them.  Although optional, this component allows vendors to
    > provide additional value in cases where their sales and distribution
    > channels allow for accurately tracking of such ownership.  Ownership
    > tracking information is indicated in

    > nit: either "accurate tracking of" or "accurately tracking"

fixed.

    > requirements for pledges, proxies and registrars when they are part of
    > an ANI.

    > Maybe refer to section 9 specifically?

okay.

    > nit: s/fields/field/

fixed a different way for Christian.

    > authenticating the BRSKI-EST TLS connection pledge client certificate.
    > Configuration or distribution of these trust anchor databases is
    > out-of-scope of this specification.

    > excluded from the database will affect which manufacturers' devices are
    > acceptable to the registrar as pledges, and can also be used to limit
    > the set of MASAs that are trusted for enrollment.

    > We seem to duplicate the "out-of-scope" text at the end/start of the
    > two paragraphs (and the second paragraph uses the definite article
    > "the" as if it was only talking about one of the two trust anchor
    > databases).

okay. keeping the second version, changing this->these.

    > check the above time fields in all certificates and signatures that ir
    > processes.

    > nits: s/ir/it/, and s/in// from "in which it has confidence in" (your

done.

    > nit: we want "they" to be the manufacturer, not the registrar, so we

Should be pledge, fixed.

    >    be more important in the future.  In the ANIMA ACP scope, new
    > devices will be quarantined behind a Join Proxy.

    > Join Proxy".  The use of "quarantined" makes me lean towards "not"...

agreed.

    > Section 3.3

    doc>    Example (2) The following example illustrates a registrar voucher-
    doc> request.  The 'prior-signed-voucher-request' leaf is populated with the
    doc> pledge's voucher-request (such as the prior example).  The pledge's
    doc> voucher-request is a binary CMS signed object.  In the JSON encoding
    doc> used here it must be base64 encoded.  The nonce and assertion MAY be
    doc> carried forward from the pledge request to the registrar request.  The
    doc> serial-number is extracted from the pledge's Client Certificate from
    doc> the TLS connection.  See Section 5.5.

    > say it; we can just describe what the example does, here.

Agreed, I will change that to "have been carried forward"

    > nit: pick one of "applies to" or "is normative for".

The text now says:
   doc> This section is normative for uses with an ANIMA ACP.

    > nit: missing "is"

already fixed.

    > nit: s/proxing/proxying/

fixed, ty.

    >    The M_FLOOD message MUST be sent periodically.  The default SHOULD
    > be 60 seconds, the value SHOULD be operator configurable but SHOULD be

    > nits: "default period" (or similar); s/be not/NOT be/

fixed.

    > nit: comma after parenthetical, not before.

fixed.

    doc>    A self-signed certificate for the Registrar is acceptable as the
    doc> voucher will validate it.

    > validate it in the case of successful enrollment".

okay.

    > nit: s/registries/Regitstrars/

fixed.

    > nit: s/A/a/

fixed.

    > As above, how painful would requiring 1.3 be?

Consistently with the text above:

          Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
          REQUIRED.  TLS 1.3 (or newer) SHOULD be available.

    > nit: s/an//

fixed.

    > nit: this colon is not appropriate usage.

ok.

    > nit: zero commas or two, around "or HTTP Cookies", but one is right

ok.

    > nit: s/is/are/

ok.

    > is included to ensure a uniqueness of the serial-number.  In the case
    > of nonceless (offline) voucher-request, then an appropriate value needs
    > to be configured from the same out-of-band source as the serial-number.

    > nit: I suggest s/a uniqueness of/a unique interpretation of/ (but if
    > you don't take that, the "a" is superfluous in the current
    > formulation).

ok.

    doc>    The MASA verifies that the registrar voucher-request is internally
    doc> consistent but does not necessarily authenticate the registrar
    doc> certificate since the registrar MAY not be known to the MASA in
    doc> advance.  The MASA performs the actions and validation checks

    > I suggest s/MAY not be known/MAY be unknown/.

ok.

    > Section 5.5.5

    doc>    voucher-request MUST include a 'proximity-registrar-cert' that is
    doc> consistent with to the certificate used to sign the registrar

    > nit: s/to// (first one)

ok

    > Section 5.6.1

    doc>    The pledge MUST verify that the voucher nonce field is accurate and
    doc> matches the nonce the pledge submitted to this registrar, or that the
    doc> voucher is nonceless (see Section 7.2).

    > In my previous Discuss position I had asked: % Is the pledge supposed
    > to accept a nonceless voucher in response to a % nonce-ful voucher
    > request?  and we had some discussion that helped clarify the intent.  I
    > just have a suggested rewording, that I *think* is entirely editorial
    > and might reduce the potential for confusion: NEW The pledge MUST
    > verify the nonce information in the voucher.  If present, the nonce in
    > the voucher must match the nonce the pledge submitted to the registrar;
    > vouchers with no nonce can also be accepted (according to local
    > policy).

okay.

    > Section 5.7

    doc>    The Status field indicates if the voucher was acceptable.  Boolean
    doc> values are acceptable.

    > voucher was acceptable""".

ok

    doc>    The version, and status fields MUST be present.  The Reason field
    doc> SHOULD be present whenever the status field is negative.  The Reason-
    doc> Context field is optional.

    > nit: no comma after "version".  nit: s/negative/false/

ok

    doc>    The keys to this JSON hash are case-insensitive.  Figure 15 shows an
    doc> example JSON.

    > 8259 standard behavior and as such would require some justification.

okay, changed this to lower case.

    > Section 5.8.1

    doc> It's hard to call Figure 17 an "example" when it doesn't conform to the
    doc> CDDL schema...

fixed.

    doc>    The domainID is a binary value calculated SubjectKeyIdentifier
    doc> according to Section 5.8.2.  It is encoded once in base64 in order to
    doc> be transported in this JSON container.

    > nit: I suggest "binary SubjectKeyIdentifier value calculated"

ok.

    > Section 5.8.2

    doc>    used as the domainID.  If not, then it is the SPKI Fingerprint as
    doc> described in [RFC7469] section 2.4 is to be used.  This value needs

    > nit: drop "is to be used" or "then it is".

ok

    > Section 5.8.3

    doc>    A relatively simple policy is to white list known (internal or
    doc> external) domainIDs.  To require all vouchers to have a nonce.

    > nit: sentence fragment.

ok.

    doc>    Alternatively to require that all nonceless vouchers be from a
    doc> subset

    > nit: comma after "alternatively".  (Hmm, this is also a sentence

ok.

    > Section 5.9.4

    doc>    In order to communicate this indicator, the client HTTP POSTs the
    doc> following to the server at the new EST endpoint at "/.well-known/est/
    doc> enrollstatus".

    > Is this supposed to be a string or a JSON object similar to

Yes, fixed this to be consistent.

    > Section 6

    doc>    When used within BRSKI, the original RFC7030 EST endpoints remain
    doc> Base64 encoded, but the new BRSKI end points which send and receive
    doc> binary artifacts (specifically, /requestvoucher) are binary.  That

    > The other two occurrences spell this "/.well-known/est/requestvoucher".

ok.

    > Section 7.2

    doc>    The following are a list of alternatives behaviours that the pledge
    doc> can be programmed to implement.  These behaviours are not mutually
    doc> exclusive, nor are they dependant upon other.  Some of these methods

    > nits: singular/plural mismatch "are"/"list"; "upon each other"

fixed.

    > nit: s/is//

already fixed.

    doc>    This is useful to support use cases where registrars might not be
    doc> online during actual device deployment.

    > "this is" with "nonceless vouchers are".

ok.

    doc>    authorized to provide this functionality to this customer.  The MASA
    doc> is RECOMMENDED to use this functionality only in concert with an
    doc> enhanced level of ownership tracking (out-of-scope.)

    > I suggest s/out-of-scope/the details of which are out of scope for this

ok.

    > Section 7.4.2

    doc>    functionality.  This provides a proof-of-proximity check that
    doc> reduces the need for ownership verification.

    > link-local connection; whether or not to reiterate that JP and
    > registrar have a trust relationship (with respect to not falsifying
    > proximity information) is less clear to me.

ok.

    > vanished or uncooperative manufacturer.

ok.

    doc>    This weaker factor reset might leave valuable credentials on the
    doc> device and this may be unacceptable to some owners.

    > nit: s/factor/factory/

ok.

    > Section 9

    doc>    Provider organizations.  Equivalent enterprises that has significant
    doc> layer-3 router connectivity also will find significant benefit,

    > nit: s/has/have/

ok.

    doc>    In the ACP, the Join Proxy is found to be proximal because
    doc> communication between the pledge and the join proxy is exclusively on

    > nit(?) My dictionary doesn't list anything for "proximal" that is a
    > good match for "with proximity"; might be worth double-checking.

I find it:
  https://www.dictionary.com/browse/proximal?r=75&src=ref&ch=dic

    doc>    asssertion is satisfied.  Other uses of BRSKI will need make similar
    doc> analysis if they use proximity.

    > nit: maybe "proximity information" or "proximity assertions".

ok.

    > Section 10.3

    doc>    While the contents of the signed part of the pledge voucher request
    doc> can not be changed, they are not encrypted at the registrar.  The
    doc> ability to audit the messages by the owner of the network a mechanism
    doc> to defend against exfiltration of data by a nefarious pledge.  Both

    > nit: missing verb ("is a mechanism", "provides a mechanism", etc.)

fixed.

    doc>    The manufacturer knows the IP address of the Registrar, but it can
    doc> not see the IP address of the device itself.  The manufacturer can not
    doc> track the device to a detailed physical or network location, only to
    doc> the the location of the Registrar itself.  That is likely to be at

    > nit: we probably don't need the last "itself".

okay.

    doc>    is likely on the same network as the device.  A manufacturer that
    doc> sells switching/routing products to enterprises should hardly be
    doc> surprised if additional purchases switching/routing products are
    doc> purchased.  Deviations from a historical trend or an establish

    > nit: we probably only need one of "purchases" and "purchased".

agreed.

    > Section 10.6

    doc>    Section Section 7.4.3 describes some ways in which a manufacturer

    > nit: duplicate "Section".

fixed.

    > Section 10.7

    doc>    existing products.  Said products might be previous deployed and
    doc> need to be re-initialized, purchased used, or just kept in a warehouse
    doc> as long-term spares.

    > nit: s/previous deployed and need/previously deployed that need/

fixed.

    > Section 11.2

    doc>    In particular implementations should pay attention to the advance in
    doc> [RFC4086] section 3, particulary section 3.4.  Devices which are reset
    doc> to factory default in order to perform a second bootstrap with a new
    doc> owner MUST NOT seed their random number generators in the same way.

    > nit: s/same way/same way across bootstraps/

fixed.

    > nit: I think these appear in the other order.

done.

    > [cabforumaudit] and [dnssecroot] probably would be fine as just

okay.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Oct 2019 16:23:57 -0400

Hi, this got quite long.
I've split this up into nits and substantive comments.
This email is about the substantive comments.
Please see a diff at: https://tinyurl.com/y5l4xz3z

Benjamin Kaduk via Datatracker <[email-masked]> wrote:
    > Thanks for the time and attention to detail put into addressing my
    > previous Discuss and Comment points.  I have one new Discuss-level
    > point and one that I think may have been missed (probably because I
    > inadvertently numbered two points with the same number).

    > (16) The audit log response (Section 5.8.1) describes the nonce as a
    > JSON string, but the RFC 8366 nonce is a binary value.  I think we need
    > to describe some mapping procedure (such as always base64-encoding as
    > is done for domainID, even if the original nonce is itself
    > base64-encoded random data) in order to be fully functional.

In the JSON mapping of the YANG, binary values are always base64 encoded, as
JSON does not support binary values.
This would be an issue in the constrained-voucher CBOR mapping through.

    > % (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.)

    > description of the contents of the POST body; there's just an example

Agreed, and there is a comment about the subjectKeyInfo.

I had opened issue: https://github.com/anima-wg/anima-bootstrap/issues/141
last week when I started writing this.

We have resolved this ticket as follows:

   The original purpose of the subjectKeyIdentifier was to indicate which
   keypair the client (pledge) had attempted to enroll. Upon successful
   enrollment, a new TLS connection is started (usually), which proves that the
   enrollment is success, and so no KeyIdentifier is needed.
   In the case of a failure, the existing TLS connection is maintained, so
   the server (Registrar) can associate the failure with the previous attempt
   to enroll.
   This change (removing the subjectKeyIdentifier) was made in -05, but the
   prose was not updated. The use of a subjectKeyIdentifier, which might no
   longer be a SHA-1 hash of a public key, is problematic, as the CSR does
   not include an appropriate KeyIdentifier, so the server would be left
   trying to calculate it, using the default (and now obsolete) SHA-1
   mechanism. Including the KeyIdentifier has proved more trouble than
   benefit.

Esko has complained that we have 14 open issues; that's probably negligence
on my part about not closing them as we solved the issues.
So we also closed all but three "auth48" tickets that had been opened.

    > talk to the Join Proxy using link-local network connectivity.  In most
    > cases, the pledge has no other connectivity until the pledge completes
    > the enrollment process and receives some kind of network credential.

    > I'd consider s/can talk to/is assumed to talk to/.

okay.  some have complained this isn't strong enough.
Maybe MUST talk to?

    > % The "proximity-registrar-cert" leaf is used in the pledge voucher- %
    > requests.  This provides a method for the pledge to assert the %
    > registrar's proximity.
    > %
    > % "proximity" in what sense?  How much verification/confidence needs to
    > be % done?  (Also, I would have expected the assertion to go the other
    > way; % that the registrar asserts the pledge's proximity -- how does
    > the pledge % have a way to know that the registrar is nearby when the
    > proxy is % transparent?)

    > Making that an explicit assumption would be helpful.

I have added the following text to make this assumption explicit:

+      <t>
+        This network proximity results from the following properties in the
+        ACP context:  the pledge is connected to the Join Proxy
+        (<xref target="proxydetails" />) using a Link-Local IPv6 connection.
+        While the Join Proxy does not participate in any meaningful sense in
+        the cryptography of the TLS connection (such as via a Channel
+        Binding), the Registrar can observe that the connection is via the
+        private ACP (ULA) address of the join proxy, and could not come from
+        outside the ACP.  The Pledge must therefore be at most one IPv6
+        Link-Local hop away from an existing node on the ACP.
+      </t>
+      <t>
+        Other users of BRSKI will need to define other kinds of assertions if
+        the network proximity described above does not match their needs.
+      </t>

====

    > here), such as Section 4 of RFC 4648.

And to the lead in, I've referenced RFC4648, which this is the first
reference to base64.

         <section title="Examples" anchor="voucher-request-examples">
             <t>This section provides voucher-request examples for illustration
-                purposes.  The contents of the certificate have been elided
+                purposes.  JSON encoding rules specify that any binary
+                content by base64 encoded (<xref target="RFC4648" />).
+                The contents of the certificate have been elided

    > How painful would it be to require 1.3 at this point?  RFC 8446 has
    > been out for more than a year, and the TLS WG is leaning on me to
    > tighten up on this...

Yes, but how many FIPS-140 validated TLS 1.3 implementations are there that
are drop-in available to router platforms with 3-5 year R&D cycles?
OpenSSL is FIPS for 1.0.1 and 1.0.2 which do not include TLS 1.3, for
instance (which is 1.1.x).
WolfSSL has FIPS-140 for TLS 1.3 (to read the press releases), and some
entities could drop it in, but others might have license issues.

How about if I change the text to say:

              Use of TLS 1.3 (or newer) is encouraged.
              TLS 1.2 or newer is REQUIRED on the Pledge side.
              TLS 1.3 (or newer) SHOULD be available on the Registrar server interface,
              and the Registrar client interface, but TLS 1.2 MAY be used.
              TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS
              1.2 MAY be used.

Getting TLS 1.3 on a web framework platform is not that hard if it does not
need FIPS-140.  Mandating that 1.3 be available reduces the domino effect
that keeps systems from organically upgrading.

    doc>    IDevID certificate is out-of-scope of this specification.  Note that
    doc> the trust anchors in/excluded from the database will affect which
    doc> manufacturers' devices are acceptable to the registrar as pledges, and
    doc> can also be used to limit the set of MASAs that are trusted for
    doc> enrollment.

    > anchor databases into this discussion as well.

I think that there are a bunch of considerations which go rather far into how
the domain owner wants to operate things.   I have started a document:
    Operational Considerations for BRSKI Registrar

but, it's just a shell so far.

    > Section 5.4

    doc>    Section 2.8.  The mechanisms in [RFC6125] SHOULD be used
    doc> authentication of the MASA.  Some vendors will establish explicit (or

    > nit: s/used/used for/ Also, we tend to require that people using 6125
    > specify what name type in the cert to verify (e.g., DNS-ID) against
    > what expected name.  It would be pretty easy to convince me that we
    > don't need to do that here, though.

diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index 8f82c58..4394881 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -1912,9 +1912,14 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
           connection and uses the MASA URL obtained as described in
           <xref target="obtainmasaurl" />. The mechanisms in
           <xref target="RFC6125" /> SHOULD be used authentication of the
-          MASA.  Some vendors will establish explicit (or private) trust
-          anchors for validating their MASA; this will typically done as
-          part of a sales channel integration.
+          MASA using a DNS-ID that matches that which is found in the IDevID.
+          Registrars MAY include a mechanism to override the MASA URL on a
+          manufacturer-by-manufacturer basis, and within that override it is
+          appropriate to provide alternate anchors.
+          This will typically used by some vendors to establish explicit
+          (or private) trust
+          anchors for validating their MASA that is part of a sales channel
+          integration.
         </t>

    > SHOULD be included in the registrar voucher-request.  The entire CMS
    > signed structure is to be included, base64 encoded for transport in the
    > JSON structure.

    > I think we need a ref for (which) base64.

I looked through.
RFC8366 does not reference RFC7951 (it should), which explains JSON
serialized YANG.  RFC7951 and RFC7950 specify original base64.
{I am annoyed that we aren't using base64url in a Postel-rule compatibility
mode everywhere...}

Section 3.3 already referenced 7951, btw

I have added the text to section 5:
   BRSKI uses existing CMS message formats for existing EST operations.
   BRSKI uses JSON [RFC8259] for all new operations defined here, and
   voucher formats.  In all places where a binary value must be carried
   in a JSON string, the use of base64 format ([RFC4648] section 4) is
   to be used, as per [RFC7951] section 6.6.

    > Section 5.5.2

    doc>    The registrar's certificate chain is extracted from the signature
    doc> method.  The entire registrar certificate chain was included in the CMS
    doc> structure, as specified in Section 5.5.  This CA certificate will be
    doc> used to populate the "pinned-domain-cert" of the voucher being issued.

    > the implication just that you don't send the rest of the chain)?

Yes.
1) There may not be a global root CA for the organization.  It could be self-signed.
2) The registrar gets to decide which thing it wants pinned.
3) The pledge is expected to have enough certificate chaining to deal with
   either situation.  (This has changed: at one point memcmp() was considered enough)
4) the EST /cacerts request lets the Pledge "upgrade" to an organizational anchor.

    > Section 5.5.6

    doc>    The MASA populates the audit-log with the nonce that was verified.
    doc> If a nonceless voucher is issued, then the audit-log is to be populated
    doc> with the JSON value "null".

    > The quotes around "null" are perhaps anti-helpful.

_null_ is a JSON literal.   Are you complaining that some people might write:
       nonce: "null"
rather than
       nonce: null
?

    > Section 7.3

    doc>    A registrar can choose to accept devices using less secure methods.
    doc> These methods are acceptable when low security models are needed, as
    doc> the security decisions are being made by the local administrator, but

    > come up with is "threat models where low security is adequate".

Does this work for you:

7.2.  Pledge security reductions

-   The following are a list of alternatives behaviours that the pledge
-   can be programmed to implement.  These behaviours are not mutually
-   exclusive, nor are they dependent upon other.  Some of these methods
-   enable offline and emergency (touch based) deployment use cases.
-   Normative language is used as these behaviours are referenced in
-   later sections in a normative fashion.
+   The following is a list of alternative behaviours that the pledge can
+   be programmed to implement.  These behaviours are not mutually
+   exclusive, nor are they dependent upon each other.  Some of these
+   methods enable offline and emergency (touch based) deployment use
+   cases.  Normative language is used as these behaviours are referenced
+   in later sections in a normative fashion.

    > Section 7.4.1

    doc>    and/or not requiring one to be present in the voucher-request.  This
    doc> results in distribution of a voucher that never expires and in effect

    > some additional wordsmithing is in order.

A Pledge will not, in general, have a real time clock it can rely on.
A nonced voucher is fresh, while a nonceless one is not.
I have changed this to:

            This
            results in distribution of a voucher that may never expire and in

I find it:

    > % Rm would have to attack the pledge and return it to a bootstrapping %
    > enabled state.  This would require wiping the pledge of current
    > %
    > % ... and I think there is a different attack if the Rm is in a
    > position % to delay or drop network traffic between the pledge and the
    > intended % registrar, to cause Rm's voucher to be delivered first even
    > though it is % generated after the intended registrar's authorization
    > process.  The % intended registrar would need to require reports on
    > voucher processing % status (or investigate their absence) in order to
    > detect such a case.

    > but I can't remember if we decided that we didn't need to discuss the

I think that the explanation if pretty complete.

    > properly use that assigned OID now?

We got a MASA URL Extension OID for:
   1.3.6.1.5.5.7.1.32

the examples date from before that, and do not use it yet.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 23 Oct 2019 22:36:36 -0700

> Please see a diff at: https://tinyurl.com/y5l4xz3z

Thanks; I'll put some editorial nits at the end of this message.

> JSON does not support binary values.

I apparently forgot that we were going through a YANG->JSON encoding when I
wrote the above, sorry for that.  But thank you for the extra reminders
about base64-encoding that are in the latest copy.

>    mechanism. Including the KeyIdentifier has proved more trouble than

The removal of SKI seems okay, but I'm still looking for something like
"the body of the POST is a JSON object with the following [whoops, I forget
the right terminology for name/value pairs]"

> okay.  some have complained this isn't strong enough.

I don't have a strong opinion on this, but it feels like something that
will probably be different for ACP vs. other deployments -- MUST feels
right for ACP but is probably not universal.

> +        the network proximity described above does not match their needs.

Thank you!

> instance (which is 1.1.x).

I take it that FIPS-140 validation is required for those $100k BFRs, then?

>               TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS

That's an okay compromise on the 1.3-encouragement front, but I don't think
that everyone will read "Foo server interface" and "Foo client interface"
in the same way.

> but, it's just a shell so far.

Okay.

> _null_ is a JSON literal.   Are you complaining that some people might write:

I am indeed.  Perhaps "the JSON primitive null", but I'm starting to think
I should stop trying to wordsmith this...

> +   in later sections in a normative fashion.

(That diff is fine with me, though it's the wrong one.  What's in the
linked diff for Section 7.3 is also fine.)

>             results in distribution of a voucher that may never expire and in

Thanks.

>   https://www.dictionary.com/browse/proximal?r=75&src=ref&ch=dic

I mean, my dictionary finds it *as a word*, just not with a definition that
looks great for how you're using it here.

> We got a MASA URL Extension OID for:

I will update my Discuss position to help us remember.

editorial nits on the linked diff:

Section 2.5.3 talks about the set of MASA that are trusted being limited
by the MASA TA database, but in the paragraph about the BRSKI-EST client
TA database.

s/described Appendix B/described in Appendix B/ (sorry, section number
not visible from diff; maybe 40% through the diff)

Section 5.4 is missing an "for" in "SHOULD be used for authentication of
the MASA".

s/accesptable/acceptable/

Figure 17 is introduced as an "abstract example", though it seems more
of a concrete one after this diff.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Oct 2019 17:50:10 -0400

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

I guess maybe unidirectional towards the Pledge makes more sense.
(Some would argue that the Pledge contains trust anchors pointing at the
Vendor)

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

    > have the option of being nonceless.  So, this seems okay as-is, right?

Correct.

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

ok.

    > Section 2.3.1

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

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

Thank you.

    > Section 2.4

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

okay.

    > Section 2.8

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

ok.

    > Section 3

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

    > nit: semantics of vouchers, or voucher requests?

voucher-requests, fixed.

    > Section 3.3

    doc> Figure 6: JSON representation of example Voucher-Request

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

I've added:
     These examples show the JSON prior to CMS wrapping.

to the intro.

    > Section 3.4

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

    > voucher-request to registrar voucher-request?

Clarified to say:

        description "Any assertion included in registrar voucher
              requests SHOULD be ignored by the MASA.";

The assertion in the prior-signed-voucher-request (or Pledge Voucher-Request)
may well be examined by the MASA.

    > Section 4.1

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

okay.

    > Section 5

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

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

changed to:
            <t>
              The pledge requests a voucher using
              the new REST calls described below.  This voucher is then validated.
            </t>

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

    > I suggest "validates and forwards" to cover the case where the registrar

the whole text is:
          <t>The registrar requests and validates the voucher from the MASA.</t>

          <t>The registrar forwards the voucher to the pledge when
          requested.</t>

so validates is already in the previous point, I think.

    > Section 5.2

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

    > parenthetical, not before.)

reworked some text.

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

    > field that's populated with the value "proximity".

we have reworked the text, including the assertion and text.

    > Section 5.5

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

    > (Just to be clear, the serial-number field is optional in the pledge's

We have a discussion last week about this.
We are making it mandatory; it is to be used as check against what is in the
IDevID.  We had made it optional to avoid repeating and dealing with what if
it not equal, but realized that we wanted it as a safety check.

    > Section 5.6.2

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

    > nit: only one of these "inconsistently"s is correct; the others should

okay

    > Section 5.8

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

    > unauthenticated clients).

That's what's intended.

    > Section 5.8.2

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

okay.

    > Section 5.9

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

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

It was "RESTful" that was disliked, and we reference "REST", and I've changed
these to API calls.

    > Section 7.3

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

    > given the potential for an expiration date in a nonceless voucher.

s/permanent/offline/

    > Section 7.4.3

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

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

agreed, changed.

    > a domain that already exists.

Right now, that's in:

5.8.2.  Calculation of domainID

   The domainID is a binary value (a BIT STRING) that uniquely
   identifies a Registrar by the "pinned-domain-cert"

   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, 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).

We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to
replace it appropriately.

    > Section 11.2

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

    > so it's not clear this is actually true.

We don't think that the voucher nonce has to be of the same quality as something that
goes into a KDF.  It is at the level of TCP Sequeunce number, not seed for
generating a private key...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 28 Oct 2019 20:18:43 -0700

Trimming heavily, with great thanks for the numerous updates...

>     > mostly-duplicate contents would be confusing.
[...]
> so validates is already in the previous point, I think.

Indeed.  Apparently the page break caused me to forget; sorry for the noise
:(

>     > unauthenticated clients).

I can see why that functionality is needed, but it seems likely to
introduce some privacy and/or security considerations to document.  It's a
bit too late in the day for me to reason through them, though.

> replace it appropriately.

That's all good and admirable; I'm suggesting that we add a note in the
security considerations of this document noting that we rely on the
domainID (however determined) to be second-preimage-resistant.

> generating a private key...

I mean, we literally say "Reducing the possibility of this is why the
pledge is mandated to generate a strong random or pseudo-random number
nonce."  So to also say "the nonce [...] does not require a strong
cryptographic randomness" seems to be in conflict with the former
statement.
Are you saying that "strong random" and "strong cryptographic random" mean
different things, or am I misreading the document in some other way?

Thanks,

Ben

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Oct 2019 07:32:59 +0100

Hi,

> On 29 Oct 2019, at 04:18, Benjamin Kaduk <[email-masked]> wrote:
> 

I would just drop the statement.  The whole point of the nonce is to prevent replay attacks, so why would we want to weaken that?

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Oct 2019 12:08:14 -0400

> bit too late in the day for me to reason through them, though.

I think that they are in fact documented!

    > domainID (however determined) to be second-preimage-resistant.

The voucher is not pinned to the domainID, but to the actual certificate.
Distinguishing the domainID for a moment from the thing in the certificate
that hashes the public key when it is signed, if a second-preimage attack
against the domainID would allow phony entries to be placed in the audit log.

Assuming that the domainID is calculated using the same hash that is used in
the certificate signature, then a second-preimage attack would break all of
the certificates, period.

I have added a section saying this, but it seems that our reference to
RFC7469 already deals with this.

    > different things, or am I misreading the document in some other way?

A Cryptographically Strong Sequence is more than enough. (section 6.2 of RFC4086).
We don't need a "unguessable random number" (seed) section 5.
Maybe I'm splitting hairs here.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Oct 2019 12:09:40 -0400

> I would just drop the statement.  The whole point of the nonce is to
    > prevent replay attacks, so why would we want to weaken that?

I don't want someone to think that they need to include an additional
source of hardware entropy just for the nonce.  They already need a well
seeded PRNG (RFC4086) for TLS operation, and that's more than enough.