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

Re: Fixing IKE Phase 1 Authentication HASH



On 25 Nov 99, at 4:01, Tero Kivinen wrote:

> Valery Smyslov writes:
> > There is one problem with this approach. To calculate HASH you need now
> > to retain all the packets untill the end of exchange. This makes IKE state
> > unnecessary large. More important, it opens protocol to attacks, when
> > initiator sends big packets (i.e. SA with a lot of proposals) without completeng 
> > exchange (this problem also exists with current HASH definition). The possible
> > solution would be to change HASH definition as follows:
> 
> I tought that little bit earlier, but decided that it is better to
> have the protocol simple than to save few hunderd bytes of memory.

I don't think that this changes make protocol much more complicated. 
And note, that this would save not only few hundred of bytes under 
normal circumstances, but, possibly, tens of kilobytes in case of 
attack. This saving would have sense.

> > HASH_I = prf(SKEYID, hash(packet_1) | hash(packet_2) | hash(packet_3) |
> > hash(packet_4) | hash(packet_5))
> 
> If the memory consumption is really an issue, then I would define it
> to be like this (this is the another version I thought about):
> 
> HASH_I = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 |
> packet_5))
> HASH_R = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 |
> packet_5 | packet_6))
> 
> I.e when you send first packet you add it to hash, when you receive
> second packet you append it the hash (keeping the hash context around
> all the time), and so on. I.e you have one or two hash contextes
> around from the first packet until the calculation of hash.
> 
> You can manage with one, if you are able to duplicate the hash context
> after adding packet 5, but before calling the hash finalization
> function. If you cannot do that then you can make two hash contextes
> around and add each packet to both of them.
> 
> If we want to get around the need for second has in all cases we could
> define the HASH_R to be:
> 
> HASH_R = prf(SKEYID, hash(packet_1 | packet_2 | packet_3 | packet_4 |
> packet_5) | packet_6))

This definition is OK too. However, there is one minor implementation 
advantage in definition HASH as prf over concatenating of individual 
packet hashes. Anyway, you need to detect retransmitted packets. To 
do so you need either to keep last received packet or to keep its 
hash. The latter case has obvious advantages of memory saving, 
moreover, if you define HASH as prf over concatenating of individual 
packet hashes you will need only one hash operation over packet for 
both detecting retransmissions and authenticating. So, you will save 
not only memory, but CPU resources too.

> I.e the concatination of the HASH_I input hash and the packet_6.
> 
> Normal hash context is something like 100 bytes, so this would use
> only 100 or 200 bytes per each IKE SA being negotiated.
> 
> Having 5 hashes of packets consumes 80 or 100 bytes, so the cost at
> the end is almost the same. 
> 
> -- 
> kivinen@iki.fi                               Work : +358-9-4354 3218
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

Best regards,
Valera.




References: