Skip to main content

Bootstrapping Remote Secure Key Infrastructure (BRSKI)
draft-ietf-anima-bootstrapping-keyinfra-45

Yes

Warren Kumari
(Ignas Bagdonas)

No Objection

(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)

Note: This ballot was opened for revision 22 and is now closed.

Warren Kumari
(was No Objection, Recuse) Yes
Roman Danyliw
(was Discuss) No Objection
Comment (2019-11-05 for -29) Sent for earlier
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.
Éric Vyncke
(was Discuss) No Objection
Comment (2019-08-30 for -26) Sent
Thank you for addressing my previous DISCUSSes and COMMENTs


-éric
Benjamin Kaduk Former IESG member
(was Discuss) Yes
Yes (2020-04-02 for -40) Sent
Thanks for putting in all the work to get this over the finish line!
I did a final read-through before entering my YES, which produced some
non-blocking comments.

Section 5.1

   The signatures in the certificate MUST be validated even if a signing

nit: just "signature" singular?

Section 5.2

   assertion:  The pledge indicates support for the mechanism described
      in this document, by putting the value "proximity" in the voucher-
      request, and MUST include the "proximity-registrar-cert" field
      (below).

Sorry if I asked this already, but is the "MUST include" only when the
"proximity" assertion is used?  The current text could be read that it
applies always.

Section 5.4

It's too bad we can't mention SCRAM in addition to Basic and Digest, but I
guess that ship has sailed.

Section 5.5

   The voucher media type "application/voucher-cms+json" is defined in
   [RFC8366] and is also used for the registrar voucher-request.  It is
   a JSON document that has been signed using a CMS structure.  The
   registrar MUST sign the registrar voucher-request.
   [...]
   [...]
   [...]
   MASA impementations SHOULD anticipate future media types but of
   course will simply fail the request if those types are not yet known.

I think these two paragraphs were originally next to each other but with the
large amount of intervening text it seems like the transition could be
improved.

Section 5.5.2

   A certificate chain is extracted from the Registrar's signed CMS
   container.  This chain may be as short as a single End-Entity

(I guess technically the CMS structure is an unordered set of certificates,
not a chain, but we're using it as a chain so I don't mind this usage.)

   The MASA MAY use the highest certificate from the certificate chain
   that it received from the Registrar, as determined by MASA policy.  A

"highest certificate" is not a particularly common usage; "farthest in the
chain from the end entity" might be more conventional.

Section 5.5.3

   As described in Section 5.5.2, the MASA has extracted Registrar's
   domain CA.  This is used to validate the CMS signature ([RFC5652]) on
   the voucher-request.

   Normal PKIX revocation checking is assumed during voucher-request
   signature validation.  This CA certificate MAY have Certificate
   Revocation List distribution points, or Online Certificate Status
   Protocol (OCSP) information ([RFC6960]).  If they are present, the

We could maybe wordsmith this a bit to only cover the case when the
pinned-domain-cert is a CA cert (vs. end entity).

Section 5.5.4

This section mentions that checking for the presence of id-kp-cmcRA in the
registrar's cert protects the domain in some cases, but that protection is
probably weakend in cases when the pinned-domain-cert is not the domain's
root CA.  That said, the failure mode is not catastrophic, since the
registrar still has to authenticate to the MASA somehow, and the MASA logic
can account for the different cases.

Section 5.6

   correct registrar, the pledge MUST NOT follow more than one
   redirection (3xx code) to another web origins.  EST supports

s/web origins/web origin/

Section 5.6.1

 missing close parenthesis for "(according to local policy[...]"

Section 5.8.2

   The domainID is determined from the certificate chain associated with
   the pinned-domain-cert and is used to update the audit-log.

Is it determined from the "chain associated with" or just the
"pinned-domain-cert" itself?

Section 7.1

   Join Proxy:  Provides proxy functionalities but is not involved in
      security considerations.

The Join Proxy is not involved in crypto, as noted here, but could drop or
delay traffic.

Section 7.3

       X.509 IDevID factory installed credential.  New Entities without
       an X.509 IDevID credential MAY form the Section 5.2 request using
       the Section 5.5 format to ensure the pledge's serial number
       information is provided to the registrar (this includes the
       IDevID AuthorityKeyIdentifier value, which would be statically
       configured on the pledge.)  The pledge MAY refuse to provide a

It's not entirely clear to me why "(this includes the IDevID
AuthorityKeyIdentifier value" holds (it's not in the idevid-issuer, I
think), but if it's clear to others that's fine.

Section 9.1.1

   full sales channel integration where Domain Owners need to be
   positively identified by TLS Client Certicate pinned, or HTTP

I'm not sure if this was intended to be "by a pinned TLS Client Certificate" or
"by the pinned-domain-cert".

Section 10.3

It looks like the second paragraph may be an editing remnant (copy of text
being modified in the first paragraph).

Section 11.6.2.1

I guess the vouchers created by an attacker with access to the MASA signing
key would not necessarily be in the audit log, which is probably worth
mentioning.

Appendix B

   Discovery of registrar MAY also be performed with DNS-based service
   discovery by searching for the service "_brski-
   registrar._tcp.<domain>".  In this case the domain "example.com" is
   discovered as described in [RFC6763] section 11 (Appendix A.2
   suggests the use of DHCP parameters).

Is there a mismatch between "<domain>" and "example.com"?
Ignas Bagdonas Former IESG member
Yes
Yes (for -22) Unknown

                            
Adam Roach Former IESG member
(was Discuss) No Objection
No Objection (2019-08-29 for -26) Sent for earlier
Thanks for addressing my DISCUSS points.
Alexey Melnikov Former IESG member
(was Discuss) No Objection
No Objection (2019-10-16 for -28) Sent
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?
Alissa Cooper Former IESG member
(was Discuss, No Objection, Discuss) No Objection
No Objection (2020-01-24 for -34) Sent
Thanks for addressing Tom Petch's comments about the YANG.

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?
Alvaro Retana Former IESG member
No Objection
No Objection (2019-10-16 for -28) Sent
(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/{{...}}/[...]
Barry Leiba Former IESG member
No Objection
No Objection (2019-07-10 for -22) Sent
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -22) Not sent

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (for -22) Sent for earlier

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -28) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-07-11 for -22) Sent
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.
Suresh Krishnan Former IESG member
No Objection
No Objection (2019-07-10 for -22) Not sent
I support Eric, Roman and Alissa's DISCUSS positions.