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

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

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).

Peter.