I reviewed this document as part of the IoT Directorate's effort to IoT-related IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Internet Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-anima-bootstrapping-keyinfra-17 Reviewer: Russ Housley Review Date: 2018-11-28 IETF LC End Date: unknown IESG Telechat date: unknown Summary: Has Issues (Note: I did not review the Appendices.) Major Concerns: Section 2.2 says: ... The registrar maintains control over the transport and policy decisions allowing the local security policy of the domain network to be enforced. I have no idea what this means. Please clarify. In Section 2.3, it says: 5. (Optional) Signing of voucher-request by the pledges IDevID to enable MASA to generate voucher only to a registrar that has a connection to the pledge. This is an important section to understand BRSKI, but I cannot parse this sentence. Please reword. Section 2.3.1 talks about pledges being uniquely identified by a "serial-number" in voucher and voucher-requests. Pledges are also uniquely identified by their serial number in certificates. Section 2.3.1 refers to HardwareModuleName, which is defined in RFC 4108. It says that the HardwareModuleName hwSerialNum is base64 encoded. RFC 4108 does not require base64 encoding. Where does that requirement come from? Section 3.1 shows the YANG tree model of the Voucher-Request. I am far from a YANG expert, but I expected a subsequent section to describe the semantics of each field. The examples in Section 3.2 are useful, but they are not a replacement. Some fields (like voucher/expires-on) are not described in Section 3.3. I assume that this is building on another module because this one contains "import ietf-voucher", but this does not say what RFC contains the imported module to learn the rest of the semantics. I think that the CDDL in Sections 4.1.1 and 4.3 are supposed to be structures. If that is correct, the structure should look something like the following, which includes type information: basic-header = [ field1: int, field2: text, ] advanced-header = [ ~basic-header, field3: bytes, field4: ~time, ] I have no idea what the boxes in Figure 10 represent. Section 7.2 does not contain enough information to make the needed object identifier assignments. In Section 7.4, the IESG (not the IETF Chair) should be the contact for standards-track registrations. I think the security considerations ought to describe the consequences of compromise of the various private keys in the ecosystem. Some only impact one device, but others have much greater impact. I think the security considerations ought to say something about the nonce. First, it should point to RFC 4086. Second, it should say something about the consequences of a poor random source. It does not need to be a comprehensive as the section dealing with setting time. Minor Concerns: The Introduction says: BRSKI provides a solution for secure zero-touch (automated) bootstrap of virgin (untouched) devices that are called pledges in this document. These pledges need to discover (or be discovered by) an element of the network domain to which the pledge belongs to perform the bootstrap. This element (device) is called the registrar. ... I find the two uses of device to be a bit confusing. I suggest: Bootstrapping Remote Secure Key Infrastructures (BRSKI) provides a solution for secure zero-touch (automated) bootstrap of virgin (untouched) devices, called pledges. Pledges need to discover (or be discovered by) an element of the network domain to which the pledge belongs to perform the bootstrap, called the registrar. ... In the Introduction, in the paragraph that follows the description of the four points of trust, I think there is a significant typo. An IEEE 802.1AR LDevID certificate addresses points 1 and 2, and then a "voucher" addresses points 3 and 2. I suspect that the second "2" should be "4". If not, some additional text is needed to cover point 4. Section 1.2: Please update the first paragraph to reference RFC 8174 in addition to RFC 2119, as follows: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. I think that "/ next steps" should be dropped from the title of Section 1.4. I think that Section 1.5 would be well served with bullets that are full sentences. For example, the document says: o BRSKI: Request Voucher This terse phrase, I think, covers the requesting of a voucher by the pledge from the MASA, and then receiving the voucher. Alternatively, you could provide forward pointers that describe each of these terse phrases. Section 2 uses "Manufacturer Service" and "Vendor Service". I think they are the same thing. Neither of these is defined in Section 1.2, so I am not totally sure. Please clarify. Section 2 says: ... It is unlikely that an integrator could provide Ownership Tracking services for multiple manufacturers due to the required sales channel integrations necessary to track ownership. ... However, it seems possible for the integrator to provide a referral to the appropriate Ownership Tracking service or provide a proxy. Section 2 talks about a "PKI Registration Authority". No context is given. At a minimum, a reference to RFC 5280 seems appropriate. If there is a more specific role that an RA might play in BRSKI, then that should be explained or referenced. Section 2.5.3 talks briefly about the "Implicit Trust Anchor database". Please add a reference to RFC 7030 here; it is needed to understand the concept. In the security considerations, it would be good to cover how the owner of a device might cope the a manufactured going out of business or stopping support for a device. This is really not a problem if the device is already on a network and it does not ever need to move to another network. Section 11.1: Please add a normative reference to RFC 8174. Nits: The abstract says: ... Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. ... This is a complex sentence. Can it be up-leveled for the Abstract? If not, can it be reworded to be more straightforward? Please spell out "BRSKI" in the first sentence of the Introduction. I did this in my suggested text in the previous portion of this review. The quotes do not balance in the second to last paragraph of the Introduction. Please put the terms that are defined in Section 1.2 in alphabetical order. In section 1.2, the definition of "drop ship" talks about "drop-ship". Please pick one spelling. In Section 1.2, you define "Join Registrar (and Coordinator)", but the Introduction seems to talk about this role simply as the "Registrar". I think it would be helpful to include a "Registrar" entry here to help the reader. Similarly for "Join Proxy" and "Proxy". The Introduction talks about IEEE 802.1AR LDevID; please add LDevID to the definitions in Section 1.2. In Figure 1: s/PKI Certificate Authority/PKI Certification Authority/ In Section 2.3: s/fake pledged/fake pledges/ In Section 2.3: s/pledges MASA/pledge's MASA/ In Section 2.3: s/(see Appendix C./(see Appendix C)./ In Section 2.3: s/pledges IDevID/pledge's IDevID/ In Section 2.6.1, the list of five time sources should be turned into a real sentence. In Section 2.6.1, please turn "See / (Section 5.2)" into a sentence. In many places: s/global internet/global Internet/ In many places: s/internet at large/Internet at large/ Lists of bullets come in many flavors. Some bullets end with a comma, some end with a period, and others end with no punctuation at all. Please pick one style and use it everywhere. FYI: I compiled the MASAURLExtnModule-2016 ASN.1 module. It compiles fine, but I find the indent and white space style used awkward.