Hi Yaron,
Hi Valery,
to make it easier for everyone, I suggest that you submit a new draft
version.
I completely agree with you - the amount of changes makes it difficult
to track them. We will definitely issue a new version shortly.
Commenting on the pull request, specifically:
"If the puzzle is successfully verified and the SK_* key are calculated,
but the message authenticity check fails, the responder SHOULD save the
calculated keys in the IKE SA state while waiting for the retransmissions
from the initiator. In this case the responder may skip verification of
the puzzle solution and ignore the Puzzle Solution payload in the
retransmitted messages."
It seems to me that if any authenticity check fails, the responder MUST
NOT make any changes at all to its saved state. Anything else would
complicate implementations and create hard to analyze vulnerabilities. The
only gain here is saving a single PRF operation on the responder's side,
and it is not worth it.
I probably wasn't clear enough.
I was talking about the situation when IKE_SA_INIT exchange has been
already completed and the responder is waiting for the first IKE_AUTH
message. At this point the responder has all the needed information
to compute the Diffie-Hellman shared key, the SKEYSEED and the SK_* keys.
However, I assume that the responder should not do it immediately,
as the IKE_AUTH message could never arrive and it would be just
a waste of resources (and a subject to attack). Instead, the responder
starts computing the keys only when the IKE_AUTH request message
arrives. Moreover, if the responder gives a puzzle to the initiator,
then there is no point of doing any expensive computational operations
until the puzzle is verified, and this only can be done when the first
IKE_AUTH message arrives.
Once the IKE_AUTH message is received and the puzzle solution it contains
is verified the responder starts calculating DH shared secret, SKEYSEED
and the SK_* keys. Only after that can it verify authenticity of the
received
IKE_AUTH message. And if this check fails, then the message must be
discarded.
However, what the point to discard SK_* keys in this situation? All the
information
to compute them was in the IKE_SA_INIT, that has been already finished.
We have only postponed the calculation to defend ourselves against possible
attack, but once the keys are calculated, we should keep them, since their
calculation
is costly. And the IKE_AUTH message we've just discarded could be
accidentally altered in the network, so probably the next retransmitted
message
would be valid, so there is no point in discarding the keys and making
hard work twice.
Does this clarifies the idea?
Regards,
Valery.
Thanks,
Yaron
On 04/03/2015 02:45, Valery Smyslov wrote:
Hi all,
I've updated my previous pull request.
The source file and changes are available at
https://github.com/ietf-ipsecme/drafts/pull/2
Now it is completely described using puzzles in the IKE_SA_INIT and
IKE_AUTH exchanges.
Payload formats and IANA considerations
are also provided.
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
