Bootstrapping Remote Secure Key Infrastructures (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-30

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Alissa Cooper (was No Objection, Discuss) Discuss

Discuss (2019-10-16 for -28)
Apologies for the multiple emails, I failed to realize there was a new Gen-ART review for this document. The follow-up from the Gen-ART review seems to indicate that a YANG doctor review of this document is needed and/or that the YANG issues raised by Tom Petch need fixing. Is there a plan to get either of those done?
Comment (2019-10-16 for -28)
Thanks for addressing my original DISCUSS points. 

Please respond to the full Gen-ART review.

Original COMMENT below.

------

I think this document would benefit from two concise lists, with notes about which items in each list are defined in this document and which ones are not defined: (1) what is operationally required of a manufacturer to support BRSKI, and (2) what is operationally required of a domain owner to support BRSKI.

= Section 2.3.1 =

What precisely is meant by "TPM identification"? Could a citation be provided?

= Section 10.1 =

"The domain can maintain some privacy since it has not necessarily been
   authenticated and is not authoritatively bound to the supply chain."

What does this mean? That the domain can expect the manufacturer not to trust the domainID because it hasn't been authenticated?

= Section 10.2 =

"The above situation is to be distinguished from a residential/
   individual person who registers a device from a manufacturer: that an
   enterprise/ISP purchases routing products is hardly worth mentioning.
   Deviations would, however, be notable."

What does the last sentence mean?

Benjamin Kaduk Discuss

Discuss (2019-10-28 for -29)
% (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.

The -29 reworks the definition of the 'nonce' field to be:

      strong random or pseudo-random number nonce (see [RFC4086] section
      6.2).  As the nonce is usually generated very early in the boot
      sequence there is a concern that the same nonce might generated
      across multiple boots, or after a factory reset.  Difference
      nonces MUST NOT generated for each bootstrapping attempt, whether
      in series or concurrently.  The freshness of this nonce mitigates
      against the lack of real-time clock as explained in Section 2.6.1.

This needs to either be "Different nonces MUST be generated" or
"the same nonce MUST NOT be reused"; this mashup is no good.

Email exchange with mcr notes:
>     > 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?
> 
> 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.

We need to fix the examples before publication.
Comment (2019-10-28 for -29)
[A few comments on the -29, some of which I think might be repeats of
ones I made on a WIP interim draft; sorry if I say something again that was
already debunked.  The comment section from the -28 is preserved later.]

Thanks for sorting the definitions; I didn't verify that the text remained
the same in the reordering

In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies both
base64 and base64url, so a section reference is usually appropriate (and
in Section 5 we do give a section reference into RFC 4648).

s/accesptable/acceptable

figure 17 seems to no longer be an "abstract example" but rather a concrete
one.

Section 9.1

   Other use cases likely have similar, but MAY different requirements.

nit: ", but MAY have different, requirements"

Section 9.1.1

   Authentication process.  The MASA creates signed voucher artifacts
   according to a it's internally defined policies.

nit: s/a it's/its/

Section 9.1.3

(Do we need to say "DULL" specifically again here for Join Proxy discovery?
Maybe not...)

[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?

=======================================================================
Additional comments since posted ballot position on -28

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.

Ignas Bagdonas Yes

Deborah Brungard No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2019-11-05 for -29)
Thank you for addressing my previous DISCUSS and COMMENTS.

I remain concerned that the current text continues to only normatively specify the behavior in the first part of the lifecycle that BRSKI-enabled equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business.  I appreciate that this scope is the consensus of the WG.  Therefore, thank you for all of the efforts made in recent version of the draft to more substantively document (if not fully specify) these later lifecycle activities.  

** Abstract.  Per “Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged.”, the rational for the lower security models as described in Section 7 do not appear to be “legacy”.

** Section 1.5  Per “Upon successfully validating a voucher artifact, a status telemetry MUST be returned.  See Section 5.7.”  Is a “voucher artifact” the same as a “voucher”?
		 	
** Section 5.9.4. Per “In the case of a SUCCESS the Reason string is omitted.  The SubjectKeyIdentifier is included so that the server can record the successful certificate distribution.”.  Given the single example in Figure 18, it isn’t clear how to represent the SubjectKeyIdentifier in JSON.

** Section 10.3.  Per “[t]he so-called "call-home" mechanism that occurs as part of the BRSKI-MASA connection standardizes what has been deemed by some as a sinister mechanism for corporate oversight of individuals. ([livingwithIoT] and [IoTstrangeThings] for a small sample).”

-- Thanks for including this text about the “call-home” mechanism.  However the references don’t seem like a fit.  Both references appear to focus on the regular “call home” activity of these device rather than the narrow, on-time one-time onboarding process.  The nature of the “call-home” isn’t just about privacy (as these articles imply), but also lock-in.

-- It isn't appropriate to characterize concerns about the BRISKI-MASA link as “sinister mechanisms ...”.

** Section 10.7.  Per “It is anticipated that specialist service providers will come to exist that deal with the creation of vouchers in much the same way that many companies have outsourced email, advertising and janitorial services.”, I don’t think this is a fair analogy.  Delegating the voucher process to an entity would take active cooperation of the manufacturer.  If the manufacture is out of business, there is not guarantee this would have been put in place (or those assets were acquired in the liquidation)

** Section 11.5.2.2 prescribes that the operator of a MASA “MUST issue a firmware update to all devices that had that key as a trust anchor”.  This suggests a required capability to update trust anchors.  However, Section 7.4.3 discusses a similar (albeit more flexible) practice but this is non-normative and deemed reduced security.  Why the dissidence?

** Please respond to Christian Huitema’s new SECDIR review items (thank you again, Christian!) on clarifying the TLS version negotiation and certificates for MASA authentication.

** Editorial Nits:

Section 3.4.  Typo. s/occurence/occurrence/

Section 4.  These sentences didn’t parse for me – “This section applies is normative for uses with an ANIMA ACP.   The use of GRASP mechanism part of the ACP.”

Section 4.  Reference expansion issue?.  s/{{RFC8446}}/[RFC8446]/

Section 5.1.  Typo.  s/progess/progress/

Section 5.2.  Editorial. Per “The media type is the same as defined in [RFC8366].  and is also …”, the start of the second sentence shouldn’t be “and is …”

Section 5.2. Editorial.  s/then there a On-Path Attacker (MITM)/then there is an On-Path Attacker (MITM)/

Section 4.1.  Recommend clarity on the non-normative behavior.  s/While the GRASP M_FLOOD mechanism is passive for the pledge, the optional other methods (mDNS, and IPv4 methods) are active./While the GRASP M_FLOOD mechanism is passive for the pledge, the non-normative, optional methods (mDNS, and IPv4 methods) described in Appendix A are active./

Section 5.7.  Editorial
s/The client HTTP POSTs the following to the server at the URI ".well-known URI "/voucher_status"./
The client sends an HTTP POSTs to the server at the URI ".well-known URI "/voucher_status".

Section 7.2.  Typo.  s/dependant/dependent/

Section 7.4.1. Typo.  s/A MASA has the option of not including a nonce is in the voucher/A MASA has the option of not including a nonce in the voucher/

Section 7.4.2.  Typo.  s/ nuissance/nuisance/

Section 7.4.3.  Typo. s/overwitten/overwritten/

Section 7.4.3.  Typo.  s/responsability/responsibility/

Section 10.2.  Duplicate word. s/the the/the/

Section 10.2. Typo. s/ arbitrary/ arbitrary/

Section 10.2 Typo. s/coorelate/correlate/

Section 10.3.  Typo. s/the the/the/

Section 10.4.  Typo. s/absense/absence/

Section 10.6.  Typo. s/gratuitiously/gratuitously/

Section 10.6.  Duplicate Word. s/Section Section/Section/

Section 10.6.  Duplicate Word. s/an an/an/

Section 11.2. Typo. s/particulary/particularly/

Section 11.3.  Typo.  s/occurence/occurrence/

Section 11.5.  Typo. s/proceedures/procedures/

Section 11.5. Sometime is amiss with reference expansions – s/{{cabforumaudit}}/[CABFORUMAUDIT]/ and s/{{dnssecroot}}/[DNSSECROOT]/

Section 11.5.2.1.  Typo. s/opportunies/opportunities/

==[ summary of old DISCUSS ]==
(1) Section 5.7.  The format of a pledge status telemetry message seems underspecified. 

(2) Section 5.8.1.  The format of the MASA audit log seems underspecified.  Is the JSON snippet presented here normative to describe the MASA audit log response?

(3) Why is Section 7.x in this document if it explains how to use BRSKI but is considered non-normative? 

(4) Thank you for documenting “manufacturer control issues” in Sections 10.3 and 10.4.  It helpfully lays justifies the current design approach.  I strongly concur with the premise that “facilitate[ing] a few new operat[i]onal modes without making any changes to the BRSKI protocol” is exactly what is needed.  

My concern is that even with the current applicability statement in Section 9, the current text appears to have only standardized the first part of the lifecycle that BRSKI equipment might see -- equipment on first sale as long as the manufacturer supports it or stays in business.  The text doesn’t appear to cover the practical aspects of the proposed mitigations in Section 10.5 or the situations described in Section 10.3/10.4 – various situations possible in the full lifecycle usage of a BRSKI device and needed support the “additional operational modes”.  Specifically:

** There appears to be little discussion on how owners/manufacturers/vendors can facilitate second sale/used equipment beyond narrative words (in Section 10.3 and 10.4)

** There is appears to be little discussion on how to practically implement a MASA (i.e., the offline use case).  For example, (Per Section 10.5) “A manufacturer could provide a mechanism to manage the trust anchors and built-in certificates (IDevID) as an extension.  This is a substantial amount of work, and may be an area for future standardization work”.  Without the ability to change anchors on the device the additional operational modes such as offline mode seems challenging.

Suresh Krishnan No Objection

Comment (2019-07-10 for -22)
I support Eric, Roman and Alissa's DISCUSS positions.

Warren Kumari (was Recuse) No Objection

Comment (2019-10-15 for -28)
I initially balloted Recuse as I'm the author of a similar document "Secure Device Install" (draft-ietf-opsawg-sdi) - after discussions and consideration I'm changing my position to No Objection; my document addresses a small slice of the problem space.

My initial Recuse also contained a bit of a soapbox rant about the ability of users to buy and use old equipment (avoiding having network gear become a "subscription" service). I'm still somewhat twitchy about this, but am balloting NoObj anyway.

Mirja Kühlewind No Objection

Comment (2019-07-11 for -22)
I agree with Alissa's discuss that the conclusion of section 10(.3) should be to recommend a manual configuration mode. Also with respect to section 10.2: if ownership is "enforced" by the manufacturer, there should also probably be a way for the buyer to check if ownership was transferred by the saler during the re-sale process.

Two other small comments on more load related points:

1) sec 4.1: "Connection attempts SHOULD be run in parallel to avoid head of queue
   problems wherein an attacker running a fake proxy or registrar could
   perform protocol actions intentionally slowly.  The pledge SHOULD
   continue to listen to for additional GRASP M_FLOOD messages during
   the connection attempts."
One minor comment: Maybe also say explicitly, while running in parallel, one should not send all initial messages at exactly the same time but pace  them out (e.g. one every 3 secs) to avoid network overload when initial connectivity is very constraint.

2) sec 4.3: " It must
   be sufficiently low that the aggregate amount of periodic M_FLOODs
   from all EST servers causes negligible traffic across the ACP."
I know this is a little bit a blurry requirement but I would still like to see a MUST here. Or maybe give an upper bound for the maximum frequency, e.g. MUST NOT send more than once per minute...? Not sure it there is a reasonable value here.

Barry Leiba No Objection

Comment (2019-07-10 for -22)
I support the comments that Warren makes in his ballot, and related comments in Alissa’s DISCUSS.  While simple device provisioning and onboarding is critical, especially in IoT scenarios, I, too, have serious concerns about how such setups can allow too much control by vendors of the use that legitimate buyers can make of the products they bought.

That said, I am balloting “no objection”, because I don’t think that my opinion on that overrides the consensus of the working group and the IETF community, and we and other SDOs are working on alternative mechanisms to do similar things.

Alexey Melnikov (was Discuss) No Objection

Comment (2019-10-16 for -28)
Thank you for addressing my DISCUSS points.

Some comments below were still applicable to -27, but some might be out of date.

In 2.3.2:

   As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
   this extension, including the scheme, iauthority, and ipath.  As a
   consideration to constrained systems, this MAY be reduced to only the
   iauthority, in which case a scheme of "https://" and ipath of
   "/.well-known/est" is to be assumed, as explained in section
   Section 5.

This is not a problem per se, but mixing absolute URIs and iauthority in the same field makes me rather uncomfortable. Maybe you can define ABNF for this field to make it crystally clear what is allowed here.
This would also avoid the need to use SHOULD and MAY above.

In 2.3.2: "https" URI scheme needs a Normative reference.

2.7.  Cloud Registrar

   If the pledge uses a well known URI for contacting a cloud registrar
   an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
   authenticate service as described in [RFC6125].

Just referencing RFC 6125 is not clear enough, as there are lots of parameters that need to be specified:

 a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
 b) are wildcards allowed in any of these?

Alvaro Retana No Objection

Comment (2019-10-16 for -28)
(1) §1.3.2 (Constrained environments): "Those types of networks SHOULD NOT use this solution."  The use of Normative language seems out of place: if this document is not applicable to constrained environments, then there's no way to enforce (SHOULD NOT)...   s/SHOULD NOT/should not

(2) §2.1: In Figure 2, should the "rejected" action be a result of step 3 (instead of 2)?

   |                   |
   |            +------v-------+
   |            | (2) Identity |
   ^------------+              |
   | rejected   +------+-------+
   |                   |
   |            +------v-------+
   |            | (3) Request  |
   |            |     Join     |
   |            +------+-------+
   |                   |


(3) s/The serialNumber fields is defined in [RFC5280], and is a SHOULD field in [IDevID]./The serialNumber field is defined in [RFC5280], and is a recommended field in [IDevID].   Note that SHOULD is not used properly here because it does not have a Normative quality (as it refers to the other document).  I'm assuming that the replacement is "recommended" (per rfc2119), but it may be "required".


(4) [nits]

s/Bootstrapping to is complete/Bootstrapping is complete

§1: "This bootstrap process satisfies the [RFC7575] section 3.3 of making all operations secure by default."  Satisfies the what?  Requirement, maybe?

s/explains the details applicability/explains the detailed applicability

s/out-of-band" information"/out-of-band" information

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

s/RFC XXXX: Manufacturer Usage Description Specification/RFC 8520: Manufacturer Usage Description Specification

s/might be previous deployed/might be previously deployed

s/were receives by/were received from

s/{{...}}/[...]

Adam Roach (was Discuss) No Objection

Comment (2019-08-29 for -26)
Thanks for addressing my DISCUSS points.

Martin Vigoureux No Objection

Éric Vyncke (was Discuss) No Objection

Comment (2019-08-30 for -26)
Thank you for addressing my previous DISCUSSes and COMMENTs


-éric

Magnus Westerlund (was Discuss) No Objection