Bug 1420910

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.se
>
> Only the following message authentication codes are allowed:
>     • hmac-sha1
>     • hmac-sha2-256
>     • hmac-sha2-512
>     • hmac-sha1-etm
>     • hmac-sha2-256-etm
>     • hmac-sha2-512-etm
>
> Any use of other ciphers or algorithms will results in the module
> entering the non-FIPS mode of operation.

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?

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.

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.

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.

(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.

s/show different algorithms/show different ciphers/r

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.

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.

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