[email protected] writes: > > > On Nov 29, 2015, at 3:56 PM, Michael Richardson <[email protected]> > > wrote: > > > > > > It is my belief/memory that IKEv2 implementations should NOT limit SA > > (PARENT or CHILD) lifetimes based upon certificate lifetime or CRL lifetime. > > > > Neither rfc4945 (pki4ipsec) nor rfc7296 seems to confirm or deny this. > > Yet, I'm sure that this was consensus at some point. Maybe I've > > mis-remembered? > > What document did I miss? > > I don't remember one way or the other. It seems perfectly logical > to limit SA lifetime. This certainly seems to be what customers > expect (based on some feedback I've seen).
We have discussed about this, but I think we never really reached concensus on one thing. There are reasons to limit SA lifetimes, and there are reasons not to. Certificate lifetime is usually ok, as they are long lived, but CRL lifetimes are not something that should be used for limiting SA lifetimes. If you have for example hourly CRLs, that would mean that every connection will do reauthentication hourly and everybody does that reauthnetication at the same time, as they all use same CA, thus same CRL. It would be much better to implement it so that you store the certificate used for authentication and then put verification timers in the future when something happens, i.e. CRL expires etc. When the CRL expires, you download new CRL, and go through that and if you have any connections using any certificates on the CRL, you delete those connections. On the other hand if someones certificate gets compromized, or employee leaves the company, you do not want to wait until next CRL lifetime. You remove his account from the user database, and push that change out to the VPN gateways, and if there are any connections open using that account that got deleted, you remove those connections (i.e. re-evaluate your policy for existing connections after policy update). This will allow you to disable access in timely fashion and you can still use more usable times for CRLs and Certificates. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
