Re: Key Re-Exchange

[nisse%lysator.liu.se@localhost (Niels Möller)]

Markus Friedl <markus.friedl%informatik.uni-erlangen.de@localhost> writes:

> I have some questions regarding the 'Key Re-Exchange' (aka rekeying):
> 
> is it true that no application data may be sent during key re-exchange?

I'd say not true (see below).

> how is this 'during key re-exchange' defined?
> 
> i think that that the re-exchange starts when a KEXINIT message has
> been both sent _and_ received.

That sounds like the only reasonable definition. And the exchange ends
with the SSH_MSG_NEWKEYS message (which doesn't happen at the same
time for both directions).

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

I think you must process the application messages as normal. The peer
should eventually respond to the KEXINIT. If it doesn't within some
resonable time (say between your key reexchange interval and a tenth
of that), you may consider it a protocol error and disconnect. 

> what are other implementations doing?

lsh currently never *initiates* re-exchange, but besides from that
there are four states:

  /* A KEX_INIT msg can be accepted. This is true, most of the time. */
  #define KEX_STATE_INIT 0

In this state, we may or have not sent an KEXINIT ourselves. Packets
other than KEXINIT are processed normally. On reception of KEXINIT, we
enter KEX_STATE_IGNORE or KEX_STATE_IN_PROGRESS.

  /* Ignore next packet */
  #define KEX_STATE_IGNORE 1

Special case to ignore a bad guess from the peer. Obviously, 
an application data packet doesn't make sense in this state.

  /* Key exchange is in progress. Neither KEX_INIT or NEWKEYS messages
   * can be received */
  #define KEX_STATE_IN_PROGRESS 2

In this state, application packets are processed normally. I believe
lsh also expects the peer to accept application data in this state. I
also think this is reasonable thing to do: it should be easy to handle
for an implementation, and if application data isn't allowed, the
connection will appear to the user to freeze. Key re-exchange should
be transparent to the user.

  /* Key exchange is finished. A NEWKEYS message should be received, and
   * nothing else. */
  #define KEX_STATE_NEWKEYS 3

Currently, lsh only accepts NEWKEYS and DISCONNECT in this state. It
ought to also accept IGNORE and DEBUG as well.

The code in question is in connection_handle_packet in
http://www.lysator.liu.se/~nisse/lsh/src/connection.c.

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

Sounds like a good idea. I also believe application data should be
allowed during most of the key exchange. More precisely, at all times
except

  1. Between a KEXINIT message and any guessed packed.
  2. Between the final keyexchange message and NEWKEYS.

For the initial keyexchange, application data MUST not be sent before
NEWKEYS, but that is just because they wouldn't be properly encrypted;
from a pure protocol point of view, application data should be allowed
even then.

Finally, I don't think "application data" is a good term to use. It
sounds like SSL speak. The spec should say which messages, or ranges
of messages, that are allowed or disallowed at any time.

Regards,
/Niels