Hi Yoav,
I'm OK with discussing these issues later, now that they're on the
Tracker. Except for one - see below.
On 09/05/2010 09:31 PM, Yoav Nir wrote:
On Sep 5, 2010, at 11:03 AM, Yaron Sheffer wrote:
[snip]
- 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
This protocol cannot require anything from the token taker, because you
don't *know* it's a token taker - there's no signaling. So either we add
signaling, or we can only require random SPIs from the token maker.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
