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

Summary: Needs a YES. Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.

Benjamin Kaduk Discuss

Discuss (2020-02-24 for -35)
Thanks for the updated examples using the allocated MASA URL extension OID!

Unfortunately, I think there are still some inconsistencies in the examples to resolve:

The MASA cert/key is identical to the "manufacturer key pair for IDevID
signatures" (C.1.1 and C.1.2).  (It shows the MASA Subject CN, so maybe 
just the included file was typo'd?)  The example IDevID cert shows an
issuer name that doesn't match the cert given.
(Also the MASA cert doesn't have a randomized serial number but the
registrar one does.)

The registrar-to-MASA voucher request in C.2.2 seems to have a CMS
SignedData with the SignerIdentifier identifying the "Unstrung Fountain
Root" (i.e,. the root CA used for these examples) instead of the
expected "fountain-test.example.com".  Am I misreading the ASN.1 dump?
(We do seem to send both certificates.)

The voucher response from MASA to Registrar seems to be signed by the
"highway-test.example.com CA" (which would be the "manufacturer key pair
for IDevID signatures" that we don't have in the -35 since the MASA
certificate is repeated), not the MASA's cert from C.1.1.
Comment (2020-02-24 for -35)
[trimming presumably stale comments]

(Ignas Bagdonas) Yes

Deborah Brungard No Objection

Alissa Cooper (was Discuss, No Objection, Discuss) No Objection

Comment (2020-01-24 for -34)
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?

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

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

(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


-éric

Magnus Westerlund (was Discuss) No Objection

Martin Duke No Record

Erik Kline No Record

Murray Kucherawy No Record

Robert Wilton No Record