FIPS vs STIG

[Matěj Týč]

One of RHEL7 bugzillas [1] shows an interesting discrepancy between our 
content and STIG:

* We feature [2] a rule "Use Only FIPS 140-2 Validated Ciphers"
  * STIG has its own [3] "A FIPS 140-2 approved cryptographic algorithm
    must be used for SSH communications."

There is a discrepancy between the two - while we claim that the 
following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 
7, only three of them are recognized as such by the STIG:

* aes128-ctr(STIG)
  * aes192-ctr(STIG)
  * aes256-ctr(STIG)
  * aes128-cb
  * aes192-cbc
  * aes256-cbc
  * 3des-cbc
  * [e-mail]

I have confirmed correctness of our description with our FIPS SME Tomas 
Mraz (in CC), so this issue looks as a bug in STIG - either the 
requirement is too strict, so it is incorrect, or it is supposed to be 
strict, and it should therefore be reworded, and we need to create a new 
rule in our content.

What is the procedure in cases like this?

References:

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1781244
    [2]:
    https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig.html#xccdf_org....
    [3]:
    https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-14/findin...

[Steve Grubb]

On Wednesday, March 11, 2020 11:36:38 AM EDT Matěj Týč wrote:
> One of RHEL7 bugzillas [1] shows an interesting discrepancy between our
> content and STIG:
> We feature [2] a rule "Use Only FIPS 140-2 Validated Ciphers"
> STIG has its own [3] "A FIPS 140-2 approved cryptographic algorithm
> must be used for SSH communications."
>
> There is a discrepancy between the two - while we claim that the
> following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux
> 7, only three of them are recognized as such by the STIG:
> aes128-ctr(STIG)
> aes192-ctr(STIG)
> aes256-ctr(STIG)
> aes128-cb
> aes192-cbc
> aes256-cbc
> 3des-cbc
> [e-mail]
>
> I have confirmed correctness of our description with our FIPS SME Tomas
> Mraz (in CC), so this issue looks as a bug in STIG - either the
> requirement is too strict, so it is incorrect, or it is supposed to be
> strict, and it should therefore be reworded, and we need to create a new
> rule in our content.
>
> What is the procedure in cases like this?

Common Criteria allows the cbc mode (but not the 192 variants). So, that is 
another data point to consider that the STIG may be off on that one. However, 
3des is consider deprecated in the 800-131a. It is not disallowed and can 
still be used. But maybe its deprecation is the rationale for that one.

-Steve
> References:
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1781244
> [2]:
>
> https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig.html#xccdf_or
> g.ssgproject.content_rule_sshd_use_approved_ciphers [3]:
>
> https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-14/find
> ing/V-72221

[James Cassell]

On Wed, Mar 11, 2020, at 11:36 AM, Matěj Týč wrote:
> One of RHEL7 bugzillas [1] shows an interesting discrepancy between our 
> content and STIG:
> We feature [2] a rule "Use Only FIPS 140-2 Validated Ciphers"
> STIG has its own [3] "A FIPS 140-2 approved cryptographic algorithm
>
> must be used for SSH communications."
> There is a discrepancy between the two - while we claim that the 
> following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 
> 7, only three of them are recognized as such by the STIG:
> aes128-ctr(STIG)
> aes192-ctr(STIG)
> aes256-ctr(STIG)
> aes128-cb
> aes192-cbc
> aes256-cbc
> 3des-cbc
> [e-mail]
>
> I have confirmed correctness of our description with our FIPS SME Tomas 
> Mraz (in CC), so this issue looks as a bug in STIG - either the 
> requirement is too strict, so it is incorrect, or it is supposed to be 
> strict, and it should therefore be reworded, and we need to create a 
> new rule in our content.

Indeed, the STIG allows fewer ciphers than FIPS allows; the STIG currently says "If any ciphers other than "aes128-ctr", "aes192-ctr", or "aes256-ctr" are listed, the "Ciphers" keyword is missing, or the returned line is commented out, this is a finding." [4]

Similarly, for the MACs allowed, "If any ciphers other than "hmac-sha2-256" or "hmac-sha2-512" are listed or the returned line is commented out, this is a finding." [5]

More are permitted by FIPS than by SSH, but the STIG is FIPS compliant as-is, using a subset of the FIPS ciphers. From the Security Policy document for the certification [6],

Only the following ciphers are allowed:
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-cbc
- aes192-cbc
- aes256-cbc
- 3des-cbc
- [e-mail]
Only the following message authentication codes are allowed:
- hmac-sha1
- hmac-sha2-256
- hmac-sha2-512
- [e-mail]
- [e-mail]
- [e-mail]
> What is the procedure in cases like this?

I'd just configure the STIG subset of FIPS, and maybe ask DISA to add a clarification note to the STIG.  Many folks are concerned about the FIPS-permitted 3DES algorithm [7], "3DES is deprecated for all new applications and usage is disallowed after 2023"

V/r,
James Cassell

[4] https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_securi...

[5] https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_securi...

[6] https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-pr...

[7] https://www.cryptomathic.com/news-events/blog/3des-is-officially-being-retir...
> References:
> > [3]:
>
> https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-14/findin...

[Sean]

If memory serves, there is/was DOD/DISA guidance prohibiting use of all CBC
mode ciphers.  I couldn't tell you where to find it, but I recall having to
make those adjustments several years ago when I did that sort of thing.

Anyone running on an accredited network with continuous monitoring and
reporting is going to get dinged by ACAS (aka nessus) if CBC modes are in
use:
https://www.tenable.com/plugins/nessus/70658

--Sean

On Wed, Mar 11, 2020 at 12:11 PM James Cassell 
wrote:
> On Wed, Mar 11, 2020, at 11:36 AM, Matěj Týč wrote:
> > One of RHEL7 bugzillas [1] shows an interesting discrepancy between our
> > content and STIG:
> > We feature [2] a rule "Use Only FIPS 140-2 Validated Ciphers"
> > STIG has its own [3] "A FIPS 140-2 approved cryptographic algorithm
> >
> > must be used for SSH communications."
> > There is a discrepancy between the two - while we claim that the
> > following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux
> > 7, only three of them are recognized as such by the STIG:
> > aes128-ctr(STIG)
> > aes192-ctr(STIG)
> > aes256-ctr(STIG)
> > aes128-cb
> > aes192-cbc
> > aes256-cbc
> > 3des-cbc
> > [e-mail]
> >
> > I have confirmed correctness of our description with our FIPS SME Tomas
> > Mraz (in CC), so this issue looks as a bug in STIG - either the
> > requirement is too strict, so it is incorrect, or it is supposed to be
> > strict, and it should therefore be reworded, and we need to create a
> > new rule in our content.
>
> Indeed, the STIG allows fewer ciphers than FIPS allows; the STIG currently
> says "If any ciphers other than "aes128-ctr", "aes192-ctr", or "aes256-ctr"
> are listed, the "Ciphers" keyword is missing, or the returned line is
> commented out, this is a finding." [4]
>
> Similarly, for the MACs allowed, "If any ciphers other than
> "hmac-sha2-256" or "hmac-sha2-512" are listed or the returned line is
> commented out, this is a finding." [5]
>
> More are permitted by FIPS than by SSH, but the STIG is FIPS compliant
> as-is, using a subset of the FIPS ciphers. From the Security Policy
> document for the certification [6],
>
> Only the following ciphers are allowed:
> aes128-ctr
> aes192-ctr
> aes256-ctr
> aes128-cbc
> aes192-cbc
> aes256-cbc
> 3des-cbc
> [e-mail]
>
> Only the following message authentication codes are allowed:
> hmac-sha1
> hmac-sha2-256
> hmac-sha2-512
> [e-mail]
> [e-mail]
> [e-mail]
> > What is the procedure in cases like this?
>
> I'd just configure the STIG subset of FIPS, and maybe ask DISA to add a
> clarification note to the STIG.  Many folks are concerned about the
> FIPS-permitted 3DES algorithm [7], "3DES is deprecated for all new
> applications and usage is disallowed after 2023"
>
> V/r,
> James Cassell
>
> [4]
> https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_securi...
>
> [5]
> https://vaulted.io/library/disa-stigs-srgs/red_hat_enterprise_linux_7_securi...
>
> [6]
> https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-pr...
>
> [7]
> https://www.cryptomathic.com/news-events/blog/3des-is-officially-being-retir...
> > References:
> > > [2]:
>
> https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig.html#xccdf_org....
> > > [3]:
>
> https://www.stigviewer.com/stig/red_hat_enterprise_linux_7/2017-12-14/findin...
> >
>
> scap-security-guide mailing list --
> [e-mail]
> To unsubscribe send an email to
> [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...