Bootstrapping Remote Secure Key Infrastructures (BRSKI)

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 (2020-01-03 for -33)
I think we're down to just:

Email exchange with mcr notes:
>     > An RFC Editor note about the RFC 8366 assignment of OID
>     > 1.2.840.113549. was removed from -23 to -28; do the examples
>     > properly use that assigned OID now?
> We got a MASA URL Extension OID for:
> the examples date from before that, and do not use it yet.

We need to fix the examples before publication.
Comment (2020-01-03 for -33)
No email
send info
[COMMENT unchanged from -31 and probably all stale]

A few new comments on the -30 and -31 to start.  I think some of my comments
on the -29 are still valid, and will try to remove ones that have been addressed.
To reiterate: to the best of my knowledge, all the comments in this ballot position
are actionable and have not been overtaken by events.

In Section 5.9.4:

   In the case of a FAIL, the same TLS connection MUST be used.  The
   Reason string indicates why the most recent enrollment failed.

I'd suggest something more like "In the case of a failed enrollment, the
client MUST send the telemetry information over the same TLS connection
that was used for the enrollment attempt, with a Reason string indicating
why the most recent enrollment failed.  (For failed attempts, the TLS
connection is the most reliable way to correlate server-side information
with what the client provides.)"
(Also, why is "FAIL" capitalized?)

Thanks for the text in Section 11.2 about second-preimage-resistance of
DomainID calculation; the grammar needs a tweak or two, though.  My
suggestion would be to either drop "The consequences of" or add "be to" to
make "would be to allow" (but not both).

Section 11.3 has gone back to just "Devices which are reset to factory default
in order to perform a second bootstrap with a new owner MUST NOT use idential
seeds", but I think it's important to be clear about what the scope of uniqueness is.
The text in Section 5.2 is pretty good in this regard, with respect to the nonces
(which are generally derived from the seed); I wonder if we might want to
restructure this text to be more like "The random seed used by a device at boot
MUST be unique across all devices and all bootstraps.  Resetting a device to
factory default state does not obviate this requirement."  (FWIW, I think the
text in the -29 was that way because of my request.)

[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.]

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

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.

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
   it processes.

nit: s/in// from "in which it has confidence in" (your
choice which one).

Section 4

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

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

   [...] The use of
   GRASP mechanism part of the ACP.  Other users of BRSKI will need

nit: missing "is", "the"

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""".

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

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.
[ed. I also can't remember if we had discussion about this comment]


I trimmed all the "Additional comments since posted ballot position on -28"
that were in my previous ballot position, as they are likely stale by now.

Ignas Bagdonas Yes

Deborah Brungard No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2019-11-05 for -29)
No email
send info
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 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  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)
No email
send info
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


Adam Roach (was Discuss) No Objection

Comment (2019-08-29 for -26)
No email
send info
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


Magnus Westerlund (was Discuss) No Objection