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
