[cabfpub] Ballot 221: Two-Factor Authentication and Password Improvements
Dimitris Zacharopoulos
jimmy at it.auth.gr
Thu Apr 5 01:29:34 MST 2018
On 5/4/2018 11:05 πμ, LEROY Franck via Public wrote:
>
> Hello
>
> “Certificate-based authentication can be used as part of Multifactor
> Authentication only if the private key is stored in a Secure Key
> Storage Device."
>
> Using a ‘SKSD’ doesn’t mean a 2 factors authentication.
>
> It only guaranties that the private key cannot be duplicated and/or
> stolen.
>
> When the SKSD is for example a smartcard under the sole control of a
> human being that keeps private the activation secret, then we have 2FA.
>
> When the SKSD is an HSM, most of the time the HSM is accessed
> programmatically with a passphrase that is stored in the ‘memories’ of
> the server (i.e. RAM, Database, INI file…) or with a software
> certificate ;-).
>
> If we take Diginotar as an example, the hacker found the activation
> secret of the HSM (thales one) in the RAM of the server and then gain
> access to the authenticated PKCS11 API in order to issue certificates.
>
> So we have to make a clear distinction when this is a human being that
> uses a GUI to validate a certificate issuance, and when systems
> communicate inside a secure zone using authenticated channels.
>
> Best regards
>
> Franck Leroy
>
Hello Franck,
The NSRs require (2.f) that each individual in a Trusted Role use a
unique credential. The main intent of this ballot is to enforce 2FA for
accessing a Secure Zone from an insecure Zone and for accessing services
(for example "approving the issuance of a Certificate") designated for
Trusted Roles from an insecure Zone.
So, yes, we are referring to individuals in Trusted Role capacity that
would need to have their private key in a FIPS (140-2 L2 overall L3
physical) or EAL4+ certified device, in order for Certificate-based
authentication to be used as 2FA.
Dimitris.
> *De :*Public [mailto:public-bounces at cabforum.org] *De la part de* Tim
> Hollebeek via Public
> *Envoyé :* mercredi 28 mars 2018 21:39
> *À :* Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> *Objet :* Re: [cabfpub] Ballot 221: Two-Factor Authentication and
> Password Improvements
>
> Thank you.
>
> *From:*Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Wednesday, March 28, 2018 3:29 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com
> <mailto:tim.hollebeek at digicert.com>>; CA/Browser Forum Public
> Discussion List <public at cabforum.org <mailto:public at cabforum.org>>
> *Subject:* Re: [cabfpub] Ballot 221: Two-Factor Authentication and
> Password Improvements
>
> Note, the redline doc doesn't quite align with this ballot text - look
> for "Multi-Ffactor" in the doc :)
>
> On Wed, Mar 28, 2018 at 3:25 PM, Tim Hollebeek via Public
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>
> Ballot 221: Two-Factor Authentication and Password Improvements
>
> Purpose of Ballot: The Network Security Working Group met a number
> of times to
>
> improve the Network Security Guidelines requirements around
> authentication,
>
> specifically by requiring two-factor authentication, and improving
> the password
>
> requirements in line with more recent NIST guidelines.
>
> While CAs are encouraged to improve their password requirements as
> soon as
>
> possible, a two year grace period is being given to allow
> organizations to
>
> develop and implement policies to implement the improved
> requirements, especially
>
> since some organizations may have to simultaneously comply with other
>
> compliance frameworks that have not been updated yet and are based
> on older NIST
>
> guidance about passwords.
>
> The following motion has been proposed by Tim Hollebeek of
> DigiCert and endorsed
>
> by Dimitris Zacharopoulos of Harica and Neil Dunbar of TrustCor.
>
> — MOTION BEGINS –
>
> This ballot modifies the “Network and Certificate System Security
> Requirements”
>
> as follows, based upon Version 1.1:
>
> In the definitions, add a definition for Multifactor Authentication:
>
> "Multi-Factor Authentication: An authentication mechanism
> consisting of two or
>
> more of the following independent categories of credentials (i.e.
> factors) to
>
> verify the user’s identity for a login or other transaction:
> something you know
>
> (knowledge factor), something you have (possession factor), and
> something you
>
> are (inherence factor). Each factor must be independent.
> Certificate-based
>
> authentication can be used as part of Multifactor Authentication
> only if the
>
> private key is stored in a Secure Key Storage Device."
>
> Add a definition for Secure Key Storage Device:
>
> "Secure Key Storage Device: A device certified as meeting at least
> FIPS 140-2
>
> level 2 overall, level 3 physical, or Common Criteria (EAL 4+)."
>
> In section 1.j., capitalize Multi-Factor Authentication, and
> strike the
>
> parenthetical reference to subsection 2.n.(ii).
>
> In section 2.f., add "(for accountability purposes, group accounts
> or shared
>
> role credentials SHALL NOT be used)" after "authenticate to
> Certificate Systems".
>
> Change section 2.g. to read:
>
> "g. If an authentication control used by a Trusted Role is a
> username and password,
>
> then, where technically feasible, implement the following
> controls:
>
> i. For accounts that are accessible only within Secure
> Zones or High Security
>
> Zones, require that passwords have at least twelve
> (12) characters;
>
> ii. For accounts that are accessible from outside a
> Secure Zone or High Security
>
> Zone, require Multi-Factor Authentication, with
> passwords that have at least
>
> eight (8) characters and are not be one of the
> user's previous four (4)
>
> passwords; and implement account lockout for failed
> access attempts in
>
> accordance with subsection k;
>
> iii. When developing password policies, CAs SHOULD take
> into account the password
>
> guidance in NIST 800-63B Appendix A.
>
> iv. If passwords are required to be changed
> periodically, that period SHOULD be
>
> at least two years. Effective April 1, 2020, if
> passwords are required to
>
> be changed periodically, that period SHALL be at
> least two years."
>
> In section 2.h., change "Require" to "Have a policy that requires"
>
> In section 2.i., change "Configure" to "Have a procedure to configure"
>
> Change section 2.k. to read:
>
> "k. Lockout account access to Certificate Systems after no more
> than five (5) failed access attempts, provided that this security
> measure:
>
> i. is supported by the Certificate System,
>
> ii. Cannot be leveraged for a denial of service attack, and
>
> iii. does not weaken the security of this authentication
> control;"
>
> Change section 2.n. to read:
>
> "Enforce Multi-Factor Authentication for all Trusted Role accounts
> on Certificate
>
> Systems (including those approving the issuance of a Certificate,
> which equally
>
> applies to Delegated Third Parties) that are accessible from
> outside a Secure Zone
>
> or High Security Zone; and”
>
> — MOTION ENDS –
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
>
> Start Time: 2018-03-28 15:30:00 EDT
>
> End Time: after 2018-04-04 15:30:00 EDT
>
> Vote for approval (7 days)
>
> Start Time: TBD
>
> End Time: TBD
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180405/8beaa7b5/attachment-0001.html>
More information about the Public
mailing list