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

RE: Use of Encryption in Heartbeat Packets



(For those who may be wondering, Tero's numbers are based on the packet
format which I am planning to use in my forthcoming draft.)

If anyone has any further comments, please send them ASAP, as I plan to
submit the draft later today.

Tero,

I don't disagree with your analysis, except on one point.

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.

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

Of course, the adversary could still flood the host with small packets, but
that is more likely to set off alarm bells on an external monitoring system.


Other Anti-clogging Mechanisms
------------------------------
However, there are other possible anti-clogging mechanisms that do not
require encryption. I would be amenable to using these instead.

For example, if the message id (or some other field in the plaintext of the
message) was generated via. a shared prf in a way that depended on the
sequence number (e.g. message id = first 32 bits of prf(SKEYID_A, seqno)),
then spoofed messages could be easily discarded.


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

If I remove encryption from the spec then anyone doing a security analysis
of ISAKMP will also have to consider the case of packets that are
authenticated but not encrypted (BTW, wasn't there talk of removing the
authenticated only bit from the header? This will have to be changed).

By making the security of heartbeat packets equivalent to that of quick mode
(actually higher because of the sequence number), I guaranteed that this was
not the case.

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 both agreed that we did not want encryption to optional. I think I'm
starting to change my mind on this issue.

Want I don't want is for people to end up saying that they would use my
heartbeat format but they are afraid of the possible security implications
because it's not encrypted. When I asked people about this topic, the
majority of people who responded said that it seemed safer to encrypt the
packets and I agree

I think what I will do is add a DONT_ENCRYPT option to the negotiation
protocol. However, the default setting (and the only MUST support) will be
to encrypt the packets.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.


> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@ssh.fi]
> Sent: Tuesday, March 07, 2000 11:55 AM
> To: akrywani@newbridge.com
> Cc: 'Chris Trobridge'; 'Andrew Krywaniuk'; 'IPSEC Mailing List @ tis
> labs'
> Subject: RE: Use of Encryption in Heartbeat Packets
>
>
> Andrew Krywaniuk writes:
> > Encryption does provide a "quick authentication check."
>
> I disagree this. I don't think it is going to be faster for any packet
> size in normal operation, and for slow ciphers it is going to be very
> much slower. On the other hand the saving offered by it are quite
> small compared to the doing the real MAC in the first place.
>
> What you are comparing is the speed of
>
> 1)	HASH(Last-CBC-Block || Message-ID) + Decrypt(1st-block)
>
> to the speed of the
>
> 2)	HMAC-HASH(Rest of the packet)
>
> to do the first check, and then in the case 1 you need to do also the
>
> 	Decrypt(rest of the packet after 1st block) +
> 	HMAC-HASH(Rest of the packet).
>
> Here the case 1 is the encrypted packet having MAC inside the
> encrypted part and the sequence number in the first block so random
> packets can be discarded after decrypting that one block. The case 2
> is when the packet has only MAC, and no encryption at all.
>
> If you don't have any spi's in the packet the packet "Rest of the
> packet" is going to be only the notify payload (12 + 16 = 28 bytes).
> So the packet in total is 28 bytes of header + 8 bytes of sequence
> number + 20 bytes of hash + 28 bytes of notify. The total length is
> going to be 84 bytes, and the encrypted part of it is 56 bytes. The
> authenticated part of the message is 28 bytes.
>
> If we assume IKE SA is using 3des-md5, then the speeds are about
> following:
>
> 1)	md5(last-cbc-block || message-id) = 6 ms
> 	3des-cbc of one block = 20 ms
> 	3des-cbc of the rest of the blocks = 119 ms
>
> in total it is going to be 26 ms + 119 ms + 30 ms.
>
> 2)	Hmac-md5 of 64 bytes = 30 ms.
>
> I.e in the DoS case you are saving for only the 4 ms, but in addition
> you need to do the extra decryption for the rest of the packet, so for
> each valid packet you waste 145 ms (total decryption time + the IV
> generation time).
>
> If the packet contains 200 byte spi list payload also, then the timing
> is going to be:
>
> 1)	md5(last-cbc-block || message-id) = 6 ms
> 	3des-cbc of one block = 20 ms
> 	3des-cbc of the rest of the blocks = 614 ms
>
> in total it is going to be 26 ms + 614 ms + 30 ms.
>
> 2)	Hmac-md5 of 256 bytes = 57 ms
>
> I.e in the DoS case you are saving for for 31 ms, but you are then
> wasting the 640 ms for each valid packet.
>
> For blowfish-cbc and md5 the values in the case 1 are little bit
> different:
>
> 1)	md5(last-cbc-block || message-id) = 6 ms
> 	blowfish-cbc of one block = 4 ms
> 	blowfish-cbc of the rest of the blocks = 18 ms
>
> So for the DoS case you save 20 ms for the DoS packet and do
> only 28 ms
> extra work for valid packet.
>
> For the larger packet the numbers are:
>
> 1)	md5(last-cbc-block || message-id) = 6 ms
> 	blowfish-cbc of one block = 4 ms
> 	blowfish-cbc of the rest of the blocks = 95 ms
>
> And for DoS case you save 47 ms, and you loose 105 ms in the valid
> packet case.
>
> > In formal-speak, encryption provides an O(1) authentication
> check of a NbnS
> > indicator of packet validity. (NbnS = Necessary, but not Sufficient)
>
> Yes, the time is O(1), but the constant factor is quite large (one
> hash for the iv and one cbc decryption) compared to the only hmac-hash
> for the rest of the packet.
>
> In the DoS case the saving of the cpu is quite small, but in the valid
> packet case the wasting of the cpu is quite large. For the faster
> cipher the numbers are not that bad, but you still waste quite a lot
> of cpu time for valid packets.
>
> I think the gain you get for decrypting the first cbc block first and
> checking the sequence number first is not enought to justify the
> wasting of the cpu time for normal valid packets.
>
> Ps. The numbers are from our crypto library using 500 MHz alpha. For
> the hardware accelerated case the overhead of starting the decryption
> etc is propably also going to play important role.
> --
> 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: