Policy 2.5 Proposal: Clarify requirement for multi-factor auth

[Gervase Markham]

Ryan Sleevi suggested a wording clarification/policy extension to the
multi-factor auth requirement, from:

"enforce multi-factor authentication for all accounts capable of
directly causing certificate issuance"

to

"enforce multi-factor authentication for all accounts capable of causing
certificate issuance or performing validation functions"

The goal here was to cover RAs performing validation functions. Although
we are moving towards not permitting third parties to perform domain or
IP address ownership validation, it still seems to be to be a good
improvement that accounts involving certificate issuance or the input of
data into what will become an issued certificate should be multi-factor
protected.

This is: https://github.com/mozilla/pkipolicy/issues/60

-------

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates

[Kurt Roeckx]

On 2017-05-19 14:18, Gervase Markham wrote:
> Ryan Sleevi suggested a wording clarification/policy extension to the
> multi-factor auth requirement, from:
>
> "enforce multi-factor authentication for all accounts capable of
> directly causing certificate issuance"
>
> to
>
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing validation functions"
>
> The goal here was to cover RAs performing validation functions. Although
> we are moving towards not permitting third parties to perform domain or
> IP address ownership validation, it still seems to be to be a good
> improvement that accounts involving certificate issuance or the input of
> data into what will become an issued certificate should be multi-factor
> protected.

I'm wondering why something like this should be in the Mozilla policy
and not be part of something else that they get audited for.


Kurt

[Gervase Markham]

On 19/05/17 14:26, Kurt Roeckx wrote:
> I'm wondering why something like this should be in the Mozilla policy
> and not be part of something else that they get audited for.

Section 6.5.1 of the BRs states:

"The CA SHALL enforce multi‐factor authentication for all accounts
capable of directly causing certificate issuance."

I'm not sure whether that came from the Mozilla policy or vice versa,
but it appeared in the Mozilla policy in version 2.1, and was
communicated as a requirement in a CA Communication in September 2011,
in response to DigiNotar. It was also in draft 34 of the BRs, written in
May 2011. So it may be we got it from them.

Gerv

[Carl Mehner]

On Friday, May 19, 2017 at 7:19:27 AM UTC-5, Gervase Markham wrote:
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing validation functions"

Should we specify somewhere that multi-factor auth encompasses two _different_ factors and not simply multiple authenticators?

It seems possible that some could (or possibly do) interpret multi-factor as including 'double-single-factor' or 'multi-step' using something like a client cert (something you have) and a TOTP like Google Authenticator (something you have). Taken to the extreme, this could include two 4-digit pins (something you know and something you know).

If that's not the intent, then something such as the following may be more clear:
"enforce multi-factor authentication (using 2 or more factors from NIST 800-63-2) for all accounts capable of causing certificate issuance or performing validation functions"

[Gervase Markham]

On 19/05/17 15:52, Carl Mehner wrote:
> Should we specify somewhere that multi-factor auth encompasses two _different_ factors and not simply multiple authenticators?

I appreciate your desire to cover all the angles, but I think the
standard definition of the term encompasses this.

I think that if there was a problem, and a CA said "we have multi-factor
authentication - two passwords", the resulting hilarity and shame would
be... extensive. And recall, Mozilla has full discretion over who we
include, so rules-lawyering is ineffective and, in fact, counter-productive.

Gerv

[Gervase Markham]

On 19/05/17 13:18, Gervase Markham wrote:
> Ryan Sleevi suggested a wording clarification/policy extension to the
> multi-factor auth requirement, from:
>
> "enforce multi-factor authentication for all accounts capable of
> directly causing certificate issuance"
>
> to
>
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing validation functions"

Implemented as specced.

Gerv

[Doug Beattie]

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy
> Sent: Wednesday, May 31, 2017 7:24 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth
> >
> > "enforce multi-factor authentication for all accounts capable of
> > directly causing certificate issuance"
> >
> > to
> >
> > "enforce multi-factor authentication for all accounts capable of
> > causing certificate issuance or performing validation functions"

Can you give some examples of validation functions that need to be enforced by multifactor authentication? There are some that I don't think can be done using multi-factor authentication, such as domain validation via email (the link to confirm the domain can't be protected by multi-factor auth).


> Implemented as specced.
>
> Gerv
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

Hi Doug,

On 01/06/17 10:54, Doug Beattie wrote:
> Can you give some examples of validation functions that need to be enforced by multifactor authentication? There are some that I don't think can be done using multi-factor authentication, such as domain validation via email (the link to confirm the domain can't be protected by multi-factor auth).

This is a good point; I think we've been unclear here. The aim was to
target CA or RA employees sitting at computers and logging in to perform
validation functions such as entering data. It wasn't designed to
require email domain validation link-clicking to be multi-factor, or for
that matter to require someone logging into their account with their CA
to say "please re-issue my certificate for this already-validated
domain" to require multi-factor.

Does anyone have suggestions as to how we can word this provision to
make this distinction?

Gerv

[Ryan Sleevi]

On Thu, Jun 1, 2017 at 6:52 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi Doug,
>
> On 01/06/17 10:54, Doug Beattie wrote:

> > Can you give some examples of validation functions that need to be
> enforced by multifactor authentication? There are some that I don't think
> can be done using multi-factor authentication, such as domain validation
> via email (the link to confirm the domain can't be protected by
> multi-factor auth).
>

> This is a good point; I think we've been unclear here. The aim was to
> target CA or RA employees sitting at computers and logging in to perform
> validation functions such as entering data. It wasn't designed to
> require email domain validation link-clicking to be multi-factor, or for
> that matter to require someone logging into their account with their CA
> to say "please re-issue my certificate for this already-validated
> domain" to require multi-factor.
>
> Does anyone have suggestions as to how we can word this provision to
> make this distinction?

Do you think it's a valid reading to suggest that the e-mail confirmation
link is, in fact, performing a validation function?

That is, I can appreciate the tortured reading that results in this - and I
can appreciate the desire for greater clarity - but I'm not sure it's worth
expending significant effort on. In the worst case, a CA who reads it like
Doug suggests will result in a more secure system (vis-a-vis the discussion
in the CA/Browser Forum regarding email scanning devices that 'click' on
links).

The reason why I don't think it's a valid reasoning is that if we accept
that this provision in the policy could be read to cover such emails, then
we're implicitly agreeing that the act of clicking that email is performing
a validation function pursuant to 3.2.2.4 of the Baseline Requirements.
Ergo, every customer of that CA who uses that method is acting as a
Delegated Third Party, performing the validation functions of 3.2.2.4 -
since, by logical extension, they're performing the validation function of
3.2.2.4 on their account - and all the attendant mess that it entails.

So while I can appreciate the question, and I can appreciate why it's
raised, I would think that if someone who wanted to make that
interpretation extended the argument through its logical conclusion, it
would naturally reveal itself as an invalid interpretation - or, ideally,
one in which other CAs will question, and we can point back to this thread.

Put differently, I think it's absolutely fantastic that Doug has raised
this question, and I think all CAs should raise any such questions of
interpretation on the list, so they can be explored, answered, and
clarified - as you have - but I'm not sure that it should be incumbent on
the policy to clarify it, especially if the (mis)interpretation results in
greater rigor, rather than less :)

[Gervase Markham]

On 01/06/17 13:45, Ryan Sleevi wrote:
> The reason why I don't think it's a valid reasoning is that if we accept
> that this provision in the policy could be read to cover such emails, then
> we're implicitly agreeing that the act of clicking that email is performing
> a validation function pursuant to 3.2.2.4 of the Baseline Requirements.

Well, yes, probably. This text is in the Mozilla policy and the above is
in the Baseline Requirements, but I can see how this logic works.

> Ergo, every customer of that CA who uses that method is acting as a
> Delegated Third Party, performing the validation functions of 3.2.2.4 -
> since, by logical extension, they're performing the validation function of
> 3.2.2.4 on their account - and all the attendant mess that it entails.

That's a good point.

