[cabfpub] Ballot 210: Misc. Changes to the Network and Certificate System Security Requirements

[Ryan Sleevi]

Thanks Neil, this is all super-helpful context and an excellent summary of
what is no doubt months of discussions, and greatly appreciated :)

On Tue, Aug 15, 2017 at 11:56 AM, Neil Dunbar via Public <
public at cabforum.org> wrote:

> Ryan,
>
> I’ll take a stab at at least some of the rationale. Obviously, others will
> have different observations and priorities - so don’t take this as anything
> other than my musings on the NetSec discussions. The dominant notion was
> that the document which was the source of NetSec was an old one (from
> Symantec, I think?), and that the movement in technology meant that some of
> its stipulations had somewhat been obsoleted.
>
> 1a - logical versus physical separation: I think that the view here was
> that VLAN tagging be orchestrated and enforced from dedicated managed
> network equipment (which must be accounted for, audited, configuration
> reviewed, change logged just as before), and not from a host based network
> stack, since that would necessitate the host being able to span the VLANs -
> in other words the host performing Certificate System work would - at least
> logically - exist in a bridging state, which violates the principle of
> isolation. Why is it being proposed? I suspect because the maturity of
> software defined networking (whether enforced via VLAN, IPSec, etc) has now
> reached the point where its isolation properties are deemed sufficiently
> trustworthy for CA work. However, I can see that others may have a markedly
> different view of this level of trust.
>

I agree with this analysis, and my concern is wanting to make sure we've at
least got the "please dear $DEITY don't do something stupid here" captured
as well, with the "something stupid" being what you mentioned - a host that
is bridged.

The challenge, which I think is worth articulating even as I try to form a
suggestion, is that it creates ambiguity as to what's "sufficiently not
stupid".

For example: Is a physical host running a hypervisor sufficiently isolated
from its guests? (Maybe, maybe not - and if not, popping the hypervisor is
sufficient to gain lateral access).
For example: Is a physical host with two dedicated NICs, each going to
different segments, sufficiently isolated? (Arguably, no, it's effectively
a bridging state - but that may be non-obvious to some CAs, based on past
evidence)
For example: Is a switch handling VLAN tagging sufficiently segmenting?
(Maybe, maybe not - popping the switch would be sufficient to gain lateral
movement)

Even if we have roots in a fully (physically) airgapped configuration, for
the online issuance, we need to have some interaction between the untrusted
'outside' and the trusted 'inside' - and wanting to make sure we've got
something sufficient enough that it would survive a pentest seems a
reasonably low bar. The problem is articulating that.


>
> 1b - “equivalent" versus “same”. Some deployments have different vendors
> (or different versions of equipment from the same vendor) which have
> different expressions of isolation enforcement (e.g. different routers
> having equivalent, but non-identical configuration data to enforce
> separation); the technical security properties desired remain the same, but
> the means of achieving them may differ. If I recall correctly (and I almost
> certainly don’t, or at least incompletely) the intention is to try and give
> some flexibility to CAs to have heterogeneous equipment setups within their
> environments, while retaining the requirement to establish to an auditor
> that the isolation properties are of equal value to a homogeneous
> environment. I’ll readily confess that my memory is less that solid on this
> point - so other NetSec people, please correct my errors.
>

I see, and I understand that goal (and the challenge it can no doubt
present). I'm curious whether this is something we can/should codify as a
documentation exercise to be included as part of the (public)
documentation. That is, my concern always exist with any form of
closed-system evaluation of equivalence, since so far, every time we've
allowed that, we (the broader PKI community) have allowed risk to be
introduced, and no way to discover it until after the fact.


> 2m - Multi-party authentication. We had a long discussion on what
> constituted a “System” as far as issuing certificates was concerned
> (specifically around Root CA equipment, which is often offline and/or air
> gapped) - did it include the HSM as well as the computers which interface
> to it? Assuming that the HSM and computer falls within the boundary of the
> “System”, the question then arose about multi-factor authentication being
> difficult in such isolated environments, since often things like OTP/U2F
> involves synchronising with other online equipment, and some CAs might be
> very loath to expose their air gapped kit - even for a short while. Thus
> the suggestion arose that if the multi-party authentication to the HSM
> could be counted (e.g. by using USB keys, or some other means), then it
> wouldn’t really matter if the authentication to the computer used to talk
> to the HSM was single-factor. Now, since all HSM equipment is mandated to
> be FIPS-140 L3 or higher, a simple password level compromise would not be
> effective - the attacker would need to compromise the trusted inputs to the
> HSM too. Or so some of my thinking went.
>

Yeah, another perspective I can totally appreciate, although not without
risk :) I think we'd be in agreement that an 'admin' password and an
'operator' password is a terrible idea - but as worded, it'd be permitted
(unless I'm misreading). Is the concern limited to HSMs (which, as you
note, may have physically distinct controls)? Is there a way to encompass
that single-factor is permitted if it's physically distinct (e.g. two
different physical devices / "something you have"), but otherwise,
multi-factor is required ("something you know" + something else)? Does that
strike the right balance, conceptually?


> 2o - Removal of requirement to have remote access from a “pre-approved IP
> address”. Giving CAs the flexibility to perform trusted operations from
> systems in their direct control using MFA, but which may not have a
> persistent IP address. The idea being that the security is vested in the
> control of the device, network and authentication method, and no longer a
> specific external IP address. Given the prevalence of NAT within isolated
> networks, it could be argued that a pre-approved IP address yields no
> tangible benefit (IPv6 networks notwithstanding).
>

Yup. This is something we (Google) raised as a concern in the very
beginning discussions of the NetSec document, while Google was hosting, in
part because it did not align with our own analysis of threat models or our
expertise :)


> 4a - Intrusion Detection. This was to replace the overly prescriptive
> suggestions of anti-virus software with the notion of “something which
> detect unauthorised changes to the system”, which is I suspect what the
> anti-virus statement was intended to achieve all along.
>

Yeah, this was another area of concern raised, so I think it's great to see
progress being made here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170815/77b9d885/attachment-0001.html>