[Servercert-wg] Ballot SC3: Improvements to Network Security Guidelines

Adriano Santoni adriano.santoni at staff.aruba.it
Wed Jul 11 22:53:09 MST 2018


Let's try again....


Il 11/07/2018 19:44, Dimitris Zacharopoulos ha scritto:
> 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
>
>
>
> _______________________________________________
> 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/20180712/04397b41/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4025 bytes
Desc: Firma crittografica S/MIME
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180712/04397b41/attachment-0001.p7s>


More information about the Servercert-wg mailing list