Hi Yaron,
Going back to your original message (I guess not everyone read it to the
end :-)
If your guess is correct then it's a pity :-(
I don't understand how puzzles for IKE_AUTH can be mandatory without
breaking the protocol. The responder doesn't even know that the initiator
supports puzzles. At the very least, we would need to add a "puzzles
supported" notification.
I probably wasn't clear enough. I meant that if client supports
puzzles and accepts puzzle in IKE_SA_INIT, then it must also
solve puzzle in IKE_AUTH. In other words, the puzzles in IKE_SA_INIT
are optional for the client, but if they are accepted by client in
IKE_SA_INIT,
then they must also be used in IKE_AUTH.
The reason for such a strong requirement is that in the situation
when responder has already created the state but has not yet
authenticated the initiator it becomes an easy target
for DoS attack (as it is mentioned in the draft).
And again for IKE_AUTH, I don't see why with fragmentation you need one
puzzle solution per fragment. The major CPU cost (DH computation,
certificate stuff and decryption) comes once, after the message is
re-assembled. So it seems to me only one puzzle response is needed for the
entire message.
In this case the responder would become succeptible to the attack
when attacker emits forged fragments, that takes place of
good fragments from legitimate initiator in the reassembly queue.
To detect the forgery responder needs to check fragment
authenticity before inserting it into the reassembly queue.
That would require performing DH and calculating
SK_a*, but that is what we are willing to defer unless peer
proves that it is really really wants to setup connection and
is ready to spend quite a lot of resources to do it.
It would be possible to protect with puzzle only the very
first fragment, because as we have calculated SK_a*
it takes very little resources to verify the other fragments,
but fragments can arrive in any order, so puzzle must be
in each fragment. That is a bit unfortunate for the initiator, I admit.
Thanks,
Yaron
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
