Can you tell OpenSSH to force a rekey according to a packet number limit?

Question

OpenSSH has a parameter in the config files (ssh_config and sshd_config) for both client and server called RekeyLimit.

The default values for it are:

RekeyLimit 1G 1h

Which will force a rekey after 1Gbyte of data has been sent using the current key of after 1h has passed since the last key was generated.

But rfc4344 make some recommendations about rekeying which refer to number of packets:

   Because of possible information leakage through the MAC tag, SSH
   implementations SHOULD rekey at least once every 2**32 outgoing
   packets.  More explicitly, after a key exchange, an SSH
   implementation SHOULD NOT send more than 2**32 packets before
   rekeying again.

Is it possible to tell OpenSSH to force a rekey according to number of packets instead of number of bytes?

Answer 1

Your answer is partially addressed in the SSH man page:

 RekeyLimit
     Specifies the maximum amount of data that may be transmitted
     before the session key is renegotiated, optionally followed a
     maximum amount of time that may pass before the session key is
     renegotiated.  The first argument is specified in bytes and may
     have a suffix of `K', `M', or `G' to indicate Kilobytes,
     Megabytes, or Gigabytes, respectively.  The default is between
     `1G' and `4G', depending on the cipher.  The optional second
     value is specified in seconds and may use any of the units docu-
     mented in the TIME FORMATS section.  The default value for
     RekeyLimit is ``default none'', which means that rekeying is per-
     formed after the cipher's default amount of data has been sent or
     received and no time based rekeying is done.

A default is already set to 1Gig and 4Gigs of data but what does that mean? If you're sending small packets, it would take a long time to rekey, if you're sending large packets, the re-keying would occur more frequently. So let me ask: "What do you think your goal is in setting this to packet amounts would accomplish?"

Rekeying was done so that no one could store/obtain/sniff chunks of data for cryptanalysis attacks. (And or side channel attacks). There is a cost to performing these types of attacks: Storage, time, knowledge of encryption/cryptanalysis. Outside of nation state sponsored programs to attack this, I have yet to see, read, or hear about a non state actor even attempting to pull this off. There are other ways to attack a system.

But to answer your question, there is no definitive method listed to do this (packet based rekeying) so you have an option: Baseline your traffic, divide total data sent, by packets sent, then use that as your rekey number. E.g. 1Gig of traffic / 1000 packets(average amount of packets it took to send 1Gig) = Rekey number.

Answer 2

I realize this is an old question, but others may stumble upon it. @Pandrei's question is legit for users of Common Criteria. However, as @munkeyoto indicates, OpenSSH gives you handles to play with the data volume. What @Pandrei didn't seem to understand was that at 1 GB of data, this is 2^28 packets given the smallest possible packet size in the SSH protocol for a specific encryption algorithm (16 bytes). So if you set the data limit at 1GB, then you would automatically be in compliance with the NDcPP CC protection profile. The number of packets is inconsequential since you can just do math to figure out whatever number of packets that is depending on the encryption algorithm that was negotiated. Specifically, see section 9.3.2 of RFC 4251:

Because MACs use a 32-bit sequence number, they might start to leak information after 2^32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [SSH-TRANS] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2^28 packets at the very most.

In the end, this is moot, since v2.0 of the NDcPP will replace the need for packet-based rekeying with data- and time-based limits as per the RFC recommendations.