openssh unix dev - Apr 2006 - your mail

> On Thu, 6 Apr 2006, Miller, Damien wrote:
> 
> > 
> > Does OpenSSH 4.3 support the use of the TLS ciphersuites that are 
> > supported in OpenSSL?
> > If so, is this a compile time option or a run-time option?  
>  Or can sshd
> > support both the SSL and TLS ciphersuites at the same time?
> 
> OpenSSH doesn't use SSL or TLS - the SSH protocol defines its 
> own transport protocol which is a little different. Have a 
> look at the "Ciphers" and "MACs" options in
ssh_config(5) to
> see what cryptographic methods are supported.
> 
> -d
> 
My initial question was a bit misleading.   I realize that SSH
and SSL have different ways of specifying what ciphers and MACs
are supported and different ways of negotiating the setup of
the transport layer.   SSH uses its Algorithm Negotiation packet
while SSL uses its Client and Server HELLO messages and its
CipherSuite definitions.  Comparing the fields in the SSH
Algorithm Negotiation message against the definition of a
CipherSuite (as used by SSL), you'll see that they specify the
same information components.

Now, my understanding, which may be flawed, is that SSH and SSL
use the same crypto library.   SSLv3 support both the SSL and
newer TLS CipherSuite which are required for FIPS-140 and DISA
certification.  This leads to my real question of whether SSH is
DISA / FIPS-140 compliant and, if so, how is that achieved.

Looking at the SSH Algorithm Negotiation message, it appears
that there isn't any field in the message that specifies how the
shared symmetric encryption key is generated.   Looking at
ssh_config(5), I can see where and how the supported ciphers are
specified.  But there is no place in the negotiation message
where the shared key generation mechanism is specified.   So if I
configure sshd to support, say 3des-cbc, how does the daemon know
which mechanism to use to generate the shared symmetric key for
the session.   And how do the SSH client and server communicate
which mechanism they can support so that the two endpoints know if
a connection setup is even possible?

Jim

Humphreys, James wrote:
> Now, my understanding, which may be flawed, is that SSH and SSL
> use the same crypto library.
No.  One SSH implementation (OpenSSH) happens to use the crypto library
from an SSL implementation (OpenSSL).  There's no requirement for this
to be so, and many other SSH implementations either have their own
crypto code or use something else.
> SSLv3 support both the SSL and
> newer TLS CipherSuite which are required for FIPS-140 and DISA
> certification.  This leads to my real question of whether SSH is
> DISA / FIPS-140 compliant and, if so, how is that achieved.
I don't know about DISA, but as far as FIPS-140 goes a given SSH
implementation might be, but AFAIK OpenSSH isn't.  There was apparently
some work toward FIPS-140 certification (see the list archives) but I
don't know if anything ever came from that.

I believe one sticking point would be the use of MD5 for key
fingerprints since MD5 isn't permitted by FIPS.  Another is that OpenSSH
has some of its own crypto code (eg rijndael/aes for older platforms),
which I imagine would have to be either disabled or certified.
> Looking at the SSH Algorithm Negotiation message, it appears
> that there isn't any field in the message that specifies how the
> shared symmetric encryption key is generated.   Looking at
> ssh_config(5), I can see where and how the supported ciphers are
> specified.
As far as I know, no permitted algorithms are specified by FIPS-140-2
for session key negotiation are permitted at all.
> But there is no place in the negotiation message
> where the shared key generation mechanism is specified.   So if I
> configure sshd to support, say 3des-cbc, how does the daemon know
> which mechanism to use to generate the shared symmetric key for
> the session.
In OpenSSH, the shared session key is always negotiated via
Diffie-Hellman.  The protocol could support others (and in fact RFC4432
specifies one based on RSA), but OpenSSH doesn't.

If you run "ssh -vvv yourserver" you will see something like this (all
on one line):

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,
diffie-hellman-group1-sha1

The first two methods use random DH groups from the set in the
"moduli"
file on the server, using SHA256 or SHA1 hashes respectively.  The
latter two use fixed DH groups specified in the SSH RFCs (which happen
to be a subset of the ones supported by IKE).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.