Hi Yaron,
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.
What else could we recommend to do in this situation?
If responder deletes IKE SA in case it receives IKE_AUTH
message that doesn't pass ICV check, then it would give
an attacker an easy way to prevent legitimate initiator
to connect - just monitor the network and once IKE_SA_INIT
from the legitimate client is finished, inject IKE_AUTH message
containing garbage.
If responder keeps half-open IKE SA for a while waiting
for more IKE_AUTH messages, then I see no reason to repeat
calculating D-H shared secret with every received message -
the result will be exacly the same.
BTW, you youself suggested that the responder cache
the SKEYSEED once it is computed. Let me quote
your message from 5 December:
----------------------------------------------------------------
[...] There are two cases:
- The IKE SA is set up by a valid initiator.
- The IKE SA is set up by an attacker.
In the first case, the responder needs to compute SKEYSEED anyway. It
should compute it once and cache it, even if it sees multiple bogus
IKE_AUTH messages sent by attackers. [...]
In the second case, the attacker also pays the price if we have a puzzle
attached to IKE_SA_INIT. And the responder only computes SKEYSEED once,
and caches the result. [...]
----------------------------------------------------------------
So, have you changed your mind or is there some misunderstanding?
Besides, if this is really a message that was "altered in the network",
how do we know that we produced correct key material?
If the ICV check of IKE_AUTH message passed, then we know
that at least we are talking with the same peer who generated
IKE_AUTH message and KEi/r and Ni/r payloads in the IKE_SA_INIT message
that we've received.
If the check failed, then either IKE_AUTH
messages was altered, of some parts of IKE_SA_INIT
messages (KEi/r, Ni/r) were altered. If the latter is the case,
then nothing can be done - IKE_SA_INIT is already over.
But if the former is the case, then there is a chance
that the next received IKE_AUTH message (would it
be retransmission or just a genuine IKE_AUTH message from
legitimate initiator which an attacker was able to outpace
with a bogus one) would pass ICV check.
Regards,
Valery.
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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
