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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
