On Saturday, November 15, 2003 19:22:59 +1300 Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> wrote:
nisse%lysator.liu.se@localhost (Niels =?iso-8859-1?q?M=F6ller?=) writes:Bill Sommerfeld <sommerfeld%east.sun.com@localhost> writes:> > 10. Section 5, last paragraph. What is "implicit server > > authentication?" The whole paragraph is unclear. Can someone provide some fill-in text?I think it refers to key exchange methods like the ones used in tls and ssh1, where one party chooses the session key and encrypts it using the other party's public RSA key. Then you must consider the remote end unauthenticated until you have verified that she knows the session key.Here's my tongue-in-cheek interpretation from a code comment: /* [...] The spec says that after a key exchange with implicit server authentication, the client must wait for the server to send a service- accept packet before continuing, however it never explains what implicit (and, by extension, explicit) server authentication actually is. We therefore define it to be "Something completely different from what we're doing here", which means that we can send the two packets together without having to wait for the server */ I read through the surrounding text and tried to figure out what the point of this requirement was, couldn't really find any, and so came up with the above interpretation, which works nicely :-).
In an effort to come up with some clarifying text, I did some research on this, which seems to confirm what Niels said. Thanks to our friends at www.watersprings.org, I was able to look at the old versions of the draft. Back in 1997, the REQUIRED (and only) key exchange algorithm was double-encrypting-sha, and the paragraph in question looked like this:
One should note that server authentication in the double-encrypting key exchange is implicit, and the client doesn't really know the identity of the server until it receives a message from the server using the correct MAC and encryption. This means that an attacker could fool the client into using no encryption (if the client is willing to accept no encryption), and the client might in some cases send sensitive data, such as a password, before it notices that the server isn't responding properly. For this reason, it is recommended that clients should not accept "none" encryption unless explicitly requested by the user. Alternatively, they should wait for the server's response to the service request before sending anything else.
In the next version (-02), the "Alternatively, they should" got changed to a MUST, but the language describing the circumstances under which this was required got gutted, largely because the required keyex had been changed to diffie-hellman (a precursor of diffie-hellman-group1-sha1), which no longer had the problem.
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.
It seems clear that waiting until you received the first encrypted message from the server was desirable at the time with double-encrypting-sha, but it actually left a number of problems unsolved. The modern protocol is better in this respect, and any acceptable keyex protocol is ultimately going to have to tie the server's identity to the algorithm negotiation and key exchange.
It also seems clear that the requirement was intended to ensure that the client know certain things about the server before proceeding, and NOT to allow servers to assume any particular behaviour. I'd be extremely surprised to find any interoperability problems caused by a failure of a client to correctly obey this requirement.
Since the requirement is unlikely to have any effect on interoperability, and its original security purpose is no longer relevant, I propose dropping the requirement (and the paragraph under discussion) entirely. It may be desirable to introduce security considerations text indicating that to be secure, a key exchange algorithm MUST bind the server's identity to version and algorithm negotiation and to the key exchange itself.
-- Jeff