[Servercert-wg] Ballot SC3: Improvements to Network Security Guidelines
Dimitris Zacharopoulos
jimmy at it.auth.gr
Wed Jul 11 10:44:30 MST 2018
Are all members who have declared participation to this WG, able to post
to this list without moderation?
Dimitris.
On 10/7/2018 12:44 πμ, Tim Hollebeek wrote:
>
> TL;DR: Ballot SC3 is exactly the same as Ballot 221, the only changes
> are to include a redline, and to make the requirements around password
> lifetimes a bit easier to read.
>
>
>
> -Tim
>
>
>
> *From:* Servercert-wg [mailto:servercert-wg-bounces at cabforum.org] *On
> Behalf Of *Tim Hollebeek
> *Sent:* Monday, July 9, 2018 5:05 PM
> *To:* servercert-wg at cabforum.org
> *Subject:* [Servercert-wg] Ballot SC3: Improvements to Network
> Security Guidelines
>
>
>
>
>
> https://github.com/cabforum/documents/compare/SC3-PasswordChangesDieDieDie?expand=1
>
>
>
> 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 Multi-Factor 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."
>
>
>
> Capitalize all instances of the defined term "Multi-Factor
> Authentication".
>
>
>
> 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 authentications which cross a zone boundary into a
> Secure Zone or High
>
> Security Zone, require Multi-Factor Authentication.
> For accounts accessible
>
> from outside a Secure Zone or High Security Zone
> require 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. Frequent password changes have been shown to cause users
> to select less
>
> secure passwords. If passwords are required to be
> changed periodically,
>
> that period SHOULD NOT be less than two years.
> Effective April 1, 2020,
>
> if passwords are required to be changed periodically,
> that period SHALL NOT
>
> be less than 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-07-09 17:00:00 EST
>
>
>
> End Time: not before 2018-07-16 17:00:00 EST
>
>
>
> Vote for approval (7 days)
>
>
>
> Start Time: TBD
>
>
>
> End Time: TBD
>
>
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180711/c5805984/attachment.html>
More information about the Servercert-wg
mailing list