|Main Archive Page > Month Archives > ipsec archives|
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.
> - 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"?
I think it's enough to require this of the token taker.
> - 6. Consideration -> considerations.
> - 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.
> - 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.
> 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.
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.
> - Please drop Dave from the Acknowledgements.
IPsec mailing list