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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
