[cabf_netsec] NCSSR Section 2.g.ii

Tim Hollebeek tim.hollebeek at digicert.com
Tue Mar 31 12:49:52 MST 2020


I can confirm Neil’s interpretation matches the intent back when we were writing it.  But the way these rules are written is very confusing, and splitting them out into easier to interpret chunks would be very helpful.

 

-Tim

 

From: Netsec <netsec-bounces at cabforum.org> On Behalf Of Clint Wilson via Netsec
Sent: Tuesday, March 24, 2020 2:00 PM
To: Neil Dunbar <ndunbar at trustcorsystems.com>; CABF Network Security List <netsec at cabforum.org>
Subject: Re: [cabf_netsec] NCSSR Section 2.g.ii

 

Neil’s description is how I read these excerpts as well. The text could definitely be made clearer and improved upon in other ways (imo, dropping direct recommendations for password complexity and instead pointing to other industry best practices guidance would be one such improvement).

 

-Clint





On Mar 24, 2020, at 9:05 AM, Neil Dunbar via Netsec <netsec at cabforum.org <mailto:netsec at cabforum.org> > wrote:

 

I don't read them as being contradictory.

The first sentence is simply saying that _if_ you are coming into a secure zone from a less-than-secure zone, multiple authentication factors are mandatory. Those factors may, or may not, include a password authentication. An example which might not: SSH into a high security zone, with the private key on a FIPS-140-2 device, and public key authentication selected, which then prompts for a One-Time-Password from the user to complete the login.

The second sentence is saying that _if_ such accounts _could_ be used from the outside (even if, in practice, they are not so used), _and_ they rely on a password, then the password regime must involve password complexity, retain history, employ a lockout function and so on. Thus, were my workstation in a secure zone, and I desired to log into an account which was in the same secure zone, I could do so with a single factor (password authentication), so long as the password regime was as described.

So I think they are complementary. That said, I think the text could be made a little clearer, if my understanding is indeed correct. On a point of principle, account lockout is something that I've always felt uneasy about, since it's so easy to use as an availability attack vector.

Cheers,

Neil

On 23/03/2020 20:14, Ben Wilson via Netsec wrote:

Aren't the two sentences in 2.g.ii. contradictory?  The first sentence says that MFA is required for Secure Zone / High Security Zone, and the second sentence says that passwords must be at least 8 characters, etc.

 

See

https://cabforum.org/2018/08/16/ballot-sc3-two-factor-authentication-and-password-improvements/  

 

    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;

 

Could it be reworded as follows?

 

ii.   For authentications from outside the CA's network, require Multi-Factor Authentication and implement account lockout for failed access attempts in accordance with subsection k; 

 

Ben





_______________________________________________
Netsec mailing list
Netsec at cabforum.org <mailto:Netsec at cabforum.org> 
http://cabforum.org/mailman/listinfo/netsec

_______________________________________________
Netsec mailing list
Netsec at cabforum.org <mailto:Netsec at cabforum.org> 
http://cabforum.org/mailman/listinfo/netsec

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20200331/f3f7e140/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/netsec/attachments/20200331/f3f7e140/attachment.p7s>


More information about the Netsec mailing list