Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it)

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Jul 09, 2003 at 08:12:52PM -0400, Joel N. Weber II wrote:
> > > If you need to try again, just send SSH_MSG_KEXINIT again.
> > > 
> > > I'm willing to write up an internet-draft along these lines after IETF
> > > if people think it's a good idea.
> >
> > There's a problem though, and I'm not sure how it could be surmounted:
> >
> > The session ID needs to be derived from all messages involved in the key
> > exchange, even for the failed exechanges so as to avoid downgrade
> > attacks.
> 
> You're right; it makes perfect sense, but I hadn't realized that.
> 
> (Tangentially, if an attacker can intercept the messages between your
> application server and your Kerberos KDC, there is probably a
> downgrade attack there, unless your GSSAPI implementation is really
> clever.  We may want to say that a GSSAPI implementation MUST abort if
> an error happens which indicates that communication with the KDC
> failed.  Except that, like, KDC isn't a GSSAPI term.)

Well, no.  While what you say about Kerberos is true, the client would
fail to acquire GSS-API credentials in such cases and so would not even
propose gsskeyex.

(Incidentally, that is one problem that we'll try to address with the
Kerberos extensions work.)

> > But the session ID computation is kex-type specific so you'd have to
> > modify the formula for the session ID for each of the three(?) existing
> > kex methods.
> 
> Every kex method, I believe, has a V_C and a V_S input for data that
> needs to be in the hash that came before the key exchange algorithm
> started running.  I think all we have to do is define that for the
> first attempt at initial keyex, and for any rekeying (yes, ugh about
> the ``for any rekeying, but that's where we are now), they are what
> they are now, and for attempts at initial keyex after the first, V_C
> and V_S somehow end up being a hash of initial V_C and V_S plus the
> previous attempts at keyex.

The problem is that we're talking about modifying existing kex methods
that are defined in multiple different documents; although we're
modifying them to take into account a mode of operation not currently
available, we would be partially obsoleting these docs, and in terms of
IETF process I think that'll mean re-spinning the RFCs (don't even think
of getting this into the I-Ds now - or, rather, you can try, but I think
you'll be told by all that it's too late).

Cheers,

Nico
--