CRL & default_crl_days

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CRL & default_crl_days

Gregory Sloop
So, I'm working with an EAP-TLS system running under freeradius.

I've setup things to use a CRL [not OSCP] to revoke certificates and
all works well.

However, the parameter default_crl_days=XXX puzzles me.

Through trial and error [mostly error] I know that if I don't
regenerate the CTL every default_crl_days, the CRL expires and then
freeradius won't auth anything at all.

So, I thought - why should I set the default_crl_days to some low
number. I assume that it [the CRL] can be replaced with a "new" CRL,
should we need one, long before the default_crl_days limit is reached.
Is that correct?

So, if that's the case, what would be the downside of making the
default_crl_days equal to the validity of the CA itself, for example?
[e.g. If the CA cert is valid for 100 years, why not set the
default_crl_days to 36500+/- days too?]

I assume there's some other use, other than EAP-TLS, where doing this
might be a bad plan, but I'm afraid I can't think of one in the
EAP-TLS context with FreeRadius. Am I missing something?

[And I'd be glad to be pointed to another context, if there is one,
where setting a very long-ish default_crl_days would be bad - even if
it's fine in the setting I'm discussing. Knowing would be good
education.]

TIA

-Greg


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CRL & default_crl_days

Gregory Sloop

GS> So, I'm working with an EAP-TLS system running under freeradius.

GS> I've setup things to use a CRL [not OSCP] to revoke certificates and
GS> all works well.

GS> However, the parameter default_crl_days=XXX puzzles me.

GS> Through trial and error [mostly error] I know that if I don't
GS> regenerate the CTL every default_crl_days, the CRL expires and then
GS> freeradius won't auth anything at all.

GS> So, I thought - why should I set the default_crl_days to some low
GS> number. I assume that it [the CRL] can be replaced with a "new" CRL,
GS> should we need one, long before the default_crl_days limit is reached.
GS> Is that correct?

GS> So, if that's the case, what would be the downside of making the
GS> default_crl_days equal to the validity of the CA itself, for example?
GS> [e.g. If the CA cert is valid for 100 years, why not set the
GS> default_crl_days to 36500+/- days too?]

GS> I assume there's some other use, other than EAP-TLS, where doing this
GS> might be a bad plan, but I'm afraid I can't think of one in the
GS> EAP-TLS context with FreeRadius. Am I missing something?

GS> [And I'd be glad to be pointed to another context, if there is one,
GS> where setting a very long-ish default_crl_days would be bad - even if
GS> it's fine in the setting I'm discussing. Knowing would be good
GS> education.]

GS> TIA
GS> -Greg

===
Anyone care to respond to this query? I've done some looking, but I
really can't find any guidance...

Again, TIA for any light you can shed on the question!
-Greg



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CRL & default_crl_days

Gregory Sloop
In reply to this post by Gregory Sloop
GS> So, I'm working with an EAP-TLS system running under freeradius.

GS> I've setup things to use a CRL [not OSCP] to revoke certificates and
GS> all works well.

GS> However, the parameter default_crl_days=XXX puzzles me.

GS> Through trial and error [mostly error] I know that if I don't
GS> regenerate the CTL every default_crl_days, the CRL expires and then
GS> freeradius won't auth anything at all.

GS> So, I thought - why should I set the default_crl_days to some low
GS> number. I assume that it [the CRL] can be replaced with a "new" CRL,
GS> should we need one, long before the default_crl_days limit is reached.
GS> Is that correct?

GS> So, if that's the case, what would be the downside of making the
GS> default_crl_days equal to the validity of the CA itself, for example?
GS> [e.g. If the CA cert is valid for 100 years, why not set the
GS> default_crl_days to 36500+/- days too?]

GS> I assume there's some other use, other than EAP-TLS, where doing this
GS> might be a bad plan, but I'm afraid I can't think of one in the
GS> EAP-TLS context with FreeRadius. Am I missing something?

GS> [And I'd be glad to be pointed to another context, if there is one,
GS> where setting a very long-ish default_crl_days would be bad - even if
GS> it's fine in the setting I'm discussing. Knowing would be good
GS> education.]

===
Perhaps it would be helpful if I give what I understand of this
param, and someone can tell me if I'm right or not.

As I understand it, if the CRL is older than the default_crl_days
specified, it will ignore the CRL and ALL verification will fail.

If you use a very long default_crl_days value, then an attacker could
get you to accept a very old cached CRL by preventing you from
retrieving the "new" CRL. Thus, this could likely be a security vuln.
because you might not have all the proper revocations contained in a
"current" CRL, and you rely on a cached version.

