Subject: [IPsec] Puzzles in IKEv2

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 4 Mar 2015 10:45:28 +0300

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.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 04 Mar 2015 06:00:35 -0500

Hi Valery,

to make it easier for everyone, I suggest that you submit a new draft 
version.

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.

Thanks,
     Yaron

On 04/03/2015 02:45, Valery Smyslov wrote:
> Now it is completely described using puzzles in the IKE_SA_INIT and 
> IKE_AUTH exchanges.
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 4 Mar 2015 15:47:04 +0300

Hi Yaron,

> to make it easier for everyone, I suggest that you submit a new draft 

I completely agree with you - the amount of changes makes it difficult
to track them. We will definitely issue a new version shortly.

> 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."
>
> 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.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 05 Mar 2015 20:07:56 -0500

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:
>> "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.
>
> However, what the point to discard SK_* keys in this situation? All 
> the information
> attack, but once the keys are calculated, we should keep them, since 
> their calculation
> accidentally altered in the network, so probably the next 
> retransmitted message

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 6 Mar 2015 10:41:14 +0300

Hi Yaron,

> it slightly improves performance. Actually, I think it is a prototypical 

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?

> 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.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Mar 2015 13:48:27 +0200

> from the legitimate client is finished, inject IKE_AUTH message

I suggest we do similar thing we do for IKEv2 in general. I.e. if you
get IKE_AUTH message which does not pass ICV, you simply drop it. I
would expect most of the implementations do that already. Also before
you can verify the ICV you need to know the SK_a and to be able to get
that you need to calculate SKEYSEED, which requires g^ir, i.e 2nd half
of Diffie-Hellman.

So at that point you have already calculated the Diffie-Hellman. Also
implementation would be completley stupid if it would not store the
SKEYSEED and SK_* keys once it has calculated them, so I would expect
every implementation do that already, i.e. they will already keep
them, and there is no need to say anything about this in here.

> the result will be exacly the same.

Why would anybody ever repeat the D-H secret calculation, when they
have already calculated SKEYSEED (and SK_*) earlier?

Do we also need to say that for future notificaitons it would be nice
for implementations to keep the "cached" SK_* values stored in IKE SA,
and not to calculate the SK_* from the KE payloads for every single
packet? I do not think we need to say such thing, and I do not think
we need to say that once you have calculated the SK_* you keep them
until you delete the IKE SA.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 6 Mar 2015 15:34:25 +0300

> that you need to calculate SKEYSEED, which requires g^ir, i.e 2nd half

Agree.

> them, and there is no need to say anything about this in here.

I think there is no harm if the draft recommends such behaviour explicitely.
After all, it is about DDoS protection, so every thing that
concerns the desense, even evident, should be spelled out.

> packet?

That's what the draft recommends.

> I do not think we need to say such thing, and I do not think

It's better to spell this out, then to let implementers to do it wrong.

Regards,
Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 06 Mar 2015 12:32:13 -0800

Hi Valery,

Sorry if I was inconsistent on this one.

This is a performance optimization, and it's a trade off for the 
responder: Do I want to cache keys, thereby saving on CPU but wasting 
more memory on potentially useless SAs? So I suggest to make it a MAY, 
not a SHOULD.

Thanks,
	Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 7 Mar 2015 08:50:02 +0300

Hi Yaron,

> responder: Do I want to cache keys, thereby saving on CPU but wasting more 
> memory on potentially useless SAs? So I suggest to make it a MAY, not a 
> SHOULD.

At this point of our defense line we are defending against CPU consumption,
not memory consumption. We've already agreed to create an IKE SA state and 
the keys,
while computed, adds relatively little to the size of the state.

So I'm reluctant to make it "MAY". Probably a lowercase "should" with some
explanations of the reasons will satisfy you?

Regards,
Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 06 Mar 2015 22:02:59 -0800

Please keep it a SHOULD, but include the explanation.

Thanks,
	Yaron

On 03/06/2015 09:50 PM, Valery Smyslov wrote:
> not memory consumption. We've already agreed to create an IKE SA state
> and the keys,