On Tue, 1 Sep 2020, Tero Kivinen wrote:

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.

Yes, this is why we (libreswan) add the conection serial created at
(re)load into the ticket. Even reloading the connection without a
change will invalidate all the issued tickets.

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.

for our implementation, global changes only take effect when reloading
the connection, so we are covered for this part.

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 don't understand why user authentication needs to be "stored". If a
user changes a password, their current IKE SA is not invalidated. If
a user certificate revoked, the current IKE SA is not invalidated.
Those checks are only repeated at re-authentication time, and session
ticket lifetime's should only be allowed to upto the re-authentication
time before requirting a re-auth.

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.

I don't think this is relevant, provided session ticket lifetime's have
a max of issue time + re-auth time. You might even want to refuse the
ticket if it is within 1 rekey time of this maximum to prevent needing
a rekey before the normal rekey time.

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to