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 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.
It seems that you see that deleting the CHILD (IPsec) SA on failure of a
liveness check is enough savings. I don't know how universal this thought
process is. Certainly, if one has limited hardware for IPsec slots, then it
conserves the expensive bit.
If one keeps the parent SA around, then one has some state in which to store
per-user data.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
