Reviewer: Qin Wu Review result: On the Right Track I am the assigned IoT Directorate reviewer for this draft. The Directorate aims to review IETF documents related with IoT (Internet of Things). Please treat these comments just like any other last call comments. For more information, please see https://datatracker.ietf.org/group/iotdir/about/ Summary: The goal of this document is to define how to contact a well-known Cloud Registrar, and further specify two ways which allow the new device be redirected towards the operator maintained infrastructure. I believe this document is well written. Here is a few comments and suggestions I would like authors of this draft to consider: 1. Section 1 said: “This document further specifies use of a BRSKI Cloud Registrar and clarifies operations that are not sufficiently specified in BRSKI.” [Qin]: Do we need to update BRSKI for these clarification on operations which haven’t been specified in BRSKI. “ 2. Section 1.2 s/specifies and standardizes/specifies s/Resller/Reseller 3. Section 1.2 said: “A typical example is an employee who is deploying a Pledge in a home or small branch office, where the Pledge belongs to the employer. There is no local domain Registrar, the Pledge needs to discover and bootstrap with the employer's Registrar which is deployed within the employer's network, and the Pledge needs the keying material to trust the Registrar. For example, an employee is deploying an IP phone in a home office and the phone needs to register to an IP PBX deployed in their employer's office.” Suggest to remove the last sentence, since it looks duplicated to have two examples in the same paragraph. 4. Section 2 said: “ For use case one, as described in Section 1.2.1, the Cloud Registrar redirects the Pledge to an Owner Registrar in order to complete bootstrap with the Owner Registrar. When bootstrapping against an Owner Registrar, the Owner Registrar will interact with a CA to assist in issuing certificates to the Pledge. This is illustrated in Figure 1. For use case two, as described Section 1.2.2, the Cloud Registrar issues a voucher itself without redirecting the Pledge to an Owner Registrar, the Cloud Registrar will inform the Pledge what domain to use for accessing EST services in the voucher response. In this model, the Pledge interacts directly with the EST service to enroll. The EST service will interact with a CA to assist in issuing a certificate to the Pledge. This is illustrated in Figure 2. ” Use case one doesn’t describe how MASA works together with Pledge, Owner Registrar and CA described in figure 1, suggest to remove MASA from the figure 1. Use case two doesn’t describe how MASA works together with Pledge, Owner Registrar, Cloud Registrar and CA described in figure 2, suggest to remove MASA from the figure 2. 5. Section 2 also said: “ As depicted in Figure 1 and Figure 2, there are a number of parties involve in the process. The Manufacturer, or Original Equipment Manufacturer (OEM) builds the device, but also is expected to run the MASA, or arrange for it to exist. ” What role does MASA play, who is expected to run the MASA? It is not clear this should be described in the scope 6. Section 2.1 Can you provide a reference to WPS? 7. Section 3.1.2 said: “ Unlike the Provisional TLS procedures documented in BRSKI section 5.1, the Pledge MUST NOT establish a Provisional TLS connection with the Cloud Registrar. “ Please provide referenced RFC to BRSKI ? 8. Section 3.1.2 also said: “ unless it is known that Cloud or Owner Registrars for this Pledge implementation will never need to be deployed in a cloud setting requiring the "server_name" extension “ What happened if Cloud Owner Registrars doesn’t support server name extension, e.g., using TLS 1.3 and can not obtain the server name? 8. Section 3.1.2 said: “ To protect itself against DoS attacks, the Cloud Registrar SHOULD reject TLS connections when it can determine during TLS authentication that it cannot support the Pledge, for example because the Pledge cannot provide an IDevID signed by a CA recognized/supported by the Cloud Registrar.¶ ” Looks like this paragraph belongs to security consideration section. 9. Section 3.2, paragraph 1: s/ In the case of an unknown Pledge a 404 is returned, for a malformed request 400 is returned, or in case of server overload 503 is returned./ In the case of an unknown Pledge, a 404 is returned, for a malformed request, 400 is returned, or in case of server overload, 503 is returned. 10. Section 3.2.3 said: “ The voucher MAY include the new "additional-configuration" field. This field points the Pledge to a URI where Pledge specific additional configuration information may be retrieved. “ How does this align with SZTP work in [RFC8572]? It is nice to reference RFC8572 if it aligns. 10. Section 3.3.1 said: “ then the Pledge MAY accept a subsequent 307 response from this Cloud VAR Registrar.¶ ” How many subsequent 307 response does the Pledge allow? Is there any security risk that needs to be considered? 11. Section 4.2 s/ both [RFC1918] and/ both ipv4 [RFC1918] and s/provided by with/provided with 12. Section 5 s/dependant upon/dependent upon 13. Section 9 said: “ The Pledge is unable to determine whether it has been redirected to another Cloud Registrar that is operated by a VAR, or if it has been redirected to an Owner Registrar, and does not differentiate between the two scenarios. “ Is there any security risk that needs to be considered? -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
