[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 8 byte aligement in ISAKMP
Naganand Doraswamy wrote:
> When the ISAKMP packet is not 8 byte aligned, we pad it with zero's to make
> it 8 byte aligned before we encrypt it during Oakley QM. Some packets
> require that we calculate hash on the payloads so that the other end can
> also authenticate us. When we calculate, do we also consider the padding? It
> is better that we consider the padding as well as it will be easier to
> verify on the other end. All we have to do is to calculate the length of the
> data on which to calcuate hash is (payload_len - isakmp header_len - hash
> payload_len - hash_data_len). We dont have to parse the ISAKMP payload to
> find out the lenght of the data on which to calculate hash. That way, if the
> hash fails we can drop the packet immediatly.
>
> On the other hand, if we dont use the pad in calculating hash, then the last
> byte of the hash should represent the lenght of the pad as that will help in
> calculating the lenght of the data on which to calculate hash.
You have to run a sanity check on the ISAKMP payload before you process it
anyway (and this processing includes verifying the hash). This check will
allow you to determine the true (minus the pad) length of the message.
If you don't run a sanity check you'd not only not be compliant with the
draft, you'd open yourself up to attack. I could send you a SA offer which
contained a TLV attribute with a huge, incorrect size. When you tried to
process this you'd jump off into never-never land and most likely crash.
The pad is not included in the hash that authenticates quick mode and this
shouldn't case anyone any grief since the true size can be determined from
normal payload processing-- validate, then process.
Dan.
References: