Subject: [IPsec] Comments on draft-ietf-ipsecme-failure-detection-00

From: Yaron Sheffer <[email-masked]>
Date: Sun, 05 Sep 2010 11:03:06 +0300

In general, the draft is in good shape. But IMO, we have one major 
security issue left: the dependence on SPI values which potentially come 
from a small space, i.e. may be repeated in normal operation, or may be 
coerced into repeating.

Detailed comments:

- 3. I would have preferred the token to be resistant to stealing (and 
duplication), in which case it can be sent in the *first* AUTH message. 
If we ensure that the token maker's SPI is long/random (see below), this 
might be possible.

- 5. Two method -> methods.

- 5.1: this method is indeed problemmatic if SPIi/SPIr pairs are 
repeated with high probability. If SPI pairs only repeat across reboots 
(somewhat unlikely), then an "epoch" (time of last reboot) value can be 
included to mitigate this problem. This is still close enough to stateless.

A possible solution, providing freshness and mitigating some of these 
issues, is to use the entire message sent by the client (typically, a 
protected IKE liveness test) as a nonce. So the token maker sends: 
HASH(HASH(SPIi | SPIr | SECRET) | client-message). This doesn't add 
state, because the client needs to keep the message around for 
retransmissions. But it doesn't work with the technique described in 
Sec. 9.2.

Alternatively it would simplify things immensely if we mandate that SPIs 
be random for implementations that support QCD (possibly only on the 
gateway side). Can we do it without having to "update RFC 4306"?

- 6. Consideration -> considerations.

- 9.1: this is not really a MUST, let's use some non-RFC 2119 wording.

- 9.3: this entire discussion is probably redundant, because when a node 
fails in the LS cluster, you switch to another node. Implementing QCD on 
top of this is probably an overkill. If we remove this section, we can 
get rid of sec. 5.2 as well, and we can focus on a single recommended 
way to generate the token, which would make analysis that much easier.

- The security considerations are focused on details of the QCD 
solution, rather then on the threats we are dealing with. These threats 
are non-trivial to describe, since an active MITM attacker can easily 
cause an IKE SA to be reset. OTOH, we don't want an active non-MITM 
attacker to be able to do so. We need to analyze the threats in order to 
select a secure, but not overlay complex solution.

- 10.2 load sharing sharing.

- 10.2 seems to propose a different (and better?) solution for the issue 
raised in 9.3. These sections need to be consistent, and also with Sec. 5.2.

- 10.3: of course, it is possible that *both* implementations generate 
predictable/short SPI values.

- Please drop Dave from the Acknowledgements.

Thanks,

     Yaron

---

From: Yoav Nir <[email-masked]>
Date: Sun, 5 Sep 2010 21:31:21 +0300

> If we ensure that the token maker's SPI is long/random (see below), this 

Issue #190
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/190

> - 5. Two method -> methods.

Done.

> gateway side). Can we do it without having to "update RFC 4306"?

I think it's enough to require this of the token taker.

Issue #191
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/191

> - 6. Consideration -> considerations.

Done.

> - 9.1: this is not really a MUST, let's use some non-RFC 2119 wording.

I disagree. We are giving requirements for implementations that conform to this spec. The requirements vary by the role that the implementation plays: RA client, RA gateway, Site to site gateway, or host.

Issue #192
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/192

> way to generate the token, which would make analysis that much easier.

I disagree. Section 9.3 is about an active-standby configuration without synchronization. a failover is the same as a reboot, only faster.

Issue #193
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/193

> The security considerations are focused on details of the QCD 

Issue #194
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/194

> - 10.2 load sharing sharing.

Done.

> raised in 9.3. These sections need to be consistent, and also with Sec. 5.2.

Disagree. 10.2 talks about load sharing clusters with synchronization, which is different from the active-standby cluster without synchronization. Of course solutions are better there.

> predictable/short SPI values.

They might.

Issue #195
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/195

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 05 Sep 2010 22:17:48 +0300

Hi Yoav,

I'm OK with discussing these issues later, now that they're on the 
Tracker. Except for one - see below.

> On Sep 5, 2010, at 11:03 AM, Yaron Sheffer wrote:
[snip]

> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/191
This protocol cannot require anything from the token taker, because you 
don't *know* it's a token taker - there's no signaling. So either we add 
signaling, or we can only require random SPIs from the token maker.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Sep 2010 14:04:08 +0300

> signaling, or we can only require random SPIs from the token maker.

I think best option is to add text saying that token makers MUST use
SPIs that looks like random, and that should be enough to make the
QCD_TOKENs generated by token makers unpredictable.
-- 
[email-masked]