Reported by Yaron Sheffer: 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"? At least one IKEv2 implementation chooses IKE SPIs in a very predictable manner. It starts with 0x0000000000001000 and increments by one for each successive IKE SA. Assuming not too many SAs, and QCD secrets not being replaced very often, it should be possible to create a dictionary of SPI pairs to QCD tokens by simply sending the likely pairs to the implementation, and getting the INVALID IKE SPI notification along with the QCD token. Throttling and rate limiting helps a little, but not if the pool of possible SPI pairs is small. Fortunately, to thwart this enumeration attack, it's enough for either the token taker or token maker to do the right thing and use random IKE SPIs. I suggest addressing the issue by requiring good random IKE SPIs for token makers. Please send comments to the list. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
