Bug 1067625

Summary:	Connection to embedded SSH servers fails in FIPS mode
Product:	Red Hat Enterprise Linux 7	Reporter:	Hubert Kario <hkario>
Component:	openssh	Assignee:	Petr Lautrbach <plautrba>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0	CC:	tmraz
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-09-30 19:23:45 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1053107
Bug Blocks:

Description Hubert Kario 2014-02-20 18:42:58 UTC

Description of problem:
When connecting to embedded SSH server the connection is dropped by other side.
It happens when the other side supports only Diffie Hellman key exchange but can't handle all DH key sizes (over 4096 bit in particular).

Version-Release number of selected component (if applicable):
openssh-6.4p1-7.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Set machine to FIPS mode
2. ssh -vv -o "Ciphers 3des-cbc" -o "KexAlgorithms=diffie-hellman-group-exchange-sha1" localhost

Actual results:
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192)

Expected results:
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<2048<8192)

Additional info:
According to NIST SP 800-57, 3DES should be used with 2048 bit DH. Strict FIPS guideline is to never use DH keys over 3072 bit.

Marking as regression since OpenSSH in RHEL 6 does not negotiate DH over 4096 bit in any configuration.

Comment 2 Petr Lautrbach 2014-02-20 19:08:54 UTC

This report only describes the 3rd party software bug. According to RFC:

The server should return the smallest group it knows that is larger
   than the size the client requested.  If the server does not know a
   group that is larger than the client request, then it SHOULD return
   the largest group it knows.

Described server drops the connection instead of providing the largest group it knows.

SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) says, that the client prefers 7680bits group but it will accept a group of size 2048 bits at minimal. So there's no conflict with any specification given that it's the server who choose the group. 

This should be really fixed on the other side.

Comment 3 Hubert Kario 2014-02-20 19:18:48 UTC

I'm not saying that the other side is RFC compliant. Far from it. Not only it does not support grooup14 DH exchange (which is secure and acceptable in FIPS mode) but also, as you pointed out, doesn't select the highest DH group size it supports.

That being said, our side may propose parameters that meet NIST recommendations, FIPS limits and limitations of the other side *without* compromising security when connecting to other, RFC compliant, servers.

Comment 5 Tomas Mraz 2014-02-20 22:56:48 UTC

I'm sorry, but I do not see as blocker at all. Also the FIPS mode limitations are not something that we would expect "broken" client to work with.

Comment 7 Hubert Kario 2014-02-21 11:58:28 UTC

(In reply to Tomas Mraz from comment #5)
> I'm sorry, but I do not see as blocker at all. Also the FIPS mode
> limitations are not something that we would expect "broken" client to work
> with.

I'd argue that openssh by suggesting 7k DH breaks FIPS mode. The problem is that normally openssh negotiated md5 based hmac, so it uses DH sizes for 128 bit ciphers. In FIPS mode the smallest HMAC it can use is SHA-1. Because of that, it uses the DH group sizes for 160 bit ciphers (7k or 8k bit).

But if you don't consider it significant violation of FIPS mode, we can leave it as is for now.

Comment 8 Tomas Mraz 2014-02-21 12:46:11 UTC

I don't see it as "significant violation of FIPS mode" at all.

Comment 9 Hubert Kario 2014-09-30 17:03:49 UTC

I raised the issue with upstream and they don't consider this to be an issue or willing to fix.

This probably should be closed as won't fix.