Hi Valery,
Thanks for the detailed clarification, and I still disagree... This
situation is very unlikely with correctly functioning peers, and I don't
think we should recommend acting on unauthenticated information, even if
it slightly improves performance. Actually, I think it is a prototypical
premature optimization.
Besides, if this is really a message that was "altered in the network",
how do we know that we produced correct key material?
Thanks,
Yaron
On 04/03/2015 07:47, Valery Smyslov wrote:
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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
