We have several hundreds of IoT WiFi devices, each authenticating with their own individual client certificates against our FreeRADIUS v2.2.9 servers. 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. This is allowed as we do not enable the "check_cert_cn" option, since this would cause other issues not only with this vendor, but with Microsoft/Apple as well as we've seen those OS sometime specify the MAC address of the client as the "Username" when authenticating with client certificates. 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. 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. 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: Access-Request = "Packet-Type=\"%{Packet-Type}\" ...... ,Timestamp = %l,%{User-Name},%{Framed-IP-Address},TLS-Client-Cert-Common-Name = \"%{TLS-Client-Cert-Common-Name}\",TLS-Client-Serial=\"%{TLS-Client-Cert-Serial}\",TLS-Client-Cert-Issuer = \"%{TLS-Client-Cert-Issuer}\"," 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). 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. Our modified query is below. Has anyone found a solution to log certificate information in the radius accounting table for users who authenticate via EAP-TLS? Thanks, Roberto accounting_start_query = " \ INSERT INTO ${acct_table1} \ (acctsessionid, acctuniqueid, username, \ realm, nasipaddress, nasportid, \ nasporttype, acctstarttime, acctstoptime, \ acctsessiontime, acctauthentic, connectinfo_start, \ connectinfo_stop, acctinputoctets, acctoutputoctets, \ calledstationid, callingstationid, acctterminatecause, \ servicetype, framedprotocol, framedipaddress, \ acctstartdelay, acctstopdelay, xascendsessionsvrkey, \ TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) \ VALUES \ ('%{Acct-Session-Id}', '%{Acct-Unique-Session-Id}', \ '%{SQL-User-Name}', \ '%{Realm}', '%{NAS-IP-Address}', '%{NAS-Port}', \ '%{NAS-Port-Type}', '%S', NULL, \ '0', '%{Acct-Authentic}', '%{Connect-Info}', \ '', '0', '0', \ '%{Called-Station-Id}', '%{Calling-Station-Id}', '', \ '%{Service-Type}', '%{Framed-Protocol}', '%{Framed-IP-Address}', \ '%{%{Acct-Delay-Time}:-0}', '0', '%{X-Ascend-Session-Svr-Key}', \ '%{TLS-Client-Cert-Common-Name}', '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}')" PLEASE NOTE: Florida has a very broad public records law (F. S. 119). All e-mails to and from County Officials are kept as a public record. Your e-mail communications, including your e-mail address may be disclosed to the public and media at any time.
On 19/03/2021 02:43, Roberto.Franceschetti@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
On Mar 18, 2021, at 10:43 PM, Roberto.Franceschetti@ocfl.net wrote:
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.
As Matthew says, that's how the protocols work. It's not a security issue with FreeRADIUS. It's an issue with your local configuration. TBH, it's RADIUS. If it "just works", then great. Otherwise, it's your responsibility to understand what's going on, and to work around issues with broken clients, broken NASes, etc. This is simply the reality of RADIUS. FreeRADIUS gives you not only the information on exactly what's going on, it gives you the power to fix it. So the only question here is "how do you work around the issues you're seeing". You can send the Class attribute back in the Access-Accept. And the NAS *should* echo it back in Accounting-Request packets for the same session. You can create Class fairly easily in v3, and there are examples to do this. In 2.2.9, it's a little harder, but not impossible. Maybe: update reply { Class := "0x%{md5:%{NAS-Identifier}%{TLS-Client-Cert-Common-Name}%{TLS-Client-Cert-Serial}%{TLS-Client-Cert-Issuer}" } You'll have to try some things to see what works. The idea is to have Class be a 16-byte value, which is taken from an MD5 hash of a bunch of things specific to that particular session. This hash MUST be unique. i.e. if two users log in at the same time, with the same certificate, then they MUST get different values for the Class attribute. You'll have to (surprise) read the debug output to see wha's in the packets, and what makes those sessions unique. Things like NAS-Port, etc. Once you find out which attributes make the request unique, then put them into the input for the MD5 hash. And also log the Class attribute, along with any information about the session (TLS cert information, Framed-IP-Address, NAS-IP-Address, NAS-Port, NAS-Identifier, etc.) before sending the Access-Accept. Logging this information lets you cross-check the Class when the server receives an Accounting-Request packet which contains the Class.
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.
If you have the Class attribute in the Accounting-Request packets, you just look up that in a DB, find the TLS cert information, and revoke the cert. If you don't have Class, you can likely just look up NAS-IP, port, etc. And that *should* generally be enough. But not always. Which is why Class exists. And whatever you do, you have to log things when sending the Access-Accept.
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: Access-Request = "Packet-Type=\"%{Packet-Type}\" ...... ,Timestamp = %l,%{User-Name},%{Framed-IP-Address},TLS-Client-Cert-Common-Name = \"%{TLS-Client-Cert-Common-Name}\",TLS-Client-Serial=\"%{TLS-Client-Cert-Serial}\",TLS-Client-Cert-Issuer = \"%{TLS-Client-Cert-Issuer}\","
That's good, if the NAS sends Framed-IP-Address. Except the whole point of RADIUS is that it happens *before* the system has network access. So in general, the Access-Request will not contain a Framed-IP-Address. But if Framed-IP-Address exists in the Access-Request *and* Accounting-Request packets, then you can use it to associate the two packets, and then revoke the correct certificate.
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).
No. Absolutely not. This is NOT how RADIUS works. Read the debug output. See what's in the Accounting-Request packets. Note that there's no certificate information.
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. Our modified query is below.
Read the debug output to see what's in the Accounting-Request packets. It really is that easy. There is no magic here. If you want to know WHY something is in the radacct table, then read the debug output. Just... PLEASE read the debug output. Note that there's no certificate information in the Accounting-Request packet. So... any idea why the certificate information isn't being logged into radacct?
Has anyone found a solution to log certificate information in the radius accounting table for users who authenticate via EAP-TLS?
You don't. It's impossible. What you DO is log the certificate information during authentication, AND log some information which identifies the session. THEN when receiving an Accounting-Request packet, look up the session information in a database, in order to find the certificate information. You're running into the limitations of the RADIUS protocol. These are NOT limitations in FreeRADIUS. These are not security issues in FreeRADIUS. Every system using RADIUS has it's own set of bizarreness and breakages. NASes which ignore the standards, supplicants which do weird things, etc. Your responsibility is to figure out what's going on, and then to use FreeRADIUS and databases in order to glue together a solution. You simply cannot rely on the NAS to do anything intelligent. The NAS gives you packets containing "something". You have to work with that. You can't make the NAS do anything else (except usually echo back Class). So the ONLY solution here is to write FreeRADIUS policies which read/write a database, in order to get the results you want. Welcome to RADIUS. It's a horrific nightmare of insanity. But FreeRADIUS gives you back control, and lets you work around almost every issue you'll see. Alan DeKok.
participants (3)
-
Alan DeKok -
Matthew Newton -
Roberto.Franceschettiï¼ ocfl.net