Yoav Nir writes: > > Wouldn't it be better to use IKEv2 session resumption (RFC 5723) for > > those clients coming back. > > > > I.e if you resume old existing session then you do not need to do > > puzzle... And after the resume, the ticket is usually changed again, > > so the ticket would always be fresh. > > That’s possible. But session tickets are different from these > tickets in two ways: > > 1. Session tickets are time-limited with a rather short validity > period. If policy requires checking the certificate / password > every two hours, then the ticket cannot be valid for more than > that.
I do not think there is anything fundamental in session resumption that requires them to have short validity period. The server can of course remember which cert was uesd to authenticate the connection originally and do OCSP check or check the cert against CRL when connection is resumed. Also server can also whiteliste the IP after the resumption is successfull and then immediately require reauthentication from the client by using RFC4478 AUTH_LIFETIME notification with lifetime of 0. > 2. Session tickets must not be replayed, so the gateway has to use > some very strict anti-replay mechanisms. The best way would be for the server to reissue now ticket for every time client comes back. And server needs to check those tickets anyways and keep track of them and make sure they are not reused... > The proposed tickets can be valid for a long time, and while replay > prevention is desired, it doesn’t need to be very strict. I would assume each ticket only works once, and once you have connected successfully you get new ticket. If attacker somehow can get the ticket from the client (i.e. sees the connection attempt and blocks the client while at the same time stealing the ticket), then it can connect the server, but as it does not know the associated keying material, it will be able to create only half-open SA and in that case the server can just count such attempt and revoce the ticket after 3rd failed attempt or so. > This laxness has operational benefits. It’s easier to implement in a > cluster of gateways, and a ticket will be valid even for a user that > hasn’t connected in a while. This makes sense because the prize from > a replayed RFC 5723 ticket is great - a valid, authenticated > session. OTOH managing to replay this new kind of ticket only gets > you a half-open SA without bothering to solve a puzzle. Yes. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
