Subject: Re: [IPsec] certificate lifetimes vs SA lifetimes

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Dec 2015 12:14:46 +0200

[email-masked] writes:
> 
> > On Nov 29, 2015, at 3:56 PM, Michael Richardson <[email-masked]> 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-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 09:58:41 -0500

Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
    >> From: IPsec [mailto:[email-masked]] On Behalf Of Michael
    >> Richardson
    >>

    > It's listed as a requirement in 4301; section 4.4.2.1, Data Items in
    > the SAD, which is the obvious place one should look for requirements on
    > how IPSec/IKE interacts with PKI.

Yes, that would be an obvious place to look for CHILD SA lifetimes.
I didn't think to look in 4301 for requirements on IKEv2.

What about PARENT SA lifetimes?   :-)

    > See the bullet point 'Lifetime of this SA':

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Dec 2015 10:07:54 -0500 (EST)

> What about PARENT SA lifetimes?   :-)

Those are not negotiated, so if any side cares they can re-authenticate
the parent SA?

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 11:30:38 -0500

> any connections using any certificates on the CRL, you delete those

I think that this is the right approach to CRLs, and I'd like to see this
concept written down so that it can be referenced.  Knowing this helps the
security review for protocols that live on top of IPsec.

    > you can still use more usable times for CRLs and Certificates.

In context of how IPsec has been used for remote access to date, this is feasible.

In situations where IPsec might be used as part of an autonomic system, this
won't work with some protocol to do this.  OCSP can't help here because we
don't know when to do another OCSP, so I think the recommendation is going to
be to set the CRL lifetime shorter.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 01 Dec 2015 12:10:57 -0500

> Those are not negotiated, so if any side cares they can re-authenticate

The fact that they aren't negotiated, doesn't change the fact that there is a
lifetime. That it isn't negotiated is good: the lifetime of the two
certificates and CRLs could be very different.
Upon PARENT SA re-authentication, one will find out if the certificate is
still valid, and run all of the CRL checks.

So, if one limits the PARENT SA's lifetime to the CRL lifetime (which ought
to be less than the certificate's lifetime), then one will do all the
checking at the right time.

Tero's point, however, is that you don't have actually do all of that
rekeying.  You can simply look at the CRL, and if it turns out the key is
bad, you kill the SA, regardless of the PARENT SA lifetime.

---

From: <[email-masked]>
Date: Tue, 1 Dec 2015 17:25:06 +0000

> On Dec 1, 2015, at 5:14 AM, Tero Kivinen <[email-masked]> wrote:
> 

It might mean that, but if you recognize this issue, you can adjust the timers by a random fraction.  This is a classic answer to the problem of "everyone doing stuff at the same time" problem.  It's not as well known as it should be, unfortunately.

	paul