Re: draft-miller-secsh-umac-00.txt

[Damien Miller <djm%mindrot.org@localhost>]

On Wed, 13 Jun 2007, Wei Dai wrote:

> > Attached is a draft for the use of Ted Krovetz' UMAC (RFC4418) as
> > a SSH MAC. OpenSSH -current implements the umac-64 method described
> > in the draft under the name "umac-64%openssh.com@localhost".
> 
> Have you also looked at Ted's new VMAC algorithm? It's still
> in Internet Draft stage, but it's simpler than UMAC and is
> also significantly faster on many platforms, especially 64-bit
> platforms. Public domain implementations are available from
> http://www.fastcrypto.org/vmac/ and http://www.cryptopp.com.
> (Disclosure: I contributed several ideas to the current VMAC design
> and am a co-author of the VMAC draft.)

I had noticed it when we first started looking at UMAC, but it seems to
have progressed quite a bit since then - thanks for the pointer.

> Both UMAC and VMAC require unique nonces. Using the sequence number as
> the nonce as in your draft may cause nonces to be reused if someone
> takes a snapshot of an active SSH connection running an a virtual
> machine, and when that snapshot is restored, the SSH program sends out
> new packets before realizing that the connection is no longer valid.
>
> Unless there is a good reason to believe this can't occur, it would be
> safer to use random nonces instead.

I don't think that this is a very likely attack for the SSH protocol. The
attacker would need:

1. The ability to snapshot the SSH sender and resume it at will.
2. The ability to inject different data into the SSH sender once it has
   resumed, so that MAC nonces are reused with different data.
3. The ability to circumvent the symmetric crypto in SSH.

If all these came together, *and* the attacker was able to completely
break UMAC with the resulting data, then they could spoof the remote end
back to the local sender. The attacker would need to be able to do this
before the remote end gave up and, unless they are prepared to spoof TCP
at the sender, would get <= 1 TCP window of data from the SSH sender to
work with.

Such a scenario doesn't seem very likely: apart from needing to
cirvumvent the symmetric crypto in order to make the MAC match the
decrypted packet, the ability to snapshot and resume a VM is very likely
to imply access to the memory contents of the SSH sender, from which
they could read the MAC keys out directly.

If the attacker doesn't have any magic way around the symmetric crypto,
then they would have to guess, using their captive VM'd process as
an oracle. The smallest useful packet they could guess at would be a
SSH_MSG_CHANNEL_DATA packet:

  packet_len | padding_len | type | channel_id | data_len | data | padding
      u32          u8         u8       u32         u32

The smallest such packet would be for a single byte of channel data, so
the overall padded length would be 16 bytes, of which 1 byte would be
padding.

Even if we assume that the attacker's success criteria is injection
of *any* data into an open channel, then the only non-critical fields
in the packet are the data and the padding (2 bytes). If they got
packet_len, padding_len, type, or data_len wrong, then the packet
would not parse successfully. If they got channel_id wrong, then the
implementation would either disconnect or ignore the data, and most
sessions would have only a small number of channels open (OpenSSH's
default limit is 10). So there would be only around 2^16 correct guesses
in a space of 2^128.

On the other hand, using random nonces has two downsides: first, they
would either need to be added to the packet (overhead) or generated by
some agreed PRF (more protocol complexity). Secondly, UMAC performs best
when the nonces are monotonically increasing counters and so using a
per-packet random nonce would slow it down.

-d