By using a short default_crl_days you prevent any verification from
relying on a cached CRL for longer than the default_crl_days.

However in the FreeRadius setup I'm using, the FreeRadius server
doesn't need to retrieve the CRL from anywhere else. It's local to the
FreeRadius server.

So, a very long CRL default_crl_days doesn't seem like a problem, as
long as I make sure that the CRL on the FR server is current [i.e.
contains all the revocations I need.]

What I'm not certain about is: If I set default_crl_days to a really
large value - can I update the CRL more often than the set value. [I'm
virtually certain I can, but I'm not positive. It appears to be an
upper-value limit, not a lower-value limit. (i.e. It *can* be replaced
long before the default_crl_days expires, but it MUST be replaced
before it's age exceeds default_crl_days - or the certificate checking
will fail.]

So, is that right, in general?

TIA

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: CRL & default_crl_days

Michael Wojcik
I don't claim any expertise in this area, but RFC 5280 5.1.2.5 seems pretty clear:

        5.1.2.5 Next Update

           This field indicates the date by which the next CRL will be issued.
           The next CRL could be issued before the indicated date, but it will
           not be issued any later than the indicated date.

So yes, you can issue a new CRL before the date in the Next Update field.

--
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: CRL & default_crl_days

Eisenacher, Patrick
In reply to this post by Gregory Sloop
Hi Gregory,

> -----Original Message-----
> From: Gregory Sloop

[snip]

> So, I thought - why should I set the default_crl_days to some low
> number. I assume that it [the CRL] can be replaced with a "new" CRL,
> should we need one, long before the default_crl_days limit is reached.
> Is that correct?

Yes, this is correct.

> So, if that's the case, what would be the downside of making the
> default_crl_days equal to the validity of the CA itself, for example?
> [e.g. If the CA cert is valid for 100 years, why not set the
> default_crl_days to 36500+/- days too?]

Every certificate that is revoked after the crl's issuance is naturally not contained in it. So a client querying a crl for a certificate's revocation status will falsely accept every certificate that was revoked after the crl's issuance. The longer your crl is valid, the more revoked certificates will slip through the check. Plus, the client has no need to update the crl as long as it is valid. This problem is inherent to crls. As such, you want to make your crls as short running as possible and usable in your environment.

HTH,
Patrick Eisenacher
:��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,���
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CRL & default_crl_days

Jeffrey Walton-3
In reply to this post by Gregory Sloop
> So, if that's the case, what would be the downside of making the
> default_crl_days equal to the validity of the CA itself, for example?
> [e.g. If the CA cert is valid for 100 years, why not set the
> default_crl_days to 36500+/- days too?]

Because some clients won't check back for 100 years... Plus, these
things are cached, so the client may check more frequently but the
caching software may check every 100 years.

Gutmman does a good job with CRLs and OCSP in his book Engineering
Security (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). See
Chapter 8, PKI. From page 638:

    When a CA issues a CRL, it bundles up a blacklist of
    revoked certificates along with an issue date and a
    second date indicating when the next blacklist will
    become available. A relying party that doesn’t have
    a current CRL is expected to fetch the current one and
    use that to check the validity of the certificate...

Jeff

On Tue, May 6, 2014 at 7:36 PM, Gregory Sloop <[hidden email]> wrote:

> So, I'm working with an EAP-TLS system running under freeradius.
>
> I've setup things to use a CRL [not OSCP] to revoke certificates and
> all works well.
>
> However, the parameter default_crl_days=XXX puzzles me.
>
> Through trial and error [mostly error] I know that if I don't
> regenerate the CTL every default_crl_days, the CRL expires and then
> freeradius won't auth anything at all.
>
> So, I thought - why should I set the default_crl_days to some low
> number. I assume that it [the CRL] can be replaced with a "new" CRL,
> should we need one, long before the default_crl_days limit is reached.
> Is that correct?
>
> So, if that's the case, what would be the downside of making the
> default_crl_days equal to the validity of the CA itself, for example?
> [e.g. If the CA cert is valid for 100 years, why not set the
> default_crl_days to 36500+/- days too?]
>
> I assume there's some other use, other than EAP-TLS, where doing this
> might be a bad plan, but I'm afraid I can't think of one in the
> EAP-TLS context with FreeRadius. Am I missing something?
>
> [And I'd be glad to be pointed to another context, if there is one,
> where setting a very long-ish default_crl_days would be bad - even if
> it's fine in the setting I'm discussing. Knowing would be good
> education.]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Loading...