Discussion:
Logging EAP-TLS failures
Norman Elton
2018-11-01 19:58:30 UTC
Permalink
I'm using linelog to syslog RADIUS packets. I've found that if I call
my linelog in my "authorize" section, immediately after referring to
my EAP module, my linelog has access to all the certificate details.
Issuer, expiration, etc.

I'd like to have similar details when the certificate is invalid. If
the linelog is in the "authorize" section, right after my EAP module,
its never reached, as the EAP failure causes the whole authorize
section to fail immediately.

I've tried putting it in the post-auth section as well, but cannot get
it positioned such that the certificate details are available.

I've also tried configuring the EAP and linelog modules in a
"redundant" section, hoping that the linelog would pick up after the
EAP failure. No luck there either.

Am I headed in the right direction? Is there a way to catch the
certificate details in a linelog module after the certificate has been
found invalid?

Thanks

Norman
-
List info/subscribe/unsubscribe?
Alan DeKok
2018-11-01 20:11:52 UTC
Permalink
Post by Norman Elton
I'm using linelog to syslog RADIUS packets. I've found that if I call
my linelog in my "authorize" section, immediately after referring to
my EAP module, my linelog has access to all the certificate details.
Issuer, expiration, etc.
Yes.
Post by Norman Elton
I'd like to have similar details when the certificate is invalid. If
the linelog is in the "authorize" section, right after my EAP module,
its never reached, as the EAP failure causes the whole authorize
section to fail immediately.
The information about bad certificates isn't available.
Post by Norman Elton
Am I headed in the right direction? Is there a way to catch the
certificate details in a linelog module after the certificate has been
found invalid?
Not really.

Why are you looking for this?

Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/l
Norman Elton
2018-11-02 14:29:38 UTC
Permalink
Post by Alan DeKok
Post by Norman Elton
Am I headed in the right direction? Is there a way to catch the
certificate details in a linelog module after the certificate has been
found invalid?
Not really.
To help with troubleshooting, I'd like to be able to see why the
certificate validation failed.

I'm going to try Arran's suggestion to check the
Module-Failure-Message. I wasn't familiar with that one.

Thanks,

Norman
-
List info/subscribe/unsubscribe? See http://www.freer

Arran Cudbard-Bell
2018-11-01 20:29:27 UTC
Permalink
Post by Norman Elton
I'm using linelog to syslog RADIUS packets. I've found that if I call
my linelog in my "authorize" section, immediately after referring to
my EAP module, my linelog has access to all the certificate details.
Issuer, expiration, etc.
I'd like to have similar details when the certificate is invalid. If
the linelog is in the "authorize" section, right after my EAP module,
its never reached, as the EAP failure causes the whole authorize
section to fail immediately.
I've tried putting it in the post-auth section as well, but cannot get
it positioned such that the certificate details are available.
I've also tried configuring the EAP and linelog modules in a
"redundant" section, hoping that the linelog would pick up after the
EAP failure. No luck there either.
Am I headed in the right direction? Is there a way to catch the
certificate details in a linelog module after the certificate has been
found invalid?
In v3 it looks like the pairs are trashed in the cert validation fails.

This is somewhat fixed in v4 as we allow "callbacks" for cert validation,
and I believe part of that is the previously ascertained validation state
from something like OCSP.

I think we also add all the attributes to the session-state: list and they
likely remain accessible even on failure... But not 100% on that.

The best you could do for v3 is probably examine the stack of error
messages in %{request:Module-Failure-Message[*]}, and send a patch to add
the cert CN or another identifier to add an REDEBUG() call with the cert
CN that failed and the validation check that failed.

You may find just concating all the Module-Failure-Message attribute
instances as the code is today, already gives you the information you need.

-Arran

Arran Cudbard-Bell <***@freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/use
Loading...