[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fixing IKE Phase 1 Authentication HASH
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.
> 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))
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.
> > 4. Negotiating Revised HASH
> It seems that the most natural way of negotiating this feature
> would be the first proposed - via new authenticated methods.
> The two others looks like a kludge.
That would be also my choice.
--
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: