| Main Archive Page > Month Archives > ipsec archives |
Re: [IPsec] Comments on draft-ietf-ipsecme-failure-detection-00
From: Yoav Nir <ynir_at_nospam>Date: Sun Sep 05 2010 - 18:31:21 GMT
To: Yaron Sheffer <yaronf.ietf@gmail.com>
On Sep 5, 2010, at 11:03 AM, Yaron Sheffer wrote:
> 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.
Issue #190
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/190
> - 5. Two method -> methods.
Done.
> - 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"?
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
> - 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.
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
> 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.
Issue #194
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/194
> - 10.2 load sharing sharing.
Done.
> - 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.
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.
> - 10.3: of course, it is possible that *both* implementations generate
> predictable/short SPI values.
They might.
Issue #195
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/195
> - Please drop Dave from the Acknowledgements.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec