[RADIATOR] CRLs not working with EAP TLS

Heikki Vatiainen hvn at open.com.au
Fri Mar 28 15:44:22 CDT 2014


On 03/27/2014 12:01 AM, Markus Moeller wrote:

>     Thank you for testing.  That is not good news. I was intending to
> use wired 802.1x  and a restart means switches may need to failover to
> the secondary Radius server especially if you want to do frequent CRL
> check and may disrupt clients when the regular EAP reauth happens.

I agree this causes disruption if CLRs are frequently regenerated. I
guess you generate the CLRs more frequently than once a day? When the
CRL is loaded, it should work for as long as the server is up so there
should not be need to restart just to make sure that the CRL works.

> Do
> you or other on the list have experience with optimised EAP reauth 
> switch settings ?

I would check that the switch, WLAN controller or any other RADIUS
clients uses a longer than 1 second (maybe 2-3 seconds depending on
network links) RADIUS reply timeout with at least 1 retry before failing
over to the secondary server. That is, 2 requests need to be lost.

Also, there would need to be more than one failure before switchover. I
do not have exact numbers, but even when the server is up the failover
should not happen too quickly especially if the requests need to be
proxied to different remote destinations.

>> my $ai = Net::SSLeay::X509_get_serialNumber($x509); \
>> my $rv = Net::SSLeay::ASN1_INTEGER_get($ai); \
>> print "ai: $ai rv: $rv\n"; \
>>
> 
> yes something like that. Is it Net::SSLeay or &Net::SSLeay ?

Both work, but leaving out & from function calls is how modern perl does
function calls. When & is *not* used, less things happen: @_ is not
passed as function argument when no () are used and prototype checking
is not turned off. In this case less is better: less to type (no &) and
no behind the back stuff happens. These days func() is preferred over
&func, &func() etc.

> I think I need to use P_ASN1_INTEGER-get_hex($ai).
> 
> Did you try this too ? In my test I got for $ai  0 which doesn't seem to
> be correct.

my $ai  = Net::SSLeay::X509_get_serialNumber($x509); \
my $rv  = Net::SSLeay::ASN1_INTEGER_get($ai); \
my $rv2 = Net::SSLeay::P_ASN1_INTEGER_get_hex($ai); \
print "ai: $ai rv: $rv rv2: $rv2\n"; \

This is what I get:

ai: 149343288 rv: 1 rv2: 01

It looks ok: 1 -> 01 but not 0.

>> It does look like a restart is needed when the CRL is refreshed. The
>> verify against CRL seems to work, but refreshing the CRL without restart
>> looks problematic.

>    This is then an underlying openssl issue isn't it ?  Do you know if
> OCSP will be available instead ?

Well, I do not know if this works as designed from OpenSSL's
perspective. There seem to be questions like this on the OpenSSL mailing
list too, but I did not see a definitive answer how CRL reloading should
be done. Or should delta CRLs used. Or should OCSP be used. Or if the
answer is something else.

There are no plans for OCSP currently. If there are ideas about how to
work around the problem with CRL reloading, comments would be
appreciated. Maybe use EAPTLS_CertificateVerifyHook to talk to a
external verify daemon or call OpenSSL verify utility?

Thanks,
Heikki

-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.


More information about the radiator mailing list