Re: Some questions about "SSH Transport Layer Encryption Modes"

[Derek Fawcus <dfawcus%cisco.com@localhost>]

On Sun, Oct 19, 2003 at 07:51:58PM -0400, Bill Sommerfeld wrote:
> 
> For those still not satisfied, I invite anyone who wants
> "seamless"/non-blocking rekeying to write and submit a draft
> documenting how to negotiate the use of a different key cutover
> strategy with a consenting peer.

Well one problem here is that I believe there is at least one
implementation, which does not respond with SSH_MSG_UNIMPLEMENTED
to unknown messages.

So the (obvious) approach of sending a new Transport Layer message to
negotiate it wouldn't work straight away.

So how about the following (would need fleshing out):

#define SSH_MSG_NONBLOCK_REKEY 22

SSH_MSG_NONBLOCK_REKEY
boolean response

Then at some point early in the connection,  this message is sent followed
by one which we expect to get a response to.  If we get an UNIMPLEMENTED,
fair enougth we know it's not supported.  If we get the response to the
subsequent packet,  again it's not supported.  If we get this packet
with the response flag,  it is supported.

I'd guess one convenient place to send the message (for a client) would
be between the initial NEWKEYS and the SERVICE_REQUEST.

So client sends:

NEWKEYS,  NONBLOCK_REKEY(response=FALSE),  SERVICE_REQUEST

and expects to get back one of:


NEWKEYS,  NONBLOCK_REKEY(response=TRUE),   SERVICE_ACCEPT
NEWKEYS,  UNIMPLEMENTED,   SERVICE_ACCEPT
NEWKEYS,  SERVICE_ACCEPT

There could also be a DISCONNECT in there as normal if the service was
unacceptable.

The question is would anyone DISCONNECT because they didn't understand
the NONBLOCK_REKEY packet?

Theoreticaly either end could send the NONBLOCK_REKEY message,   and
they could pass in transit,  so one would have to be willing to cope
with a request where one wanted a response.  However this could be
dealt with.

Actually,  thinking about it.  Sending the message before the KEXINIT
message may be better - then either end can announce it's support for
this.  So one would have:

NONBLOCK_REKEY(response=FALSE), KEXINIT, ...

and expect back one of:

NONBLOCK_REKEY(response=TRUE),  NEWKEYS, ...
UNIMPLEMENTED, NEWKEYS, ...
NEWKEYS, ...

Thoughts?

DF