Michael Richardson writes: > > We added a suspend commend, but since that deleted states on the > > initiator, it ended up sending delete's to the server. The server > > deleted the IKE SAs. Now the client can resume a connection that > > technically was ended by Delete. > > It seems that either the client shouldn't send deletes, or:
I think the original idea is that if the client or server send explict delete, that is supposed to mean that IKE SA is deleted, and all information about it should be deleted, including resumption. > > If the client comes back with a valid ticket within the valid expiry > > time, the server does not know if A) the IKE SA was already deleted > > and the ticket theoretically should no longer be valid or B) the server > > deleted the IKE SA due to liveness timeouts and the client comes back > > with tickets to resume this. > > the server should behave the same way regardless of who deleted the SA. If the server deletes the IKE SA, because of liveness failure, that is not explicit delete, i.e. not something that happened based on the adminstrative action or similar, but instead it could be just temporary failure in the network. So if the server deletes IKE SA because of livenss check failures it should not mean that resumption state or the IKE SA is permanently deleted. > >> >> The case of a cluster of gateways is not handled by the RFC. This is > >> >> alluded to at the end of the Introduction. > >> > >> > that was an unfortunate easy way to not address the problem of > syncing > >> > state between servers :) > >> > >> Can you explain what the problem is if the ticket is used more than > once > >> (with different gateways) within the time B? > > > So this indeed is the important question for all of these cases. What is > > the harm? Because why does the RFC state that deleted IKE SAs should not > > be resumed? > > I think that maybe the intention was that IKE SAs deleted by the server due to > operator action should never be resumed. Because the user changed their > password, or their 2FA was compromised, or ... > Maybe the state-lite way is that the identity that involved in the deleted > state is marked as needing re-authentication. This is what I think the RFC tries to say. I.e., if either end explictly did adminstrative action to delete the IKE SA, then it should not be possible to do resumption to it. Of course if the user crendentials were compromised or re-authentication is required that means that the configuration of the server has changed for that user, and then ticket should be invalid because the configuration is different. Normally the ticket is encrypted with key that is changed every time the server configuration changes, which means changing the server configuration will invalidate all tickets. If this is not wanted for change which only affects certain user, then ticket should contain user identification number or similar, and the configuration serial number for that user, and every time something changes in the user configuration which requires revoking outstanding tickets, the configuration serial number for that user is incremented. If client tries to use ticket which has wrong configuration serial number for user, then server will simply reject that ticket. Anyways server or client should NOT invalidate tickets just because it deleted the IKE SA because of liveness failures. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
