Re: Key Re-Exchange

[Mats Andersson <mats%mindbright.se@localhost>]

Hi,

I agree that the draft might improve on clarity here.

On Wed, 4 Apr 2001, Markus Friedl wrote:
> is it true that no application data may be sent during key re-exchange?
> 
> how is this 'during key re-exchange' defined?
> 
> so, if you initiate the re-exchange, you have to wait for the KEXINIT
> from the peer, but since there might be some more packets one the
> wire i might get these messages before i get the KEXINIT.
> 
> the problem here is that i cannot tell whether my KEXINIT message
> did already arrive at the peer or whether the peer just ignores the
> KEXINIT message and just keeps sending applications messages.
> 

transport-draft says:
...
Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
...
This message is the only valid message after key exchange, in addition to
SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages. 
...
Implementations MUST NOT accept any other
messages after key exchange before receiving SSH_MSG_NEWKEYS.
...
More application data may be sent after the SSH_MSG_NEWKEYS packet has
been sent; key exchange does not affect the protocols that lie above the
Secure Shell transport layer.
...

This seems to imply that no other messages than the KEX messages should be
sent during the re-exchange (the state is not explicitly defined though,
or rather the definition is spread across several paragraphs).

> i think that the paragraph about the re-exchange should to be extended
> in the current transport-draft.

En exact definition of the state "key exchange" (valid for both "initial"
key exchange and later re-exchange) could be given in a short paragraph
like:

...
The transport layer enters key exchange state as soon as a KEXINIT message
is received. When this message is received, a party MUST respond with its
own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT
already was a reply. During key exchange the only valid messages, both for
reception and transmission, are the KEX packets (range 30-49) and
SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE. Any other messages
SHOULD be considered a fatal protocol error. The key exchange state ends
by each side sending an SSH_MSG_NEWKEYS message.
...

This should probably go somewhere into paragraph 5.1. "Algorithm
Negotiation". And be explicitly referred in the paragraph 7 "Key
Re-Exchange".

> what are other implementations doing?

We disable and flush the transmitter queue directly when a KEXINIT is
received and then send a KEXINIT directly (if it was not a "reply" to our
own KEXINIT). The transmitter is re-enabled directly after the NEWKEYS has
been sent. It is the exact same code for "initial" key exchange as for
re-exchange (minus the session id). This seems to work well with SSH Inc's
implementation (which is the only one we have tried it with).

Cheers,

/Mats