[cabf_netsec] [EXTERNAL] Rationale for changes in ballot 210 - summary

[Ryan Hurst]

I think limiting the multi-person authentication to situations where there
is a physical authenticator would be a good idea.

Ryan

On Tue, Aug 15, 2017 at 8:47 AM, Peter Bowen via Netsec <netsec at cabforum.org
> wrote:

> I think these are good answers.  Before I read this, I sent a reply on the
> 1.a item — I think that Ryan simply hasn’t read the existing requirements
> carefully.  For 2.m, should we consider somehow limiting the multi-person
> authentication to situations where there is a physical authenticator?
>
> > On Aug 15, 2017, at 8:35 AM, Kirk Hall via Netsec <netsec at cabforum.org>
> wrote:
> >
> > I think those are good explanations, Neil - thanks.  I'd add that
> according to memory, the original NetSec requirements were based on an
> internal Symantec security document, supplemented in places from outside
> standards.  Thus they may in effect be 5-10 years old, and ready for
> updating as you suggest.
> >
> > -----Original Message-----
> > From: Netsec [mailto:netsec-bounces at cabforum.org] On Behalf Of Neil
> Dunbar via Netsec
> > Sent: Tuesday, August 15, 2017 8:14 AM
> > To: CA/Browser Forum Network Security WG List <netsec at cabforum.org>
> > Subject: [EXTERNAL][cabf_netsec] Rationale for changes in ballot 210 -
> summary
> >
> > Chaps,
> >
> > I’m pushing this out as a discussion point in order to answer Ryan’s
> (perfectly reasonable) request for the logic underpinning Ballot 210
> changes.
> >
> > I’m certain that I’ve missed many points, or invented others from my
> fevered imagination - so please do add some suggestions, and I’ll integrate
> before posting to the main list. Note - I’m NOT trying to speak for the
> NetSec group as a whole - I’m just trying to ensure that my memory is
> sufficiently refreshed as not to mislead the forum.
> >
> > Cheers,
> >
> > Neil
> >
> > -------------
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 1l, 2l, 4c, 4f - Replacing numerals with text. Stylistic change.
> >
> > 2g, 2j, 3e, 4c  - Replacing number of days with months. More to fit in
> with the scheduling which most IT departments orchestrate regular reviews
> and activities, i.e., every three months rather than every 90 days.
> >
> > 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.
> >
> > 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).
> >
> > 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.
> >
> > Definition of Security Support System - making it clear that the
> functions of the security support systems include HIDS/NIDS, rather than
> the overly prescriptive “anti-virus”. In fact, anti-virus software could
> let all manner of unauthorised changes through since the changes don’t fit
> the definition of malware.
> >
> > _______________________________________________
> > Netsec mailing list
> > Netsec at cabforum.org
> > http://cabforum.org/mailman/listinfo/netsec
> > _______________________________________________
> > Netsec mailing list
> > Netsec at cabforum.org
> > http://cabforum.org/mailman/listinfo/netsec
>
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20170815/43d41d53/attachment-0001.html>