[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fixing IKE Phase 1 Authentication HASH
Tero, some comments on your draft below.
> The authentication payloads (HASH or SIG) MUST be the last payload in
> the packet, and when it is calculated to the authentication HASH its
> contents MUST be all zeros, with proper length (either determined by the
> HASH algorithm or the public key used in the authentication).
>
> So in the main mode the initiator HASH is calculated as follows:
>
> HASH_I = prf(SKEYID, packet_1 | packet_2 | packet_3 | packet_4 |
> packet_5)
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:
HASH_I = prf(SKEYID, hash(packet_1) | hash(packet_2) | hash(packet_3) |
hash(packet_4) | hash(packet_5))
where "hash" is negotiated hash function.
This way we would save IKE state size by the cost of additional CPU usage.
But taking into consideration that hash function must be fast enough, I think
this could make sense.
> In the main mode the responder HASH is calculated as follows:
>
> HASH_R = prf(SKEYID, packet_1 | packet_2 | packet_3 | packet_4 |
> packet_5 | packet_6)
Again, I would suugest:
HASH_R = prf(SKEYID, hash(packet_1) | hash(packet_2) | hash(packet_3) |
hash(packet_4) | hash(packet_5) | packet_6)
Of course, there is no need to include hash(packet_6).
> In the aggressive mode the HASH is calculated as follows:
>
> HASH_I = prf(SKEYID, packet_1 | packet_2)
> HASH_R = prf(SKEYID, packet_1 | packet_2 | packet_3)
Again, I would suggest:
HASH_I = prf(SKEYID, hash(packet_1) | hash(packet_2))
HASH_R = prf(SKEYID, hash(packet_1) | hash(packet_2) | packet_3)
> With same kind of processing of packet 2 and 3 than was for packets 5
> and 6 in the main mode. Note, that the encryption of the final packet in
> the aggressive mode does affect the HASH, because there might be padding
> added to the packet 3 which must be then be included to the HASH.
>
> 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.
Regards,
Valera.
Follow-Ups:
References: