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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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?