On Saturday, November 22, 2003 15:15:41 +1300 Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:
Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:Based on this, it seems clear that "implicit server authentication" in this context means authentication where the server's identity is proved only by its later ability to encrypt valid messages. This doesn't apply to the current diffie-hellman-group1-sha1 keyex, in which the server signs the exchange hash, and thus proves its identity and binds it to the algorithm negotiation and key exchange just completed.Not necessarily. My less tongue-in-cheek guess at the meaning of the text was that the "implicit" stuff was intended to make the first post-handshake message (service or global request or whatever the client happened to send there) play the same role as the Finished message in SSL, where the client and server do a mutual proof-of-possession of encryption and MAC keys via a pipeline-stalling message that prevents any further (sensitive) data from being exchanged until the PoP has concluded (the SSL Finished also authenticates the handshake messages). The signed exchange hash merely proves to the client that the server knows the master secret, but not necessarily that the client and server share encryption and MAC keys. Without this mutual PoP, the client could end up sending passwords to the server using an incorrect (and potentially weak) key if it's messed up something and derived the key incorrectly. Because there's no rationale included in the spec, I don't know if the need for mutual PoP was an SSH design requirement or not. If not then the current wording would be fine. If it is, then it'd have to be changed to make the PoP step explicit (which I guess would affect existing implementations).
At this point in the SSH protocol, we really only care about the server proving things to the client. The client gets a chance to prove its identity, and authenticate the algorithm negotiation and key exchange, during user authentication, which happens only after key exchange is complete.
If proof of possession of the derived keys was a design goal, the protocol as it exists today already does not meet the goal, since there is obviously _some_ case in which the requirement is not meant to apply (otherwise it wouldn't be conditional!). I would think that if this was a goal, it would have been called out by an explicit pipeline-stall, in the form of a pair of messages which behave like SSH_NEWKEYS (before you can proceed, you MUST both send your message and receive your peer's). Finally, note that in diffie-hellman-group1-sha1, the version and algorithm negotation as well as the key exchange itself (together, the equivalent of the TLS handshake) are authenticated by the signature at the end of the key exchange.
I believe it is clear from the original text and from the nature of the change that the requirement at that time WAS intended to apply to double-encrypting-sha1, and WAS NOT intended to apply to diffie-hellman.
I believe we can make any decision we want about how clients have to behave wrt this requirement, and it won't affect interoperability with existing servers or have any implementation effect on servers -- there is no way a server can observe whether the client waited, so I can't see any way for a client's behaviour in this regard to affect interoperability.
That said, I don't think there is any good security reason to require this behaviour with any well-behaved mechanism, and doing so will certainly render some mechanisms noncompliant, apparently including yours. It may be easy to fix, but what is the justification for making people do so?
-- JeffPS: In researching this, I had reason to go over section 5.3, which defines the various encryption algorithms. It contains the following text, which I believe may be inconsistent with RFC2026:
RC4 is a registered trademark of RSA Data Security Inc.