openssh unix dev - Jan 2015 - questions regarding session establishment in SSH

Hello,

I spent some time today with RFC4253, RFC5056 and the OpenSSH source code and I
have a few questions.

1) For authentication methods such as "publickey" that work by
providing a signature over a session identifier, is it fair to say that a MITM
attacker is unable to use a MITM attack to log in to the server the client meant
to log into? The reason I believe that to be the case is that the SSH protocol
appears to have both end point and unique channel bindings through its session
identifier mechanisms.

If that holds true, then if:
* publickey authentication is used on a connection, and
* a shared secret is available on both the SSH server and the SSH client, which
the server will only provide after a user authenticates, and
* the SSH server is able to provide the SSH client with the secret, then
 
An SSH client can safely conclude that no MITM attack has occurred.

Per my blog post at
https://www.danieldent.com/blog/ssh-requires-a-chain-of-trust/, I am looking for
an easy way to bring new hosts online and know that the initial connection to
them has not been subject to a MITM. I proposed a more complicated approach that
could work for any authentication method, but with further analysis I believe
that if the authentication method is restricted to ones which leverages channel
bindings, then all that is needed is to have a way to load a shared secret onto
servers.

2) How was the 16 byte/128 bit size of the cookie in SSH_MSG_KEXINIT chosen?

In earlier versions of the protocol, a 16 byte cookie would have had both the
client and the server contributing at least as much entropy as the output of the
hash function it contributed entropy towards (MD5).  But that no longer holds
true. Has there been any analysis done on the adequacy of a 16 byte cookie?

3) Regarding section 7.2 of RFC4253:

An explanation of how keys are chosen is given, ending with "This process
will lose entropy if the amount of entropy in K is larger than the internal
state size of HASH."

The keys described in 7.2 are chosen using the output of hash functions; there
is only so much entropy available in the output of those hash functions. If the
amount of entropy is less than the key size of the encryption functions, does
that not mean that the higher key size is only a dangerous illusion?

Thanks,

Daniel

---
Daniel Dent
https://www.danieldent.com/
https://twitter.com/DanielDent
https://www.linkedin.com/in/danieldent

On Mon, 12 Jan 2015, Daniel Dent wrote:
> Hello,
>
> I spent some time today with RFC4253, RFC5056 and the OpenSSH source
> code and I have a few questions.
>
> 1) For authentication methods such as "publickey" that work by
> providing a signature over a session identifier, is it fair to say
> that a MITM attacker is unable to use a MITM attack to log in to the
> server the client meant to log into? The reason I believe that to be
> the case is that the SSH protocol appears to have both end point and
> unique channel bindings through its session identifier mechanisms.
>
> If that holds true, then if:
> * publickey authentication is used on a connection, and
> * a shared secret is available on both the SSH server and the SSH client,
>   which the server will only provide after a user authenticates, and
> * the SSH server is able to provide the SSH client with the secret, then
>  
> An SSH client can safely conclude that no MITM attack has occurred.
Are you talking about a MITM that has a copy of the real target's host key?

If not, then the connection is already protected by the server's signature
using the hostkey over the session ID.

If you are talking about an active MITM with the host key, then they
can still succeed by just accepting any host key that the client presents
without bothering to check the signature it generated.

The channel binding in pubkey auth prevents a MITM from using the client's
public key to authenticate to the real host on their behalf. It doesn't
provide any guarantee that the host is what they expect, because the client
has already accepted that they trust the server by that point in the protocol.
> 2) How was the 16 byte/128 bit size of the cookie in SSH_MSG_KEXINIT
chosen?
You'd have to search the ancient ietf-ssh archives and/or early versions
of the internet-drafts for that.
> In earlier versions of the protocol, a 16 byte cookie would have had
> both the client and the server contributing at least as much entropy
> as the output of the hash function it contributed entropy towards
> (MD5). But that no longer holds true. Has there been any analysis done
> on the adequacy of a 16 byte cookie?
Not that I'm aware of, but I don't think it matters. Even 2^128 is
infeasible assuming the hash algorithm is sound.
> 3) Regarding section 7.2 of RFC4253:
>
> An explanation of how keys are chosen is given, ending with "This
> process will lose entropy if the amount of entropy in K is larger than
> the internal state size of HASH."
>
> The keys described in 7.2 are chosen using the output of hash
> functions; there is only so much entropy available in the output of
> those hash functions. If the amount of entropy is less than the key
> size of the encryption functions, does that not mean that the higher
> key size is only a dangerous illusion?
It's an illusion but with the smallest hash used being 160 bits and the
stretching being performed using a good hash function, it's hardly a
dangerous one.

-d