Perhaps this leads to the solution? We say:

"enforce multi-factor authentication for all accounts capable of causing

certificate issuance or performing RA or DTP functions as defined by the
Baseline Requirements"

?

Gerv

[Doug Beattie]

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, June 1, 2017 8:46 AM
To: Gervase Markham <ge...@mozilla.org>
Cc: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>

Subject: Re: Policy 2.5 Proposal: Clarify requirement for multi-factor auth

> > "enforce multi-factor authentication for all accounts capable of
> > directly causing certificate issuance"
> >
> > to
> >
> > "enforce multi-factor authentication for all accounts capable of
> > causing certificate issuance or performing validation functions"

> > Does anyone have suggestions as to how we can word this provision to
> > make this distinction?

> Do you think it's a valid reading to suggest that the e-mail confirmation link is, in fact, performing > a validation function?

> That is, I can appreciate the tortured reading that results in this - and I can appreciate the desire
> for greater clarity - but I'm not sure it's worth expending significant effort on. In the worst case, a
> CA who reads it like Doug suggests will result in a more secure system (vis-a-vis the discussion in
> the CA/Browser Forum regarding email scanning devices that 'click' on links).

Yea, I didn’t really think that 2-factor auth needed to apply to this, but I don’t see how it applies to any of the automated domain validation processes either. When a user requests the validation of a domain we'll provide them a Random Number via email, or one that they need to incorporate into DNS, Test Certificate or web site change. Once the email is received or the random value is in place, the CA checks for this (maybe upon being asked by the partner or applicant). I don’t see any place in these processes where 2-factor auth is applicable. Even in a managed account where an authenticated Applicant says: "I want to add this domain to my account" and we provide a Random Number for them to use to demonstrate control I don’t see a need for 2-factor auth for that "account".

I understand the increased importance on domain validation, but I'm not clear how we map this to domain validation at all, except perhaps for doing it manually via who-is by an RA (and RAs already need 2-factor auth).

If this is the case, then in what cases do you see 2-factor auth being a requirement where it was not before?

[Gervase Markham]

On 01/06/17 14:22, Doug Beattie wrote:
> If this is the case, then in what cases do you see 2-factor auth being a requirement where it was not before?

Well, Mozilla policy didn't require that all RA accounts had
multi-factor, only those directly capable of causing certificate
issuance. Maybe there was some other requirement somewhere which means
this addition is redundant?

An example of someone who didn't require it before who requires it now
would be someone who did EV research into the correctness of the company
information as supplied by the applicant, and marked it as "confirmed"
in the system. This is "performing a validation function", but it's not
"directly causing certificate issuance".

Gerv

[Gervase Markham]

On 01/06/17 13:59, Gervase Markham wrote:
> Perhaps this leads to the solution? We say:
>
> "enforce multi-factor authentication for all accounts capable of causing
> certificate issuance or performing RA or DTP functions as defined by the
> Baseline Requirements"

or "enforce multi-factor authentication for all accounts capable of
either causing certificate issuance or performing validation functions,
for certificates containing domains not owned or controlled by the
account holder"

Gerv

[Ryan Sleevi]

I liked your previous version better, if it had to be updated.

It would sound like you're suggesting "Enterprise RA" accounts should not
use multi-factor authentication, but given that they're part of the scope
of audited activities (that the CA must directly oversee), the use of
multi-factor authentication seems both entirely appropriate and necessary
to maintaining the integrity of such systems.

So my preference was
1) Originally worded
2) "performing RA or DTP functions"
...
3) This wording :P

On Fri, Jun 2, 2017 at 6:00 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 01/06/17 13:59, Gervase Markham wrote:

> > Perhaps this leads to the solution? We say:
> >
> > "enforce multi-factor authentication for all accounts capable of causing
> > certificate issuance or performing RA or DTP functions as defined by the
> > Baseline Requirements"
>

[Gervase Markham]

On 02/06/17 12:29, Ryan Sleevi wrote:
> 2) "performing RA or DTP functions"

I'll go with that :-)

Gerv