Qin Wu via Datatracker <noreply@xxxxxxxx> wrote:
> infrastructure. I believe this document is well written. Here is a few
> comments and suggestions I would like authors of this draft to
> consider:
Your comments have been collected into this pull request:
https://github.com/anima-wg/brski-cloud/pull/177
> 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. “
Added updates:
https://github.com/anima-wg/brski-cloud/pull/177/commits/e312384e44cf25d78fed023878b64f3bcac889eb
> 2. Section 1.2 s/specifies and standardizes/specifies
> s/Resller/Reseller
https://github.com/anima-wg/brski-cloud/pull/177/commits/55583ee237f3b5c237b76d8552e6eb55a8bbfae7
> 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.
I have rewritten as:
https://github.com/anima-wg/brski-cloud/pull/177/commits/d694527499b3310ad0bdda1e1f0774c40346b244
-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.
+This mechanism is useful to help an employee who is deploying a Pledge in a home or small branch office, where the Pledge belongs to the employer.
As there is no local domain Registrar in the employee's local network, 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.
+As a very specific 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.
I did not remove the example, because I think it's important to emphasis the point.
> 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.
I've amended the figure to include BRSKI-MASA as the protocol.
It's unchanged from RFC8995.
Removing it from the diagram would be more confusing.
https://github.com/anima-wg/brski-cloud/pull/177/commits/1f47e48dc65910d7865727d37fa4ae256ecb7716
> 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
It's the same as RFC8995.
> 6. Section 2.1 Can you provide a reference to WPS?
Yes, maybe.
https://github.com/anima-wg/brski-cloud/pull/177/commits/378eec962adb2cfaa4613aa3d0b65a90cc155b7e
references: https://www.wi-fi.org/discover-wi-fi/wi-fi-protected-setup now.
which has a marketing click-through, which many BigTech employees are
forbidden from clicking through. So I don't know how to cite 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 ?
https://github.com/anima-wg/brski-cloud/pull/177/commits/7bba63442bc78c6a97101a53495013a5f33971d1
now cites RFC8995 section 5.1 with a link.
> 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?
https://github.com/anima-wg/brski-cloud/pull/177/commits/2a51c3f3c33392fc3e8e6129a30d37ab53daa853
reworked some of the SNI text.
Sending SNI is pretty much mandatory in TLS 1.3, but we are allowed to modify that.
On the Registrar side, the SNI info should be ignored.
I thought that draft-richardson-anima-registrar-considerations had more text
about SNI that didn't get into RFC8995... I thought there was an errata.
Yes, 6648. But not marked verified.
maybe it's time to adopt registrar-considerations.
I don't know what to do here.
> 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.
Well, I disagree.
SHOULD/MUST do not belong in Security Considerations, but can be referenced.
I'm not sure this belongs in SC, but I am willing to add a new 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.
also in:
https://github.com/anima-wg/brski-cloud/pull/177/commits/2a51c3f3c33392fc3e8e6129a30d37ab53daa853
> 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.
SZTP specifies a way to use https or SSH to reach out to the cloud, and then
there might be a inversion of the connection, and configuration information
will be downloaded. I don't think this work aligns with that work at all.
> 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?
There is a section 7.2 that deals with this.
I've added a clearer forward reference:
https://github.com/anima-wg/brski-cloud/pull/177/commits/eaa7c87e73216e5091dfd1cb6019bcc15ca2dc4a
> 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
typos fixed:
https://github.com/anima-wg/brski-cloud/pull/177/commits/b88dff990b3dea58cf6d8510ed9db6b3b19af70e
> 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?
I don't think so.
But, I've rewritten slightly:
https://github.com/anima-wg/brski-cloud/pull/177/commits/39e2096297f9f68c26bc4dfac6b6fa77e3b14ee8
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
