[strongSwan] Strongswan caching CRL's when setting is set to "no"

[Tobias Brunner]

Hi Eric,

>>> Does "<conn>.reauth_time” and leaving “break_before_make” alone force a reauth and certificate validity check on IKE/ISAKMP from non-cached crl’s?
>>
>> Could you please clarify your question (e.g. why do you mention break_before_make in this context?
> 
> make_before_break defaults to no.  1) no interruptions in link 2) impact on CRL test

It does add a delay to the online certificate validation (via OCSP/CRL) 
on the client, but not change the basic functionality.  Instead of 
validating the certificate while the SA is created, the client waits 
until the new SA is fully established (and tears down the SA if the 
certificate is not valid).

>> what do you mean with "from non-cached CRLs”?
> 
> This was testing to see if it would pull the CRL on each wreath.  In my mind, if the CRL is hosted and changes and the CRL is never reloaded from its source, a revoked certificate can be used up until a start/restart occurs

It can be used as long as there is no CRL available that revokes it (or 
a negative OCSP response).  If a cached CRL (or OCSP response) is still 
valid, that's what will be used without fetching anything (if the fetch 
fails, the cached status will be accepted unless strict revocation 
checking is enabled).  A restart or purging CRLs/OCSP responses at 
runtime (e.g. via a cron job) will affect the in-memory cache (which 
could also be disabled completely), if CRLs are also cached on disk, 
they have to be removed manually.

As mentioned before, relatively short-lived delta CRLs can be used to 
trigger more frequent fetches (or use OCSP for even more current status 
reports).

>> are you considering setting reath_time on the client or the server -
> 
> Yes.  No effect on reload CRL

No, it does not affect how/when CRLs are fetched.  But without 
reauthentication, certificates are currently not re-checked at all (i.e. 
a client could keep the IKE_SA alive indefinitely).  If you configure it 
on the server, it either initiates a reauthentication itself, if it can 
due to the config, or it requests the client to reauthenticate (the 
IKE_SA is deleted if the client does not reauthenticate in time).

>> and with what type of authentication/config?
> 
> Certs for auth

OK, unless you use virtual IPs, then both peers can initiate a 
reauthentication.

>> why do you mention ISAKMP, are you actually considering using IKEv1?).
> 
> Not considering IKEv1

OK, good.

> Looks like if the server cert is revoked, I will need to reach out to all spoke instances to bounce so they’ll find out it’s revoked.

They won't find out until (1) they reauthenticate/reestablish the IKE_SA 
and (2) they use a CRL that actually revokes the certificate.  Depending 
on how long the CRL is valid and the caching behavior (as discussed 
before) this can take a while.

Regards,
Tobias