Deb Cooley via Datatracker <[email protected]> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ----------------------------------------------------------------------
> In the security considerations section, please state what the
consequences are
> for the issues listed. For example:
> --- Section 8.1, para 1: So what? Is there an issue with a Pledge
> connecting to the Internet before being enrolled? [hint: yes, there
> is]
https://github.com/anima-wg/brski-cloud/pull/248/commits/5cee6c47d3948ab4df3bff5080d62b4f5e9b664e
+The Pledge SHOULD NOT assume that the connectivity that it has is sheltered.
+In a majority of cases, the Pledge will be connected to a network behind an
enterprise firewall, or a home router, with typical restrictions on incoming
TCP connections due to NAT44 {{?RFC6144}} and {{?RFC7084, Sections 3.1}}, and
{{RFC6092, Section 4}}.
+In such situations, the Pledge might think it can be assured that it can not
be attacked, but this is not the case.
+Pledges could be deployed on networks with unfiltered connectivity, there
could be incoming connections enabled, and there could also be malicious
devices within this network.
(I don't like BCP14 keywords in SC, but, it seems to fit here)
Not sure if the term "sheltered" is well enough understood.
Maybe it's enough to say "RFC6092 is not universal"
{Saw a talk a decade ago about critical power control relays for Heathrow
Terminal 4
being on a public IP... of course with default password.
Because how else do you power cycle the firewall remotely?}
> --- Section 8.1, para 2: While a Pledge should check for firmware
updates,
> validation and transfer of those updates needs to happen in a secure
fashion
> - usually this means source integrity (did the f/w come from the correct
> place), firmware integrity (is the f/w load the same?), and possibly
> confidentiality. A sentence to make this more obvious would be good.
+The Pledge SHOULD contact the Manufacturer before bootstrapping in order to
apply any available firmware patches.
+Firmware patches need to validated before being applied.
+This is best done via signatures on the firmware updates, such as described in
{{?RFC9019}} or an equivalent mechanism.
+Origin authentication of updates is also sometimes enough.
+
+In order to best protect the Pledge from attacks of all kinds, Manufacturers
are encouraged to make MUD {{?RFC8520}} files available.
+Care needs to be taken in those definitions to allow for retrieval of firmware
updates.
> --- Section 8.2: While reading this long section, I see a
recommendation
> near the bottom. Perhaps reorganizing this section so the recommendation
is
> closer to the top. The goal here is to reduce security issues due to
> compromised trust anchors (i.e. keep the list small). The second goal is
to
> reduce the issues with requiring an update to the trust store list
(properly
> validating the service).
> ---- One comment in particular, in para 2, while it might be easier,
> using one of the WebPKI trust stores will result in many trust anchors
that
> are not applicable.
I moved the last point to the top, and I wound up rewriting things, changing
some of the order. The rich-text diff result is at
https://github.com/anima-wg/brski-cloud/pull/248/commits/1f7efb049d968511eed36436246da746338492d7?short_path=95c06ef#diff-95c06efda4eae4c6bd2b739bded9ef7a0d5c210ba88be1e034bffd3872816030
> --- Section 8.3: What are the consequences of accepting a redirect when
> validation fails?
https://github.com/anima-wg/brski-cloud/pull/248/commits/aa7b5d0493335e2ad35706256ac44b04340c6ade
+Provisional TLS connections are not immediately validated.
+A provisional TLS connection can be intercepted by an attacker, as unlike in
{{BRSKI}}, this connection crosses the Internet.
+There can be IP address hijacks, possibly DNS attacks that could send the
Pledge to the wrong place.
+Such a diversion would be detected when the resulting Voucher can not be
validated.
+
There is a conflict between these requirements: one says to validate, and the
other one says not to.
-This is resolved by having the Pledge attempt validation, and if it succeeds,
then an HTTP 307 redirect will be accepted.
+This is resolved by having the Pledge attempt validation, and if it succeeds,
then and only then, an HTTP 307 redirect will be accepted.
If validation fails, then an HTTP 307 redirect MUST be rejected as an error.
If that occurs, then the onboarding process SHOULD restart after a delay.
This failure should be reported to the initial Cloud Registrar via the
mechanism described in {{BRSKI, Section 5.7}}.
+If the Pledge were to accept a 307 Redirect from a malicious entity, then it
could be directed to connect to some other Registrar-like entity.
+This could be used to turn the Pledge into part of a distributed denial of
service (DDoS) attack.
+As the Pledge will send it's details in the Voucher Request that it does send,
there is also a possible disclosure of the Pledge's identifiable private
information.
+
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> Thanks to Mike Ounsworth for their (multiple) secdir reviews.
> Section 4.2, step 6: What/where is this:
{pledge-certificate-identity-considerations} ?
> Section 8.4: What/where is this:
{bootstrap-via-cloud-registrar-and-owner-est-service} ?
I hate it when that happens. Of course it should be {{FOO}}.
It's only {#FOO} when defining the anchors. Fixed.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
