Subject: Re: additional core draft nits in need of WG attention.

From: [email-masked] (Peter Gutmann)
Date: Sat, 15 Nov 2003 19:22:59 +1300

[email-masked] (Niels =?iso-8859-1?q?M=F6ller?=) writes:
>Bill Sommerfeld <[email-masked]> 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 :-).

Peter.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 21 Nov 2003 12:54:42 -0500

On Saturday, November 15, 2003 19:22:59 +1300 Peter Gutmann 
<[email-masked]> wrote:

>    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