Logging EAP-TLS certificate details

[Matthew Newton]

On 19/03/2021 02:43, Roberto.Franceschetti at ocfl.net wrote:
> While each device has its own unique client certificate having the device's serial number as the CN in the cert, the hardware vendors is using a generic username of "user" when specifying the username during the authentication process.

Because the username isn't a useful thing with certificate auth, and 
they have to set it to something. You can't trust it as it's random data 
put in the RADIUS request by the NAS based on what the device says, 
rather than information from the certificate (which the NAS has no 
control over, and doesn't even look at).


> We see this "feature" of EAP-TLS that allows to specify a completely random username as a serious security risk, as there is no information being logged in the radacct table to indicate what certificate was used to authenticate a particular session.

What you choose to log or not is hardly a security issue. Was the user 
allowed on to the network based on spoofed data in User-Name? No, 
because it's ignored.


> Here is our scenario. Hundreds of IoT devices, each authenticating with certs, connecting/disconnecting multiple times per minute. All of them are logging in with the username "user". If one of those certificates is compromised and is used in a malicious way in a different device, while the radius accounting table will show us the IP address of the attacker, there will be absolutely no way to find out which of the hundreds of certificates we issued was abused, and we would thus not know which certificate was compromised and needs to be revoked.

Add the wanted certificate info to radpostauth and look there?


> We were able to log the certificate information and link it to the client's IP during the Access-Request via syslog by modifying this in the linelog:

Sure, or do the same with radpostauth.


> The above will ultimately probably allow us identify the compromised certificate if we're able to capture/archive the syslog data (which we do...), but this is a workaround - the certificate information should really be available in the radacct table as that's what's used to examine user's activity (time remaining connected, bytes transferred, time of connection and so forth).

radacct logs the accounting data. That's not the same as auth data, and 
is largely down to what the NAS has available about the session.

The certificate fields aren't part of anything the NAS knows about, so 
it won't tell you about it. NASes don't unpack EAP.


> Customizing the accounting queries in the dialup.conf however does not seem to work for adding the same TLS-Cert fields to the radacct table (we did of course modify the schema to add the extra TLS-Cert fields). The TLS-Cert fields are being filled with blank values in the radacct table. We're thinking it's probably because the various %{TLS-Client-Cert-nnnnn} are not available during the "Accounting-Request" process.

Yes, because the NAS doesn't know about the data in the cert.

You can try and send a User-Name attribute (e.g. with the certificate 
serial number or similar) in the auth reply, which the NAS should echo 
back as the User-Name attribute in the accounting requests.

You can also try setting the Class attribute in the auth reply, which 
again the NAS should echo back in the acct requests.

Some NASes will send enough information in the auth which will enable 
you to pre-create the accounting record, which will tie the two 
together. See sql_session_start in post-auth.

-- 
Matthew