Bug 1420910 - OpenSSH ciphers in practice do not meet the stated Common Criteria/FIPS approvals.
Summary: OpenSSH ciphers in practice do not meet the stated Common Criteria/FIPS appro...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.4
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Stefan Dordevic
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-09 20:46 UTC by Trevor Vaughan
Modified: 2017-08-01 18:42 UTC (History)
5 users (show)

Fixed In Version: openssh-7.4p1-2.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 18:42:47 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2029 normal SHIPPED_LIVE Moderate: openssh security, bug fix, and enhancement update 2017-08-01 18:11:55 UTC

Description Trevor Vaughan 2017-02-09 20:46:57 UTC
Description of problem:

The ciphers approved in the Common Criteria/FIPS reviews do not match the active cipher list in OpenSSH when running in FIPS mode:

Approved List:

aes128-ctr 
aes192-ctr 
aes256-ctr 
aes128-cbc 
aes192-cbc 
aes256-cbc 
3des-cbc 
rijndael-cbc@lysator.liu.se 

Active List:

3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com

Note the presence of the GCM ciphers.

Version-Release number of selected component (if applicable):

All since the 7.0 release and updated as of Feb 9, 2017.

How reproducible:

Put the system in FIPS mode and run 'ssh -Q cipher'

Comment 1 Shawn Wells 2017-02-09 21:05:33 UTC
FIPS paperwork @ 
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf

Certified algorithms are listed in '10.1.1 OpenSSH Configuration', which
reads:

> The user must not use DSA keys for performing key-based authentication
> as OpenSSH only allows DSA keys with 1024 bit size which are
> disallowed as per SP800-131A.
>
> The user must not accept DSA host keys potentially offered during the
> first contact of an SSH server as OpenSSH only allows DSA keys with
> 1024 bit size which are disallowed as per SP800- 131A.
>
> When re-generating RSA host keys, the crypto officer should generate
> RSA keys with a size of 2048 bit or higher according to [SP800-131A].
> The crypto officer should inform the user base to not use RSA keys
> with key sizes smaller than 2048 bits.
>
> In FIPS 140-2 mode, the following restrictions are applicable. When
> these restrictions are violated by configuration options or command
> line options, the module will not be in the FIPS mode of operation:
>
> • SSH protocol version 1 is not allowed
> • GSSAPI is not allowed
> • Only the following ciphers are allowed:
>     • aes128-ctr
>     • aes192-ctr
>     • aes256-ctr
>     • aes128-cbc
>     • aes192-cbc
>     • aes256-cbc
>     • 3des-cbc
>     • rijndael-cbc@lysator.liu.se
>
> Only the following message authentication codes are allowed:
>     • hmac-sha1
>     • hmac-sha2-256
>     • hmac-sha2-512
>     • hmac-sha1-etm@openssh.com
>     • hmac-sha2-256-etm@openssh.com
>     • hmac-sha2-512-etm@openssh.com
>
> Any use of other ciphers or algorithms will results in the module
> entering the non-FIPS mode of operation.

Comment 2 Jakub Jelen 2017-02-10 07:46:20 UTC
Thank you for the report. This is obviously bug. But:

The gcm ciphers are removed from the default list of offered ciphers (so with default configuration they can not be negotiated), which can be verified by running openssh in debug mode (ssh -vvv host) or when running sshd in test mode, for example

    sshd -T | grep ciphers

should not report these ciphers.

The problem is that they can be enabled by explicitly setting them in configuration files. I will take care of the changes. Is this expected to be fixed in the next Y release or earlier?

Comment 3 Tomas Mraz 2017-02-10 07:59:49 UTC
We were told by the FIPS test lab that they do not have to be explicitly disabled in the code. I think we should consult with them first. On the other hand I do not think we have a problem to add this explicit disablement in RHEL-7.4.

Comment 4 Jakub Jelen 2017-02-10 08:08:26 UTC
ok, thanks for the clarification.
But the other ciphers (blowfish, arcfour, chacha20-poly1305, ...) are disabled completely so there is some difference and at least small confusion for users.

Comment 5 Stephan Mueller 2017-02-10 08:17:04 UTC
FIPS 140-2 level 1 allows a per-policy deactivation of ciphers. I.e. it is allowed what has been done: the documentation specifies which configuration options are allowed (or not allowed).

As the documentation in the SP referenced in comment #1 excludes GCM, GCM shall not be configured.

There is no need to technically disable a given cipher if the guidance states what is allowed and what not.

Maybe the guidance could be more specific to provide a precise sshd_config configuration line that is mandated.

Considering such sshd_config configuration line, one could even argue that the offending cipher of GCM is technically disabled.

Comment 7 Shawn Wells 2017-02-10 22:04:29 UTC
(In reply to Jakub Jelen from comment #4)
> ok, thanks for the clarification.
> But the other ciphers (blowfish, arcfour, chacha20-poly1305, ...) are
> disabled completely so there is some difference and at least small confusion
> for users.

I think Jakub's comment captures the ask very well. 

(1) If a user places their system in FIPS mode and then runs 'ssh -Q cipher', GCM is shown in the output. This creates the impression GCM is allowed because other ciphers such as blowfish, arcfour, etc do not get listed. Can we have GCM not listed in the 'ssh -Q cipher' output when FIPS is enabled?

(2) The output of 'sshd -T | grep ciphers' and 'ssh -Q ciphers' show different algorithms when the system is placed into FIPS mode, which is confusing.

Comment 8 Shawn Wells 2017-02-10 22:06:31 UTC
s/show different algorithms/show different ciphers/r

Comment 9 Jakub Jelen 2017-02-13 08:55:49 UTC
Tomas explained the reasons why it was set this way. What the -Q switch to ssh does is to list the *supported* algorithms (from man ssh):

> -Q query_option
> Queries ssh for the algorithms supported for the specified version 2.

But not the default offered list. It should be visible by using -G switch, such as (not yet in RHEL7 as far as I know).

  ssh -G test | grep ciphers

If we would remove the GCM ciphers from the above "list", client nor server would not know them and specifying them in the configuration files would lead to errors (unknown ciphers), which might be possibly a regression.

On the other hand, we discussed something similar like a year ago about Fedora in the bug #1324493 which discussed removal of *-gcm modes, sha1-96 MAC and sha1 KEXes, which reflects the original request.

Comment 10 Tomas Mraz 2017-02-13 10:04:36 UTC
Jakub, I think it is up to you to consider whether removing the ciphers in the FIPS mode completely is risky or not. If the removal is properly documented I think we can go with that. It also will not affect non-FIPS mode at all.

Comment 19 errata-xmlrpc 2017-08-01 18:42:47 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2029


Note You need to log in before you can comment on or make changes to this bug.