[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Use of Encryption in Heartbeat Packets

Andrew Krywaniuk writes:
> DoS Analyis
> -----------
> In your example with the SPI list, you assume that the SPI list only adds
> 200 bytes to the packet. This is not necessarily true in the DoS case
> because the adversary can make the packet as long as he wants.

True, but lets say the attacker adds 2048 bytes of spi list to the
packet. HMAC-MD5 of that 2048 bytes takes 308 µs (microseconds, my
previous email used ms instead of proper µs). That is still much
faster than decrypting even the 200 byte packet. 

If the attacker adds more you can ignore the packet because it is too
big.

> In general, full-packet HMAC authentication does not provide good DoS
> resistance.

We are already using full-packet HMAC authentication in the ESP and AH
protocols, so I don't really think this is an issue here... If
somebody wants to consume our HMAC-MD5 calculation resources then he
can send random full sized ESP packets.

> Security Weaknesses
> ---------------------------
> The bigger issue is whether not encrypting these packets will add any
> weaknesses to the framework.

True. I haven't seen any real weakness because of clear text heartbeat
packets. 

> If there was some kind of data analysis attack on SKEYID_a that was not
> practical before, it may become practical when the hash is not encrypted.
> Also, if people are concerned about the SPI list being sent in the clear,
> they will have no resort.

We are already generating HMAC-MD5 key from the SKEYID_e that is used
to calculate the ESP authentication MAC. In the ESP packet the result
of the MAC is stored in the packet after encryption. So if there is
such attack which gains from the seeing data, HMAC-MD5 hash of data
pairs, then we have much more serious problems than just breaking
heartbeats...

> We both agreed that we did not want encryption to optional. I think I'm
> starting to change my mind on this issue.

I think it is better to select either one and stick to it. IKE has way
too options already, I don't want to add another one. If WG thinks we
must encrypt the packets then we encrypt them and thats fine...

Perhaps it is better to wait before everybody has time to read the
draft and then we can ask about this in the Adelaide IETF meeting. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
Follow-Ups: References: