Michael Richardson writes: > > Tero Kivinen <kivi...@iki.fi> wrote: > > 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. > > This is probably a rather bad thing.
If server configuration is changed to require AES-GCM instead of 3DES then I think all active tickets needs to be invalidated to make sure they do not work. Easiest way is to change the ticket encrypting key. Or if configuration is changed so that tunnels to 10.0.0.0/8 is no longer allowed... Global configuration changes are quite rare, and most implementations I know do not bother checking whether existing IKE SAs match the new policy or not, but simply delete all IKE SAs and recreates them. Of course things that do not affect existing IKE SAs like adding new users, or new networks etc are not really such global changes, and do not require IKE SAs to be recreated. Again if you want you can make your implementation so it matches the policy and all existing IKE or Child SAs, and deletes only those IKE or Child SAs which are against new policy, but that is quite complicated thing to do, especially as you might not have stored all information needed to match the policy (i.e., you might not have the original certificate used to authenticate the specific IKE SA, so you might not be able to match whether that has something that is no required by new policy). > > 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. > > In many cases there is a single configuration "template" which applies to all > users who authenticate with a certificate from a certain CA, or with a login > matching some pattern. > > In order to store the configuration serial number, on a per-user basis, then > some state is created a per-user basis. This does not sound like a horrible > thing to me, but it is probably something new. Almost always there is some per user data anyways, most commonly the password etc, and/or all kind policy information coming from the AAA server... I do not think people will configure remote users in such way, that anybody with EE cert signed with that CA can log in... Almost always they use EAP or similar and those have per user data. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
