I agree with Yaron that it should be the way it is now described in the draft. If either side deleted the IKE SA, then it should not come back to life through session resumption. Specifically, the client should not get reconnected without authentication. The laptop example is excellent. If I close my laptop in Tel Aviv, and fly to Stockholm, and some guy from baggage handling gets at my laptop, they should not be able to resume a session to my workplace. I should need to authenticate again (if I was dilligent enough to disconnect the session).
With a ticket-by-reference scheme, this is easy - the gateway deletes the ticket from the store when the IKE SA is deleted. With ticket-by-value this doesn't work. After a crash, the gateway gets presented with a valid ticket, and has no way of knowing whether the IKE SA associated with that ticket has or has not been closed. The gateway could keep a blacklist (ticket revocation list?) but that really does add lots of complexity. I think the spec should reduce this to a SHOULD, with an explanation in security considerations about what it means for ticket-by-value and ticket-by-reference. ________________________________________ Yaron Sheffer wrote: > Hi Pasi, > > Sorry for the late reply. > > I believe most people would NOT expect a properly terminated > (deleted) IKE SA to be resumed. To give one example, suppose I > "downsize" a user and revoke his access rights. Today I will simply > terminate (=delete) all his existing SAs, and then will rely on the > next IKE setup to revalidate the user with the AAA server, which > will correctly fail. Resumption would bypass this check. If you want to make sure the downsized user doesn't come back and bypass the AAA server, you need either ticket-by-reference or some gateway-side state to prevent use of tickets that have been revoked. In either case, it seems the gateway could prevent resumption in cases where the gateway closed the IKE_SA, but still allow it if the client closed the IKE_SA, no? (BTW, in case of ticket-by-value, the gateway doesn't need per-ticket "black list" -- e.g. Eric Rescorla's "stateless tokens" draft suggested using a fixed-size Bloom filter to keep track of tickets that should not be accepted any more.) But it seems regardless of whether we allow resuming a properly closed IKE_SA or not, this is an issue that should be discussed in the Security Considerations section. If most people would expect revoking access rights to work the way you describe, it might come as a surprise that it does not, when using ticket-by-value... > We could add a flag to the 2 notifications for the gateway to signal > to the client that it implements a different semantics, i.e. it is > willing to resume a previously deleted SA. Do you think this use > case is worth the added complexity? It seems we're looking at this from quite different angles -- to me, *not* allowing resumption here is added complexity, since it's more difficult to implement than allowing resumption...? Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
