Re: Logging EAP-TLS certificate details
I thank you both for letting me know that it's not possible to obtain certificate information when logging the accounting information. I had been looking for a way for the past week and would still be looking for one if it wasn't for your reply. However I believe my point of this being a big freeradius security issue is incorrectly overlooked. Consider a scenario where freeradius is configured to authenticate against an LDAP/Active Directory. * We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the UserName that was logged in as being "JohnS". We thus know exactly which LDAP account is compromised, are able to block the attack and quickly investigate how the account was compromised. The key there is that access was granted with a username/password credential. The username in this case unequivocally identifies the account used to login WiFi, and that "identity" information was logged by freeradius. Now consider a different scenario (ours...) were, in addition to LDAP/Active Directory, we also allow EAP-TLS authentication via certificates issues by our certificate authority (we have issued over 40,000 certificates). * We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the UserName that was logged in as being "HaHaHaTryToCatchMeIfYouCan". We discover that the account "HaHaHaTryToCatchMeIfYouCan" does not exist in our LDAP/Active Directory. We then think the user probably authenticated with EAP-TLS and a certificate, but we're guessing since neither the radacct nor the radpostauth tables provide any clues as to the authentication used. * We check the "CallingStationID" in radacct to see if the MAC address of the hacker appears elsewhere, but it's a fake MAC. We are thus in a nightmare scenario where the hacker was able to obtain the private key for one of our 40,000 certificates to authenticate with our WiFi, but we have absolutely no idea which of these 40K certificates was compromised. We will need to revoke them all and that would be a disaster. Saying "this is how radius works" does not apply here. There's nothing wrong with RADIUS. It's authenticating correctly. EAP-TLS allows the user to specify a random username as it's not taking part of the authentication process. There's nothing wrong with that either. WHY? Because they are authenticating with a certificate that we issued, and given any specific certificate's serial number, we know who it was issued to. If there's a problem with the specific certificate being compromised, we revoke it. Freeradius checks the CRL so it will not allow access to revoked certificates. BUT WAIT. Freeradius is logging usernames for users who authenticating with a password, BUT it's NOT logging absolutely anything at for the certificate used by users who authenticate with a certificate. NOTHING. The issue is thus that while freeradius is be default logging the critical "Username" when regular authentication is occurring, freeradius is completely oblivious when it comes to logging the equivalent of the username when dealing with EAP-TLS. Any properly written application will have adequate auditing for who is logging into it. Freeradius is instead allowing users to login via EAP-TLS with absolutely no auditing whats-over. Auditing means auditing the identity used to login. Auditing an EAP-TLS username that is not actually being used for login purposes is useless - Freeradius MUST log whatever method is used to authenticate a user, and with EAP-TLS that means logging the TLS-Client-Certificate information. As you said there's nothing from with RADIUS protocol. But there everything wrong with the default installation of freeradius when it comes to auditing EAP-TLS authentications. This is a huge issue security hole as the logging of EAP-TLS certificate information that should be included in the default freeradius configuration, not left to admins to figure out that (1) they actually have an auditing problem of an application that's not logging who's authenticating, and (2) for them to figure out how to log it. We were able to implement what was missing after much pain and Googling. For anyone who thinks this is an actual concern, this is how we addressed it. 1. Our NAS logs the MAC address of our wireless clients on authentication requests. So we modified the radpostauth table to include the "CallingStationID" (which has the MAC address of the client) and the client cert information. This allows us to had an audit trail of usernames, MAC and Client Cert for every Access-Request: ALTER TABLE `radius`.`radpostauth` ADD COLUMN `CallingStationId ` VARCHAR(64) AFTER `nasipaddress`, ADD COLUMN `TLS_Client_Cert_Common_Name` VARCHAR(256) AFTER `CallingStationId`, ADD COLUMN `TLS_Client_Cert_Serial` VARCHAR(128) DEFAULT NULL AFTER `TLS_Client_Cert_Common_Name`, ADD COLUMN `TLS_Client_Cert_Issuer` VARCHAR(50) DEFAULT NULL AFTER `TLS_Client_Cert_Serial`; 2. Modify the radacct table to add the client cert information in it so we can populate it afterwards: ALTER TABLE `radius`.`radacct` ADD COLUMN `TLS_Client_Cert_Common_Name` VARCHAR(256) AFTER `xascendsessionsvrkey`, ADD COLUMN `TLS_Client_Cert_Serial` VARCHAR(128) DEFAULT NULL AFTER `TLS_Client_Cert_Common_Name`, ADD COLUMN `TLS_Client_Cert_Issuer` VARCHAR(50) DEFAULT NULL AFTER `TLS_Client_Cert_Serial`; 3. Change the linelog module to log the certificate information on the Access-Request so it would be available in syslog as a backup: 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}\"," 4. Change the postauth_query in the dialup.conf module to log the CallingStationid and the Client Cert data in the database on the Access-Request: postauth_query = "INSERT INTO ${postauth_table} \ (username, message, nasipaddress, reply, authdate, CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) \ VALUES ( \ '%{User-Name}', \ '%{Module-Failure-Message}', \ '%{NAS-IP-Address}', \ '%{reply:Packet-Type}', '%S', '%{Calling-Station-Id}', \ '%{TLS-Client-Cert-Common-Name}', '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}')" 5. Create and call every minute or so the following stored procedure which will update the certificate details for the records in the radacct table by matching logins via their MAC address (CallingStationId) in the radpostauth table (which does contain the certificate information previously retrieved/stored by the access-request). CREATE PROCEDURE `radacct_add_cert_info`() UPDATE radacct INNER JOIN radpostauth ON radacct.CallingStationId = radpostauth.CallingStationId SET radacct.TLS_Client_Cert_Common_Name=radpostauth.TLS_Client_Cert_Common_Name, radacct.TLS_Client_Cert_Serial=radpostauth.TLS_Client_Cert_Serial, radacct.TLS_Client_Cert_Issuer=radpostauth.TLS_Client_Cert_Issuer WHERE `authdate` > DATE_SUB(NOW(), INTERVAL '10' MINUTE) AND `AcctStartTime` > DATE_SUB(NOW(), INTERVAL '10' MINUTE) AND (radpostauth.TLS_Client_Cert_Common_Name<>'' OR radpostauth.TLS_Client_Cert_Serial<>'' OR radpostauth.TLS_Client_Cert_Issuer<>'');; The nightmare scenario above where EAP-TLS clients would be untraceable now becomes the following: * We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the certificate's serial number and common name in the radacct table for that record * We revoke the certificate, force a re-download of the CRL in the cron job, stop the attack, and can now focus on investigating how the user the certificate was issued to mishandled it. Roberto From: Alan DeKok Subject: Re: Logging EAP-TLS certificate details Date: March 19, 2021 at 8:04:04 AM EDT To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> On Mar 18, 2021, at 10:43 PM, Roberto.Franceschetti@ocfl.net<mailto: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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html 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 Mar 22, 2021, at 2:46 PM, <Roberto.Franceschetti@ocfl.net> <Roberto.Franceschetti@ocfl.net> wrote:
I thank you both for letting me know that it's not possible to obtain certificate information when logging the accounting information. I had been looking for a way for the past week and would still be looking for one if it wasn't for your reply.
That's good to hear.
However I believe my point of this being a big freeradius security issue is incorrectly overlooked.
Please be aware that FreeRADIUS is *strongly* limited by the RADIUS protocol. We just can't do what we'd like to do, as you saw with trying to get TLS information into the Accounting process.
Consider a scenario where freeradius is configured to authenticate against an LDAP/Active Directory.
* We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the UserName that was logged in as being "JohnS". We thus know exactly which LDAP account is compromised, are able to block the attack and quickly investigate how the account was compromised.
The key there is that access was granted with a username/password credential. The username in this case unequivocally identifies the account used to login WiFi, and that "identity" information was logged by freeradius.
Mostly. There are additional caveats, of course. One is that the credential logged in radacct is the one sent by the NAS. It is *usually* the same as the one in the Access-Request, but it doesn't *have* to be. FreeRADIUS just logs whatever the NAS sends it. The NAS can (and will) lie about what it's doing. Saying this is a security issue in FreeRADIUS is to severely misunderstand the problem.
Now consider a different scenario (ours...) were, in addition to LDAP/Active Directory, we also allow EAP-TLS authentication via certificates issues by our certificate authority (we have issued over 40,000 certificates).
* We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the UserName that was logged in as being "HaHaHaTryToCatchMeIfYouCan".
This User-Name is taken from the Access-Request packet. Which in turn is derived from the User-Name in the EAP packet. Which is under the control of the malicious user.
We discover that the account "HaHaHaTryToCatchMeIfYouCan" does not exist in our LDAP/Active Directory.
So... why did you let the user in? A good chunk of this problem is that you're not validating the user names. You've previously said:
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 a problem. Most people don't do this. Most people put a real name into the certificate. For devices, they put the device MAC address. So this comes down to: "We provisioned entirely similar user credentials to 40K devices, and now we don't know which device is which". To which the only possible answer is "well, don't do that!"
We then think the user probably authenticated with EAP-TLS and a certificate, but we're guessing since neither the radacct nor the radpostauth tables provide any clues as to the authentication used.
This is why the configuration files are editable. So you can edit them.
* We check the "CallingStationID" in radacct to see if the MAC address of the hacker appears elsewhere, but it's a fake MAC.
But the same MAC will be sent in both the Access-Request and Accounting-Request packets. Or, you can check the Framed-IP-Address as you said before. Or is this no longer possible? What changed? And why is it not possible to look at the NAS IP address / port, etc. as I suggested before? Why isn't that information available? If it isn't, I would hope that you would reply "No, it isn't available" instead of ignoring my comments and coming up with yet another scenario for why this doesn't work.
We are thus in a nightmare scenario where the hacker was able to obtain the private key for one of our 40,000 certificates to authenticate with our WiFi, but we have absolutely no idea which of these 40K certificates was compromised. We will need to revoke them all and that would be a disaster.
Sure. So... configure your certificates to contain useful information, like names and/or MAC addresses. Use the information in the packets to cross-correlate Access-Request and Accounting-Request packets. This is all what people do.
Saying "this is how radius works" does not apply here. There's nothing wrong with RADIUS. It's authenticating correctly. EAP-TLS allows the user to specify a random username as it's not taking part of the authentication process. There's nothing wrong with that either. WHY? Because they are authenticating with a certificate that we issued, and given any specific certificate's serial number, we know who it was issued to. If there's a problem with the specific certificate being compromised, we revoke it. Freeradius checks the CRL so it will not allow access to revoked certificates.
BUT WAIT. Freeradius is logging usernames for users who authenticating with a password, BUT it's NOT logging absolutely anything at for the certificate used by users who authenticate with a certificate. NOTHING.
If only the configuration files were editable, and you could log the certificate serial number along with the fake User-Name. See? It's easy.
The issue is thus that while freeradius is be default logging the critical "Username" when regular authentication is occurring, freeradius is completely oblivious when it comes to logging the equivalent of the username when dealing with EAP-TLS. Any properly written application will have adequate auditing for who is logging into it. Freeradius is instead allowing users to login via EAP-TLS with absolutely no auditing whats-over.
Nonsense. You've configured 40K certificates with "user" as the name. Then, you're saying that FreeRADIUS is broken because it doesn't anticipate this situation, and log *extra* information that *you* need, and *only* you need for your particular deployment. Please don't blame us for a broken system.
Auditing means auditing the identity used to login. Auditing an EAP-TLS username that is not actually being used for login purposes is useless - Freeradius MUST log whatever method is used to authenticate a user, and with EAP-TLS that means logging the TLS-Client-Certificate information.
If only the configuration files were editable...
As you said there's nothing from with RADIUS protocol. But there everything wrong with the default installation of freeradius when it comes to auditing EAP-TLS authentications.
Nonsense. NORMAL installations doing NORMAL things work fine. Your situation where you're doing very non-normal things doesn't work. But FreeRADIUS gives you the power to fix it. So... fix it.
This is a huge issue security hole as the logging of EAP-TLS certificate information that should be included in the default freeradius configuration, not left to admins to figure out that (1) they actually have an auditing problem of an application that's not logging who's authenticating, and (2) for them to figure out how to log it.
Normal configurations work. If you use unique user names for each certificate, then the default configuration works. If you put "user" into all of the certs, then well... Yes, if you do unusual things, then you have to understand how the server works, and then configure it log extra information.
We were able to implement what was missing after much pain and Googling.
Or perhaps asking on this list? You got an answer in much less than a day. An answer which was specific, clear, and helpful.
For anyone who thinks this is an actual concern,
Making snide insults to the developers is quite rude. Don't do that. I understand that YOUR system is insecure and broken. Because YOU did unusual things, and the server magically doesn't know how to fix that. The solution is NOT to complain that the server is broken. The solution is to ask for help, and to listen to the answers. The default configuration of the server works in as many situations as possible. However, it does NOT automatically do everything that everyone wants, everywhere, always. That's impossible.
this is how we addressed it.
1. Our NAS logs the MAC address of our wireless clients on authentication requests. So we modified the radpostauth table to include the "CallingStationID" (which has the MAC address of the client) and the client cert information. This allows us to had an audit trail of usernames, MAC and Client Cert for every Access-Request:
ALTER TABLE `radius`.`radpostauth` ADD COLUMN `CallingStationId ` VARCHAR(64) AFTER `nasipaddress`, ADD COLUMN `TLS_Client_Cert_Common_Name` VARCHAR(256) AFTER `CallingStationId`,
If the TLS-Client-Cert-Common name is always "user", then you can also check for bad user-names: post-auth { ... if (TLS-Client-Cert-Common-Name && (TLS-Client-Cert-Common-Name != User-Name)) { reject } ... } 2 lines of code will prevent users from lying about their User-Name. This doesn't solve the problem of having 40K certs with the same identity, but whatever.
4. Change the postauth_query in the dialup.conf module to log the CallingStationid and the Client Cert data in the database on the Access-Request: postauth_query = "INSERT INTO ${postauth_table} \ (username, message, nasipaddress, reply, authdate, CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) \ VALUES ( \ '%{User-Name}', \ '%{Module-Failure-Message}', \ '%{NAS-IP-Address}', \ '%{reply:Packet-Type}', '%S', '%{Calling-Station-Id}', \ '%{TLS-Client-Cert-Common-Name}', '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}')"
5. Create and call every minute or so the following stored procedure which will update the certificate details for the records in the radacct table by matching logins via their MAC address (CallingStationId) in the radpostauth table (which does contain the certificate information previously retrieved/stored by the access-request).
That's very heavy-weight. Or, in 3.0.18 and later we have a new policy "sql_session_start". This policy is run in the post-auth section, and creates an entry in the radacct table: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/policy.d/a... it can then log TLS information there, too.
The nightmare scenario above where EAP-TLS clients would be untraceable
Again, because *your* deployment is broken. Having 40K certificates with identity "user" is just terrible security practice.
now becomes the following:
* We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the certificate's serial number and common name in the radacct table for that record * We revoke the certificate, force a re-download of the CRL in the cron job, stop the attack, and can now focus on investigating how the user the certificate was issued to mishandled it.
Or: * create certificates with unique contents (device name, MAC address, etc.) * verify that the User-Name matches TLS-Client-Cert-Common-Name * use the default config to log default values At that point, it is *trivial* to figure out which certificate has been compromised. There's no need to go edit the default configuration files. And there's no need to complain that the default configuration is "insecure", because you have 40K users, all with the same name. Yes we didn't anticipate that someone would do that. Largely because such practices are insecure. So... don't blame us for failing to anticipate *and* work around site-local practices which create security issues. Alan DeKok.
Let me clarify - we issue certificate to actual people and applications. Every certificate is accounted for, and the Common Name will either have the persons's name or the serial/MAC address of the IoT it was issued to. That is not the issue. We *know* who the certificates are issued to, and if we have the Cert Serial number or the CN we can immediately identify them. For legitimate applications and users, this will work fine, as a "real" user will enter their username in the EAP-TLS request, or the operating system will provide the MAC address. Those are non-issues. We know everything there is to know. The problem is with an attacker, or in my original post with the incompetent vendor who is specifying "User" as the EAP-TLS username for each one of their hundreds of devices. If I (the attacker) can get my hands on a certificate with the private key, when logging in with EAP-TLS I can provide whatever username I want. Freeradius will only be logging/auditing that fake username, and whatever fame MAC address I assign to the virtual machine I'm using to perform the attack. I will be completely anonymous because freeradius is not logging the Cert Serial or the Cert Common Name. If freeradius logged the Serial or the CN we would not be having this conversation as we'd have all the info necessary to track down the compromised certificate and the person/device it was originally issued to.
FreeRADIUS just logs whatever the NAS sends it. The NAS can (and will) lie about what it's doing. Saying this is a security issue in FreeRADIUS is to severely misunderstand the problem. No that's incorrect in EAP-TLS - the NAS will send the *correct* information about the certificate. That cannot be faked. freeradius is configured to accept only certs issued by our Certification Authority.
This User-Name is taken from the Access-Request packet. Which in turn is derived from the User-Name in the EAP packet. Which is under the control of the malicious user.
Exactly - the User-Name is useless when it comes to EAP-TLS. That's not what should be audited. It's the certificate information (which IS available on the access-request) that needs to be logged.
So... why did you let the user in?
A good chunk of this problem is that you're not validating the user names. You've previously said: How do you expect us to validate the username? We can't force all applications to follow one single standard. Windows and Mac sometimes connect by putting the MAC address. Some NIC cards take the current logged-in-user's username. In our case we have a vendor who has hardware with a hard-coded "User" as a username. Other ioT have their serial number in the CN. You cannot enforce a standard for a "Username" EAP-TLS field that is free-form with no RFC that requires it to be something specific (I've been looking for one to try telling that one vendor to fix their stuff and follow the standards... but there isn't one)
At the end, who cares about the EAP-TLS "User-name" free-form field when the actual identity used to login is the certificate, but freeradius is not logging anything about it? This is a 100% a freeradius issue, not a RADIUS protocol issue.
This is a problem. Most people don't do this. Most people put a real name into the certificate. For devices, they put the device MAC address. So this comes down to:
"We provisioned entirely similar user credentials to 40K devices, and now we don't know which device is which".
As I said, we're doing it correctly already. All certs either have the persons's name or the device's serial/MAC address in the CN. Each cert it unique.
And why is it not possible to look at the NAS IP address / port, etc. as I suggested before? Why isn't that information available? If it isn't, I would hope that you would reply "No, it isn't available" instead of ignoring my comments and coming up with yet another scenario for why this doesn't work. It's useless to look at the NAS IP / port information, as that will do nothing as far as letting us know what certificate was used to login. Why...? Because the TLS Client Cert details are only received by freeradius, which is not logging it.
Sure. So... configure your certificates to contain useful information, like names and/or MAC addresses.
Use the information in the packets to cross-correlate Access-Request and Accounting-Request packets.
This is all what people do. We do too. Our certs DO have that info. But if freeradius doesn't log which certificate is used to login, how can we retrieve said information if freeradius doesn't tell us which certificate was used?
If only the configuration files were editable, and you could log the certificate serial number along with the fake User-Name.
See? It's easy. ...Actually in multiple posts you have said not to change the "User-Name" field. We did however change the config files to retrieve the info required, but we also had to change the schema of the database to log what freeradius wasn't logging. We LOVE freeradius for the flexibility it provides. We canned the super-expensive Cisco Radius appliances we were using several years ago in favor of freeradius not because of the cost, but because of the immensely superior capabilities freeradius has. All I'm trying to point out is that when it comes to EAP-TLS, it's imperative for freeradius to log the client certificate information. I'd wager there is a large number of admins using freeradius for EAP-TLS authentication that have no idea that the current implementation they are using will be useless to track down a compromised certificate should the need ever arise. We ourselves were oblivious to this until we had to deal with the vendor that was deploying their IoTs with the generic "User" username, and realized what a gaping security hole we had.
You've configured 40K certificates with "user" as the name. Then, you're saying that FreeRADIUS is broken because it doesn't anticipate this situation, and log *extra* information that *you* need, and *only* you need for your particular deployment.
Please don't blame us for a broken system. No, once more. We did not configure 40K certs with "user" as the name. That is not the problem. The problem is that if you steal one of those 40K certs, you will be able to come onsite and login via WiFi to our network by specifying a fake username, and it will be *impossible* for me to find out which certificate you stole since freeradius is not logging that information. If freeradius logged the serial or the CN, I *would* immediately know which of the 40K certs was compromised as each one has a unique serial/CN. Please do not deviate blame. Our system is fine. The issue is using a product (freeradius) that is not logging the identity (meaning the certificate) that is used to login when using EAP-TLS.
Normal configurations work. If you use unique user names for each certificate, then the default configuration works. If you put "user" into all of the certs, then well...
We don't. The attacker is the one that would specify "User" in the "User-Name". I don't know how to make this clearer...
If the TLS-Client-Cert-Common name is always "user", then you can also check for bad user-names: It's not. As I've repeatedly said in my post, the CN will either have the name of the person the original certificate was issued to, or the serial/MAC of the IoT device.
if (TLS-Client-Cert-Common-Name && (TLS-Client-Cert-Common-Name != User-Name)) { reject } ... }
2 lines of code will prevent users from lying about their User-Name.
Not doable. As I explained above you/we cannot require multiple vendors/applications to use a specific User-Name. We have different vendors specifying different data in different formats. There is no standard - there's no RFC for that. It's a simple label. Vendor A will use their serial. Vendor B their MAC address with ":" separators. Vendor C will use the MAC with "-". Vendor D will require the CN to be the person's name by specifying "CN=" in front of it. Vendor E will require the name without the "CN=" in front. And so not. This is not an issue with legitimate vendors and applications. That User-Name field is not to be used as an identifier in the EAP-TLS process period - it's a label. The authenticator is the certificate - that is what matters and needs to be tracked/logged.
Or, in 3.0.18 and later we have a new policy "sql_session_start". This policy is run in the post-auth section, and creates an entry in the radacct table: We're using a very complex config in our v2 to handle a dozen different types of authentications/applications/configurations. I got a headache when I first looked at the migration guide. I'm hoping to retire before I'm forced to upgrade.
And there's no need to complain that the default configuration is "insecure", because you have 40K users, all with the same name. We don't. All 40K certs are unique and immediately identifiable. We're worried about the single certificate that can be stolen, with the hacker being able to specify a useless random user-name, and with freeradius not logging the serial/issuer of the certificate, without which we cannot identify the compromised certificate.
So... don't blame us for failing to anticipate *and* work around site-local practices which create security issues. This is not a "local" practice. Anyone who is using the default freeradius configuration to authenticate EAP-TLS users has a gaping security hole. Any attacker who compromises a client certificate will be able to login without the security staff being able to identify which certificate was compromised, and that is going to be a problem. All because freeradius is not logging the cert's serial number and issuer...
For anyone who thinks this is an actual concern,
Making snide insults to the developers is quite rude. Don't do that. I'm sorry - it wasn't intended that way. My two co-workers were in a "oh wow" shock moment when I showed them how I was able to authenticate with a certificate and a fake name, rendering them incapable of finding our which cert I had used to login. While I am at loss as to why you do not see the fact of the certificates not being logged as being a big security issue, I've posted the previous information for anyone who like me may have been searching for TLS info, looking for a solution to retrieve the certificate info, and spent the time to document it properly to try (1) to better clarify the root issue and (2) to assist anyone who like me isn't too versed in the ability to customize freeradius.
I again apologize for the tone - it's just frustrating being told that our environment is not configured correctly by saying we issued 40K certificates all being the same, when that is incorrect. All our certs are unique, and can uniquely identify the person/device they were issued to either with their serial number or CN. The problem is another - an attacker who is able to steal one and use it without us being able to tell which of the 40K cert was stolen as freeradius does not log that critical piece of information (cert serial/issuer/CN). We have a solution. I'm merely pointing out to the radius community that whoever is using EAP-TLS is likely at risk as they are unable to track down the specifics of certificates used for authentication in case an attacker steals one of them, and they haven't modified their system to track them. Roberto
On Mar 22, 2021, at 3:25 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 22, 2021, at 2:46 PM, <Roberto.Franceschetti@ocfl.net> <Roberto.Franceschetti@ocfl.net> wrote:
I thank you both for letting me know that it's not possible to obtain certificate information when logging the accounting information. I had been looking for a way for the past week and would still be looking for one if it wasn't for your reply.
That's good to hear.
However I believe my point of this being a big freeradius security issue is incorrectly overlooked.
Please be aware that FreeRADIUS is *strongly* limited by the RADIUS protocol. We just can't do what we'd like to do, as you saw with trying to get TLS information into the Accounting process.
Consider a scenario where freeradius is configured to authenticate against an LDAP/Active Directory.
* We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the UserName that was logged in as being "JohnS". We thus know exactly which LDAP account is compromised, are able to block the attack and quickly investigate how the account was compromised.
The key there is that access was granted with a username/password credential. The username in this case unequivocally identifies the account used to login WiFi, and that "identity" information was logged by freeradius.
Mostly. There are additional caveats, of course. One is that the credential logged in radacct is the one sent by the NAS. It is *usually* the same as the one in the Access-Request, but it doesn't *have* to be.
FreeRADIUS just logs whatever the NAS sends it. The NAS can (and will) lie about what it's doing. Saying this is a security issue in FreeRADIUS is to severely misunderstand the problem.
Now consider a different scenario (ours...) were, in addition to LDAP/Active Directory, we also allow EAP-TLS authentication via certificates issues by our certificate authority (we have issued over 40,000 certificates).
* We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the UserName that was logged in as being "HaHaHaTryToCatchMeIfYouCan".
This User-Name is taken from the Access-Request packet. Which in turn is derived from the User-Name in the EAP packet. Which is under the control of the malicious user.
We discover that the account "HaHaHaTryToCatchMeIfYouCan" does not exist in our LDAP/Active Directory.
So... why did you let the user in?
A good chunk of this problem is that you're not validating the user names. You've previously said:
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 a problem. Most people don't do this. Most people put a real name into the certificate. For devices, they put the device MAC address. So this comes down to:
"We provisioned entirely similar user credentials to 40K devices, and now we don't know which device is which".
To which the only possible answer is "well, don't do that!"
We then think the user probably authenticated with EAP-TLS and a certificate, but we're guessing since neither the radacct nor the radpostauth tables provide any clues as to the authentication used.
This is why the configuration files are editable. So you can edit them.
* We check the "CallingStationID" in radacct to see if the MAC address of the hacker appears elsewhere, but it's a fake MAC.
But the same MAC will be sent in both the Access-Request and Accounting-Request packets.
Or, you can check the Framed-IP-Address as you said before. Or is this no longer possible? What changed?
And why is it not possible to look at the NAS IP address / port, etc. as I suggested before? Why isn't that information available? If it isn't, I would hope that you would reply "No, it isn't available" instead of ignoring my comments and coming up with yet another scenario for why this doesn't work.
We are thus in a nightmare scenario where the hacker was able to obtain the private key for one of our 40,000 certificates to authenticate with our WiFi, but we have absolutely no idea which of these 40K certificates was compromised. We will need to revoke them all and that would be a disaster.
Sure. So... configure your certificates to contain useful information, like names and/or MAC addresses.
Use the information in the packets to cross-correlate Access-Request and Accounting-Request packets.
This is all what people do.
Saying "this is how radius works" does not apply here. There's nothing wrong with RADIUS. It's authenticating correctly. EAP-TLS allows the user to specify a random username as it's not taking part of the authentication process. There's nothing wrong with that either. WHY? Because they are authenticating with a certificate that we issued, and given any specific certificate's serial number, we know who it was issued to. If there's a problem with the specific certificate being compromised, we revoke it. Freeradius checks the CRL so it will not allow access to revoked certificates.
BUT WAIT. Freeradius is logging usernames for users who authenticating with a password, BUT it's NOT logging absolutely anything at for the certificate used by users who authenticate with a certificate. NOTHING.
If only the configuration files were editable, and you could log the certificate serial number along with the fake User-Name.
See? It's easy.
The issue is thus that while freeradius is be default logging the critical "Username" when regular authentication is occurring, freeradius is completely oblivious when it comes to logging the equivalent of the username when dealing with EAP-TLS. Any properly written application will have adequate auditing for who is logging into it. Freeradius is instead allowing users to login via EAP-TLS with absolutely no auditing whats-over.
Nonsense.
You've configured 40K certificates with "user" as the name. Then, you're saying that FreeRADIUS is broken because it doesn't anticipate this situation, and log *extra* information that *you* need, and *only* you need for your particular deployment.
Please don't blame us for a broken system.
Auditing means auditing the identity used to login. Auditing an EAP-TLS username that is not actually being used for login purposes is useless - Freeradius MUST log whatever method is used to authenticate a user, and with EAP-TLS that means logging the TLS-Client-Certificate information.
If only the configuration files were editable...
As you said there's nothing from with RADIUS protocol. But there everything wrong with the default installation of freeradius when it comes to auditing EAP-TLS authentications.
Nonsense.
NORMAL installations doing NORMAL things work fine. Your situation where you're doing very non-normal things doesn't work. But FreeRADIUS gives you the power to fix it.
So... fix it.
This is a huge issue security hole as the logging of EAP-TLS certificate information that should be included in the default freeradius configuration, not left to admins to figure out that (1) they actually have an auditing problem of an application that's not logging who's authenticating, and (2) for them to figure out how to log it.
Normal configurations work. If you use unique user names for each certificate, then the default configuration works. If you put "user" into all of the certs, then well...
Yes, if you do unusual things, then you have to understand how the server works, and then configure it log extra information.
We were able to implement what was missing after much pain and Googling.
Or perhaps asking on this list? You got an answer in much less than a day. An answer which was specific, clear, and helpful.
For anyone who thinks this is an actual concern,
Making snide insults to the developers is quite rude. Don't do that.
I understand that YOUR system is insecure and broken. Because YOU did unusual things, and the server magically doesn't know how to fix that.
The solution is NOT to complain that the server is broken. The solution is to ask for help, and to listen to the answers.
The default configuration of the server works in as many situations as possible. However, it does NOT automatically do everything that everyone wants, everywhere, always. That's impossible.
this is how we addressed it.
1. Our NAS logs the MAC address of our wireless clients on authentication requests. So we modified the radpostauth table to include the "CallingStationID" (which has the MAC address of the client) and the client cert information. This allows us to had an audit trail of usernames, MAC and Client Cert for every Access-Request:
ALTER TABLE `radius`.`radpostauth` ADD COLUMN `CallingStationId ` VARCHAR(64) AFTER `nasipaddress`, ADD COLUMN `TLS_Client_Cert_Common_Name` VARCHAR(256) AFTER `CallingStationId`,
If the TLS-Client-Cert-Common name is always "user", then you can also check for bad user-names:
post-auth { ... if (TLS-Client-Cert-Common-Name && (TLS-Client-Cert-Common-Name != User-Name)) { reject } ... }
2 lines of code will prevent users from lying about their User-Name.
This doesn't solve the problem of having 40K certs with the same identity, but whatever.
4. Change the postauth_query in the dialup.conf module to log the CallingStationid and the Client Cert data in the database on the Access-Request: postauth_query = "INSERT INTO ${postauth_table} \ (username, message, nasipaddress, reply, authdate, CallingStationid, TLS_Client_Cert_Common_Name, TLS_Client_Cert_Serial, TLS_Client_Cert_Issuer) \ VALUES ( \ '%{User-Name}', \ '%{Module-Failure-Message}', \ '%{NAS-IP-Address}', \ '%{reply:Packet-Type}', '%S', '%{Calling-Station-Id}', \ '%{TLS-Client-Cert-Common-Name}', '%{TLS-Client-Cert-Serial}', '%{TLS-Client-Cert-Issuer}')"
5. Create and call every minute or so the following stored procedure which will update the certificate details for the records in the radacct table by matching logins via their MAC address (CallingStationId) in the radpostauth table (which does contain the certificate information previously retrieved/stored by the access-request).
That's very heavy-weight.
Or, in 3.0.18 and later we have a new policy "sql_session_start". This policy is run in the post-auth section, and creates an entry in the radacct table:
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/policy.d/a...
it can then log TLS information there, too.
The nightmare scenario above where EAP-TLS clients would be untraceable
Again, because *your* deployment is broken. Having 40K certificates with identity "user" is just terrible security practice.
now becomes the following:
* We detect IP 10.255.1.100 on our internal network currently attacking one of our Exchange servers. * We see 10.255.1.100 as belonging to our WiFi DHCP pool. * We thus go to the RADIUS radacct table to see the FramedIP address issued at the time of the attack. * We see the certificate's serial number and common name in the radacct table for that record * We revoke the certificate, force a re-download of the CRL in the cron job, stop the attack, and can now focus on investigating how the user the certificate was issued to mishandled it.
Or:
* create certificates with unique contents (device name, MAC address, etc.) * verify that the User-Name matches TLS-Client-Cert-Common-Name * use the default config to log default values
At that point, it is *trivial* to figure out which certificate has been compromised. There's no need to go edit the default configuration files. And there's no need to complain that the default configuration is "insecure", because you have 40K users, all with the same name.
Yes we didn't anticipate that someone would do that. Largely because such practices are insecure.
So... don't blame us for failing to anticipate *and* work around site-local practices which create security issues.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 Mar 22, 2021, at 5:04 PM, <Roberto.Franceschetti@ocfl.net> <Roberto.Franceschetti@ocfl.net> wrote:
Let me clarify - we issue certificate to actual people and applications. Every certificate is accounted for, and the Common Name will either have the persons's name or the serial/MAC address of the IoT it was issued to.
There's a lot of details which have come out over a series of messages. Incomplete problem descriptions tend to cause confusion. The summary here is: * malicious users are logging in with fake names, because those fake names are never checked against the cert, or against a DB. Fixing this will address a lot of issues * the default configuration doesn't log TLS client cert serial, because (a) most people don't use EAP-TLS, and (b) most people who do use it also check that the user names are valid * the User-Name field is taken from the EAP-Identity, which is in turn taken from the subjectAltName or Common name fields of the certificate. * These fields are the same 99% of the time. The server checks that User-Name matches EAP-Identity. It is up to you to configure the server to check that User-Name matches the correct certificate field. See the first point above. * We can't add in these checks by default, because there are variations in which fields are used * Your site has (essentially) random vendors issuing random certs that you don't control. This practice is insecure, and is contributing towards the problem you're seeing. * Most people control their own client certificates. This means that they can issue certs with fields that make sense, in a format that makes sense. * Because your site is not following this common practice, you're seeing all kinds of issues. Issues which most other people don't see. * Access-Request packets contains NAS IP / port information. You can log that, along with other information such as certificate serial numbers. * Accounting-Request packets also contain NAS IP / port information. This is the same information as seen in the Access-Accept. * You can correlate the two sets of information, in order to see (a) which port the user is on, and (b) what TLS cert they have. This minor change to the default configuration will address all of the issues you're seeing. The security issue here is that your site is not validating that the User-Name matches the cert, and is not validating that the User-Name is known. While there are reasons for that, it's important to note that these reasons are local to your site. Perhaps we need better documentation to say "don't do that, it's a problem". Alan DeKok.
For the record,
* Your site has (essentially) random vendors issuing random certs that you don't control. This practice is insecure, and is contributing towards the problem you're seeing. This is once more incorrect. We are the ones issuing certificates to vendors and users via our Certificate Authority, not vice-versa. We are in full control of that process, and certificates are issued manually by us. What we (and nobody else) CANNOT control is the fact that these IoT devices with the certs can be physically stolen (thus exposing the certificate), or that an employee who was issued a certificate decides to perform unlawful acts and use that certificate for nefarious purposes. There is absolutely nothing wrong with our practices, please do no make baseless accusations.
* the User-Name field is taken from the EAP-Identity, which is in turn taken from the subjectAltName or Common name fields of the certificate. You are simply wrong here. It would be up to the application to provide the "User-Name" and that is completely unrelated to the certificate details. You yourself here just said it can be the SubjAltName or the CN... so even for you there's no standard. And as I've said, some applications provide the CN, some the MAC address, some random usernames.. Neither you nor I control what these applications provide. We didn't program them - they are commercial applications and/or a function of the OS.
* These fields are the same 99% of the time. The server checks that User-Name matches EAP-Identity. It is up to you to configure the server to check that User-Name matches the correct certificate field. See the first point above. Wrong. See above. In real life you can't perform matches on the EAP-TLS provided User-Name as there's NOTHING IN ANY RFC that says it must match the CN/SubjAltName. Just because you say it's best practices it doesn't mean that Microsoft/Apple/Netmotion or JoesGarage etc will listen to you. I keep repeating - WE are not specifying the User-Name - commercial products we use that authenticate via EAP-TLS are specifying the various flavors of "User-Name" EAP-TLS identities while authenticating using our *properly issued* certificates.
* Because your site is not following this common practice, you're seeing all kinds of issues. Issues which most other people don't see. I'm sorry, but WE are following best practices. What is not following best practice was freeradius not auditing/logging the identity (meaning the certificate details) that was used to authenticate via EAP-TLS. Imagine what would happen if Microsoft, instead of logging the username used to login, would instead log the "description" field in Active Directory for the account. Sure, you could scream all you want and say "but the users should have a real valid description in the description field". Do you actually think that would fly...? No. This is what is happening with Freeradius. Instead of logging the certificate used to login, it's logging the "User-Name" field which in the case of EAP-TLS is a completely random user-defined field - a "description".
You are trying to blame us for something which is instead a big whole in freeradius - the lack of auditing of the certificates used to authenticate via EAP-TLS in the default configuration of freeradius. If auditing was in place, we would not be having these arguments. The solution is simple - all it takes is for the developers to understand that it is an actual issue and fix it instead of baselessly blaming us admins for not following best practices. Luckily freeradius is the beauty that it is, and we were able to customize it to log what should be logged out-of-the-box. And at this point, I will repeat - "For anyone who thinks this is an actual concern, here's how we did it - see previous posts." Roberto
On Mar 22, 2021, at 6:40 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 22, 2021, at 5:04 PM, <Roberto.Franceschetti@ocfl.net> <Roberto.Franceschetti@ocfl.net> wrote:
Let me clarify - we issue certificate to actual people and applications. Every certificate is accounted for, and the Common Name will either have the persons's name or the serial/MAC address of the IoT it was issued to.
There's a lot of details which have come out over a series of messages. Incomplete problem descriptions tend to cause confusion.
The summary here is:
* the default configuration doesn't log TLS client cert serial, because (a) most people don't use EAP-TLS, and (b) most people who do use it also check that the user names are valid
* the User-Name field is taken from the EAP-Identity, which is in turn taken from the subjectAltName or Common name fields of the certificate.
* These fields are the same 99% of the time. The server checks that User-Name matches EAP-Identity. It is up to you to configure the server to check that User-Name matches the correct certificate field. See the first point above.
* We can't add in these checks by default, because there are variations in which fields are used
* Your site has (essentially) random vendors issuing random certs that you don't control. This practice is insecure, and is contributing towards the problem you're seeing.
* Most people control their own client certificates. This means that they can issue certs with fields that make sense, in a format that makes sense.
* Because your site is not following this common practice, you're seeing all kinds of issues. Issues which most other people don't see.
* Access-Request packets contains NAS IP / port information. You can log that, along with other information such as certificate serial numbers.
* Accounting-Request packets also contain NAS IP / port information. This is the same information as seen in the Access-Accept.
* You can correlate the two sets of information, in order to see (a) which port the user is on, and (b) what TLS cert they have.
This minor change to the default configuration will address all of the issues you're seeing.
The security issue here is that your site is not validating that the User-Name matches the cert, and is not validating that the User-Name is known. While there are reasons for that, it's important to note that these reasons are local to your site.
Perhaps we need better documentation to say "don't do that, it's a problem".
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 24/03/2021 02:43, Roberto.Franceschetti@ocfl.net wrote:
Luckily freeradius is the beauty that it is, and we were able to customize it to log what should be logged out-of-the-box.
So the summary is: - FreeRADIUS is very configurable and lets you do pretty much anything you want - FreeRADIUS ships with a default config which works in a lot of situations out of the box - Whoever is installing FreeRADIUS still has to configure it, and understand what they are doing - You installed it and didn't understand what you were doing, and had a wow revelation moment when you realised your configuration was wrong - You learnt something - You fixed your config so it worked - You're blaming the FreeRADIUS devs for not catering for your exact situation. That's hardly fair. FreeRADIUS will work in a huge number of situations. The default config works in a lot, but will always need to be configured. We do a lot of installs with ISPs and broadband setups. They often send critical Circuit ID information in all sorts of random attributes that needs logging and I have to configure FreeRADIUS to log it, often for regulatory auditing purposes. In the same way that I don't blame the default config for not working perfectly out of the box in every situation I use it in, I also don't blame the default config for not logging the exact information that I wanted it to log. Instead I look at the incoming requests, think "according to the requirements, what needs logging here?" and change the config so that it does what is needed, then test to make sure everything is working as it should. -- Matthew
On Mar 23, 2021, at 10:43 PM, <Roberto.Franceschetti@ocfl.net> <Roberto.Franceschetti@ocfl.net> wrote:
* Your site has (essentially) random vendors issuing random certs that you don't control. This practice is insecure, and is contributing towards the problem you're seeing. This is once more incorrect. We are the ones issuing certificates to vendors and users via our Certificate Authority, not vice-versa. We are in full control of that process, and certificates are issued manually by us.
Given the amount of confusion in the messages, that wasn't clear.
There is absolutely nothing wrong with our practices, please do no make baseless accusations.
Go read Matthews' reply. I'd also ask you to look in the mirror, and see hypocrisy. You've claimed that the default configuration of FreeRADIUS is insecure, which is stating outright that *our* practices are wrong. We pointed out that no, we can't anticipate everything. And that it's up to you to understand your system. And that you've created an insecure system. At which point you get offended. This comes across like "*I* can say that you guys are wrong. How DARE you tell me that my practices are wrong!". To be frank, I've been doing this for 20 years. I've written many of the standards in the space. I've implemented many of the standards. I've deployed EAP at many sites. I've done deep dives into TLS standards, implementations, and practices. I'm in the middle of writing a new RFC on EAP best practices, including TLS. I'm saying your practices are wrong, and you're saying I don't understand the problem space. Who is likely to be correct here? Think hard. RFC 3580 says that the User-Name MUST be taken from the EAP-Identity. RFC 5216 says that the EAP-Identity is taken from (some) fields of the certificate. Those are the facts. If you disagree with those facts, you have to explain why the words in the RFCs do not mean what they say. The RADIUS packets contain things like User-Name, NAS IP/port, MAC address, TLS cert fields, etc. These fields are not always to be trusted, as vendors can (and do) insane things with the protocols. That is an entirely different issue. It is YOUR responsibility as an administrator to catch broken equipment, and work around it. I've said that repeatedly, and you don't seem to take that seriously. It's easier to just blame FreeRADIUS (and us). If you control the certificates, then you can cross-correlate the fields. It's simply a matter of reading the debug output. MAC addresses in weird format (Calling-Station-Id)? Normalize them. User-Name is crap? Check that the MAC address in the certificate matches the MAC address in Calling-Station-Id. And log the MAC and User-Name, along with the NAS IP, port, etc. Unless things are completely insane, you have enough information to do this. I'll note that the default configuration logs User-Name *and* Calling-Station-Id, which means that you have the name *and* the MAC of the device. The default configuration also logs Called-Station-Id, along with NAS IP, port, etc. Which means that you know where the device is on the network. If the certificate is compromised, you have all the information you need. You can tell which certificate has been compromised, and can (a) revoke the cert, and (b) kick the user offline. Again, WE CANNOT CHECK TLS FIELDS IN THE DEFAULT CONFIGURATION. I've explained why in great detail. You've ignored this. Instead, you've referred to 'best practices" which you seem to have invented. You've made false analogies. You've claimed I'm wrong for stating how cert fields go to EAP-Identity and User-Name, despite me pointing to the RFCs which say this is how it works. You've gotten offended when we say your practices are wrong. But it's perfectly fine for you to say that our practices are wrong. And to imply that we don't care about security. We simply cannot update the default configuration to work everywhere, in all possible configurations, always, no matter what. This *is* what you're asking us to do. We've explained why that's true. We've explained what you should do in order to take responsibility for your local configuration. Instead of learning, you're getting offended that we're telling you you're wrong. And you're implying that we don't care about security. If you want to piss off the FreeRADIUS developers, you're doing a great job. If you want to learn how to make your system better (and come up with a simpler solution), you're failing miserably. For anyone who's reading this, don't implement Roberto's solution. It's heavyweight, complex, and unnecessary. Instead, issue certificates which contain as much information as possible about the device, mainly MAC addresses. Instead, check users who are authenticating, and ensure that only known users are authenticating. Reject users who aren't known, etc. Instead, if the NASes send you crap, figure out what extra information you DO need to log, and add that to the logs. And don't get upset that FreeRADIUS is missing a magic button which says "do what I want". Those buttons don't exist in the real world. Alan DeKok.
Alan, I've been doing this for 20+ years as well. You focus on developing software and creating RFCs, I focus on security and ensuring applications are secure and also develop software myself. I insist that unless you log the EAP-TLS certificate data, freeradius is lacking security as you CANNOT find out what certificate is compromised when using data logged and audited by freeradius in its default configuration. You need to log the client cert's serial number and issuer. If you don't, there is NO WAY to to find out what cert is compromised.
If you control the certificates, then you can cross-correlate the fields. It's simply a matter of reading the debug output. You think we run freeradius in debug mode and log the output...? It's irrelevant what shows in freeradius -X in a production environment. What matters in case someone hacked in is what's in the logs/database. They don't contain the debug output. The only thing the debug output is useful for is to use its data to see what's available and make use of it thru customizations. Which is exactly what we did. We customized freeradius using the info we saw in the debug output, and that required changing the database schema and the logging schema to capture cert information. I'm simply telling you that would you need to make those changes in the default freeradius configuration as well, because right now you're not logging the identity used to authenticate with EAP-TLS, and that's a big security issue.
I'll note that the default configuration logs User-Name *and* Calling-Station-Id, which means that you have the name *and* the MAC of the device. The default configuration also logs Called-Station-Id, along with NAS IP, port, etc. Which means that you know where the device is on the network. You are 100% incorrect here, again. Did actually realize that I can configure a Parallels/VMware guest with a completely bogus MAC address, and authenticate via WiFi and EAP-TLS with a stolen certificate by specifying a completely fake User-Name? Will you tell me how in the world I'm supposed to find the compromised certificate if BOTH the MAC and the User-Name are fake? I CANNOT. All I would have is a client IP which would tell me in our around which building the attacker is. Not what certificate they stole. And don't tell me about the RFCs you named as we deal with the real world, and in the real world there are multiple cases of large companies using EAP-TLS authentication where there is simply no standard for the User-Name. We cannot enforce any specific format or we'd have to stop using EAP-TLS altogether as nobody would be able to authenticate.
User-Name is crap? Check that the MAC address in the certificate matches the MAC address in Calling-Station-Id.
..and you come up with all sorts of "you should do this" like this one. Why in the world should we be limited to assigning one specific certificate to one single IoT? What if we want to assign the same certificate to the 5 fire trucks in Fire Station 1, another certificate to the 4 ambulances in Fire station 2, and so forth? We are actually assigning individual certificates for each vehicle, but what it we didn't want to as we were satisfied in knowing that each Fire station had its own certificate for their devices? There are too many scenarios, and again, NONE OF THIS IS AN ISSUE IF YOU LOG THE SERIAL NUMBER AND ISSUER of the cert used to authenticate. If you log that information, then you're logging the method used to authenticate. How can you even argue that it's not needed? Roberto
On Mar 24, 2021, at 8:30 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 23, 2021, at 10:43 PM, <Roberto.Franceschetti@ocfl.net> <Roberto.Franceschetti@ocfl.net> wrote:
* Your site has (essentially) random vendors issuing random certs that you don't control. This practice is insecure, and is contributing towards the problem you're seeing. This is once more incorrect. We are the ones issuing certificates to vendors and users via our Certificate Authority, not vice-versa. We are in full control of that process, and certificates are issued manually by us.
Given the amount of confusion in the messages, that wasn't clear.
There is absolutely nothing wrong with our practices, please do no make baseless accusations.
Go read Matthews' reply. I'd also ask you to look in the mirror, and see hypocrisy.
You've claimed that the default configuration of FreeRADIUS is insecure, which is stating outright that *our* practices are wrong. We pointed out that no, we can't anticipate everything. And that it's up to you to understand your system. And that you've created an insecure system.
At which point you get offended. This comes across like "*I* can say that you guys are wrong. How DARE you tell me that my practices are wrong!".
To be frank, I've been doing this for 20 years. I've written many of the standards in the space. I've implemented many of the standards. I've deployed EAP at many sites. I've done deep dives into TLS standards, implementations, and practices. I'm in the middle of writing a new RFC on EAP best practices, including TLS.
I'm saying your practices are wrong, and you're saying I don't understand the problem space. Who is likely to be correct here? Think hard.
RFC 3580 says that the User-Name MUST be taken from the EAP-Identity. RFC 5216 says that the EAP-Identity is taken from (some) fields of the certificate. Those are the facts. If you disagree with those facts, you have to explain why the words in the RFCs do not mean what they say.
The RADIUS packets contain things like User-Name, NAS IP/port, MAC address, TLS cert fields, etc. These fields are not always to be trusted, as vendors can (and do) insane things with the protocols. That is an entirely different issue.
It is YOUR responsibility as an administrator to catch broken equipment, and work around it. I've said that repeatedly, and you don't seem to take that seriously. It's easier to just blame FreeRADIUS (and us).
If you control the certificates, then you can cross-correlate the fields. It's simply a matter of reading the debug output.
MAC addresses in weird format (Calling-Station-Id)? Normalize them.
User-Name is crap? Check that the MAC address in the certificate matches the MAC address in Calling-Station-Id. And log the MAC and User-Name, along with the NAS IP, port, etc. Unless things are completely insane, you have enough information to do this.
I'll note that the default configuration logs User-Name *and* Calling-Station-Id, which means that you have the name *and* the MAC of the device. The default configuration also logs Called-Station-Id, along with NAS IP, port, etc. Which means that you know where the device is on the network.
If the certificate is compromised, you have all the information you need. You can tell which certificate has been compromised, and can (a) revoke the cert, and (b) kick the user offline.
Again, WE CANNOT CHECK TLS FIELDS IN THE DEFAULT CONFIGURATION. I've explained why in great detail. You've ignored this.
Instead, you've referred to 'best practices" which you seem to have invented. You've made false analogies. You've claimed I'm wrong for stating how cert fields go to EAP-Identity and User-Name, despite me pointing to the RFCs which say this is how it works. You've gotten offended when we say your practices are wrong. But it's perfectly fine for you to say that our practices are wrong. And to imply that we don't care about security.
We simply cannot update the default configuration to work everywhere, in all possible configurations, always, no matter what. This *is* what you're asking us to do.
We've explained why that's true. We've explained what you should do in order to take responsibility for your local configuration. Instead of learning, you're getting offended that we're telling you you're wrong. And you're implying that we don't care about security.
If you want to piss off the FreeRADIUS developers, you're doing a great job. If you want to learn how to make your system better (and come up with a simpler solution), you're failing miserably.
For anyone who's reading this, don't implement Roberto's solution. It's heavyweight, complex, and unnecessary.
Instead, issue certificates which contain as much information as possible about the device, mainly MAC addresses.
Instead, check users who are authenticating, and ensure that only known users are authenticating. Reject users who aren't known, etc.
Instead, if the NASes send you crap, figure out what extra information you DO need to log, and add that to the logs.
And don't get upset that FreeRADIUS is missing a magic button which says "do what I want". Those buttons don't exist in the real world.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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 3/24/21 8:26 PM, Roberto.Franceschetti@ocfl.net wrote:
Why in the world should we be limited to assigning one specific certificate to one single IoT? Because everything else is stupid.
We are actually assigning individual certificates for each vehicle,
Good.
but what it we didn't want to as we were satisfied in knowing that each Fire station had its own certificate for their devices? Using the same private key on various devices is really bad practice. Because if one device is compromised you have to modify all affected devices which imposes more risk for your availability. Especially in case of physically moving entities (vehicles) you don't want that.
I even saw people distributing their wild-card TLS server cert with a single private key issued for a second-level domain to hundreds of different TLS servers. Well, something like this is clearly asking for trouble.
There are too many scenarios, and again, NONE OF THIS IS AN ISSUE IF YOU LOG THE SERIAL NUMBER AND ISSUER of the cert used to authenticate. Maybe I don't understand you. But if you're using the same X.509 cert on several devices it would always be the same 2-tuple (issuer name, serial no). You would still need to log and/or attribute-map other device information along with that.
Ciao, Michael.
On Mar 24, 2021, at 3:26 PM, Roberto.Franceschetti@ocfl.net wrote:
I've been doing this for 20+ years as well. You focus on developing software and creating RFCs,
As I've said, I've also spent much of that time building actual real-world systems. Please don't minimize that.
I focus on security and ensuring applications are secure and also develop software myself. I insist that unless you log the EAP-TLS certificate data, freeradius is lacking security as you CANNOT find out what certificate is compromised when using data logged and audited by freeradius in its default configuration. You need to log the client cert's serial number and issuer. If you don't, there is NO WAY to to find out what cert is compromised.
You're strenuously arguing a point we've already agreed to. I already know what the default configuration logs, and why. Matthew and I have explained WHY the default configuration does what it does, and what YOUR responsibility is. Why not address the reasons we gave why the default configuration is the way it is? Show that you understand our position, and then try to refute it. You're just not doing that right now. Which makes it clear that you don't understand my position. Which means that your counter-arguments are largely irrelevant.
If you control the certificates, then you can cross-correlate the fields. It's simply a matter of reading the debug output. You think we run freeradius in debug mode and log the output...? It's irrelevant what shows in freeradius -X in a production environment. What matters in case someone hacked in is what's in the logs/database. They don't contain the debug output.
That's just missing the point. The debug output is where you START your local customizations. Don't pretend that I'm an idiot who's asking you to always run the server in debug mode. Don't pretend I'm an idiot who doesn't understand that the debug output doesn't go into the database. That implication is rude, ignorant, and uncalled for. It shows that your counter-argument is based on ad hominems and false assumptions.
The only thing the debug output is useful for is to use its data to see what's available and make use of it thru customizations. Which is exactly what we did. We customized freeradius using the info we saw in the debug output, and that required changing the database schema and the logging schema to capture cert information.
Which is what we told you to do. And what *everyone* has to do. The default configuration works *mostly* in *most* situations. But it has to be customized.
I'm simply telling you that would you need to make those changes in the default freeradius configuration as well, because right now you're not logging the identity used to authenticate with EAP-TLS, and that's a big security issue.
I'm simply telling YOU why you're wrong. instead of addressing my points, you just repeat yourself. It shows that your counter argument can't, in fact, address my points.
I'll note that the default configuration logs User-Name *and* Calling-Station-Id, which means that you have the name *and* the MAC of the device. The default configuration also logs Called-Station-Id, along with NAS IP, port, etc. Which means that you know where the device is on the network. You are 100% incorrect here, again.
Bullshit. You can believe that I don't understand RADIUS / EAP / TLS, or you can believe that you don't understand my points. I know which one is easier for you, but that doesn't change what's going on here.
Did actually realize that I can configure a Parallels/VMware guest with a completely bogus MAC address, and authenticate via WiFi and EAP-TLS with a stolen certificate by specifying a completely fake User-Name?
OMFG, REALLY? HOLY SHIT!!!! I mean, it's not like I *admitted* that in a prior email. But it's hard to address my comments. It's easier to have counter-arguments which assume I'm a freaking idiot.
Will you tell me how in the world I'm supposed to find the compromised certificate if BOTH the MAC and the User-Name are fake? I CANNOT.
I've explained. Since you haven't learned from that explanation, there isn't more I can do.
..and you come up with all sorts of "you should do this" like this one. Why in the world should we be limited to assigning one specific certificate to one single IoT?
Because using the same certificate in multiple devices is insecure and wrong. It costs you NOTHING to create more certificates. It costs you enormous amounts of insecurity to have the same cert on multiple devices. The fact that you don't see this as a problem is a huge red flag: You should not be recommending "best practices".
There are too many scenarios, and again, NONE OF THIS IS AN ISSUE IF YOU LOG THE SERIAL NUMBER AND ISSUER of the cert used to authenticate. If you log that information, then you're logging the method used to authenticate. How can you even argue that it's not needed?
Because I didn't argue that. So your counter-arguments are based on lying about what I said. Your position is based on lies, misunderstanding and/or ignoring my position, simple repetition, and implying that I'm an idiot. Why do you feel that this is the best approach? Alan DeKok.
Hello, ernestly: This discussion is a real pity. The matter is complex, and the questions raised may be relevant for more users. Could everyone please take the personal fierceness out of the dispute and stick to the technical points? Unfortunately, my experience with EAP-TLS is very limited, but obviously we would prefer it for our Clients in the future, too. Watching discussions on this list is often a good way to see what problems might lie ahead when, e.g. using a feature you have not used before. So I would really like to understand things, but it seems sort of hard to match the two points of view. Roberto: We DO need to log bulletproof cert details like serial number. Alan: Go set up your clients in a sane way, then you get your correlation for free. Roberto: We already try, but vendors won't play along. Alan: Then we are far from standards, and the default config cannot cover every weird situation that might arise. But there's always a way to fix it through the config. Roberto: But the default config/FR's processing MUST cover this, otherwise it a crap, security-wise. Roberto, you've really dived deeply into your specific kind of problem. Why not submit patches that try to improve the default config, if it is this clear what is missing? I would really be interested to see what exactly should change. What I haven't understood so far: Given Roberto's situation, _can_ you tweak the config to log the data he wants, or would you need to change the processing at some point (e.g. changing openssl lib calls to extract more information)? Martin -- Dr. Martin Pauly Phone: +49-6421-28-23527 HRZ Univ. Marburg Fax: +49-6421-28-26994 Hans-Meerwein-Str. E-Mail: pauly@HRZ.Uni-Marburg.DE D-35032 Marburg
On Mar 24, 2021, at 4:59 PM, Martin Pauly <pauly@hrz.uni-marburg.de> wrote:
Watching discussions on this list is often a good way to see what problems might lie ahead when, e.g. using a feature you have not used before. So I would really like to understand things, but it seems sort of hard to match the two points of view.
The two points of view are this: Roberto: FR is broken because it doesn't do what I want out of the box Alan: FR does the right thing most of the time, for most people. If your situation is unusual or more complex, you need to edit the configuration. This is the same position taken by Matthew. The disagreement here is that Roberto is strenuously trying to convince me that bad actors can do bad things. And implying that I don't already know that. I do know that already. I've said so repeatedly. The disagreement is that Roberto wants us to update the default configuration to match his environment. I've explained why that request is wrong. Instead of addressing my reasons, he's just repeated his arguments, and implied I don't know what I'm talking about. Matthew has already explained that in some situations, the server won't even log session information for users. Because NAS vendors don't follow the standards, and don't put session information into the standard attributes which FreeRADIUS expects. The issues that Roberto is seeing are a tiny piece of the raging dumpster fire which is RADIUS. There is literally NOTHING we can do to the default configuration which will make it perfectly secure in all situations. So we are drawing a line. Roberto disagrees with where that line is drawn, which is fine. He can have opinions. What is inappropriate here is the implication that I'm stupid, that I don't understand how things work, and that I don't care about security.
Roberto: We DO need to log bulletproof cert details like serial number. Alan: Go set up your clients in a sane way, then you get your correlation for free. Roberto: We already try, but vendors won't play along.
You control the certificates, but not what goes into the EAP-Identity. But a nonsense EAP identity is one of a very few weird things that a vendor can do. There are still other fields you can use to cross-correlate information. But you have to write those correlation rules manually, for your local system. We can't do this in the default configuration. I've explained this. These rules are created by reading the debug output, and then writing rules based on what you see. The response to that recommendation was a comment implying that I didn't know that the debug output didn't go into the database. Just.... enough. I have no idea why it's so important for Roberto to imply that I'm an idiot. It's unproductive, and insulting. I won't put up with that kind of nonsense.
Alan: Then we are far from standards, and the default config cannot cover every weird situation that might arise. But there's always a way to fix it through the config. Roberto: But the default config/FR's processing MUST cover this, otherwise it a crap, security-wise.
And that's where we disagree. The default configuration does NOT cover every possible weird situation, and WILL NOT cover ever possible weird situation. It is wrong and naive to ask that it does.
Roberto, you've really dived deeply into your specific kind of problem. Why not submit patches that try to improve the default config, if it is this clear what is missing? I would really be interested to see what exactly should change.
"Log TLS cert serial number on Access-Accept". Except, of course, that isn't enough. Maybe the NAS vendors are broken, as Matthew has pointed out. Then what? You've logged a TLS cert serial number, but you have no idea what device it's for, or where that device is located on the network. This is why my recommendation (as always) is for people to understand their local network, and configure it to their local needs.
What I haven't understood so far: Given Roberto's situation, _can_ you tweak the config to log the data he wants, or would you need to change the processing at some point (e.g. changing openssl lib calls to extract more information)?
Yes. Update the schemas to include TLS cert serial. Update the SQL queries to log the TLS cert serial. But, and this is a huge BUT. There are *still* situations where that won't work. So even if we add that to the default configuration, someone *else* will jump in and say "I bought equipment from vendor X, which doesn't put session information into the standard attributes, so FR doesn't log it. OMG, FR is broken!" Such comments will be dealt with politely at first, and then with repeated slaps upside the head if they continue. Here's the official recommendations for EAP-TLS: * use your own CA, so you control which certificates are issued. * use ONE client certificate per device. Issuing the same certificate to multiple devices is broken and wrong * include as much information as possible in the client certificate. Names, MAC addresses, etc. * when a user authenticates, check the information in RADIUS (User-Name, Calling-Station-ID) against the fields in the client cert. If they disagree, then someone is likely doing something bad, and you can reject the user * if the vendor equipment does stupid things, then most of the time you can work around it by following the previous guideline * don't buy equipment from broken vendors who do stupid things. It makes your life harder. * read the debug logs to see what kind of things are sent by the NAS. Then, write rules to store what you need in the DB. Maybe update the DB schema. * don't write scripts to scan / update the DB. This is almost always unnecessary. Instead, write SQL queries to update the *relevant* fields. Use information taken from the packets, certificates, etc. Read the debug output to see what information is available * don't tell the FR developers that they're idiots. It won't end well. * don't ask that the default configuration be updated to match your particular use-case. It won't end well. I'm currently writing an RFC which says this (not the last 2 points). So that when people argue, I can point to the doc and say "this is how it's done". And also so that when vendors do stupid things, people can point to the doc and say "here's how to do it correctly". People are free to review the doc and comment. But they need to do so based on understanding how things work, and not by implying that the author is an idiot. Alan DeKok.
Freeradius allows EAP-TLS authentication with certificates. Freeradius is however not logging which certificate was used to authenticate. Thus if a certificate is stolen/compromised, admins will be unable to determined which certificate needs to be revoked in order to stop the abuser. A system that performs authentication must log the credential used to login. With EAP-TLS, the "credential" is the certificate used to authenticate. Freeradius needs to log at a minimum the certificate's issuer, and the serial or CN so that the certificate used to login can be identified. This is not happening out-f-the-box. There's no option in the configs to enable the logging of that information. We had to (1) spend several days trying to figure out how to resolve this, and (2) make changes to the database and to a couple of config files to make it happen. All I've pointed out from the beginning is that this EAP-TLS logging capability should be included as option (enabled by default) in freeradius, as right now when it comes to EAP-TLS, freeradius is an application that performs authentication without logging the credential (certificate) used to authenticate. Roberto
On Mar 24, 2021, at 6:09 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 24, 2021, at 4:59 PM, Martin Pauly <pauly@hrz.uni-marburg.de> wrote:
Watching discussions on this list is often a good way to see what problems might lie ahead when, e.g. using a feature you have not used before. So I would really like to understand things, but it seems sort of hard to match the two points of view.
The two points of view are this:
Roberto: FR is broken because it doesn't do what I want out of the box
Alan: FR does the right thing most of the time, for most people. If your situation is unusual or more complex, you need to edit the configuration.
This is the same position taken by Matthew.
The disagreement here is that Roberto is strenuously trying to convince me that bad actors can do bad things. And implying that I don't already know that. I do know that already. I've said so repeatedly.
The disagreement is that Roberto wants us to update the default configuration to match his environment. I've explained why that request is wrong. Instead of addressing my reasons, he's just repeated his arguments, and implied I don't know what I'm talking about.
Matthew has already explained that in some situations, the server won't even log session information for users. Because NAS vendors don't follow the standards, and don't put session information into the standard attributes which FreeRADIUS expects.
The issues that Roberto is seeing are a tiny piece of the raging dumpster fire which is RADIUS. There is literally NOTHING we can do to the default configuration which will make it perfectly secure in all situations. So we are drawing a line. Roberto disagrees with where that line is drawn, which is fine. He can have opinions.
What is inappropriate here is the implication that I'm stupid, that I don't understand how things work, and that I don't care about security.
Roberto: We DO need to log bulletproof cert details like serial number. Alan: Go set up your clients in a sane way, then you get your correlation for free. Roberto: We already try, but vendors won't play along.
You control the certificates, but not what goes into the EAP-Identity. But a nonsense EAP identity is one of a very few weird things that a vendor can do. There are still other fields you can use to cross-correlate information.
But you have to write those correlation rules manually, for your local system. We can't do this in the default configuration. I've explained this. These rules are created by reading the debug output, and then writing rules based on what you see.
The response to that recommendation was a comment implying that I didn't know that the debug output didn't go into the database.
Just.... enough. I have no idea why it's so important for Roberto to imply that I'm an idiot. It's unproductive, and insulting. I won't put up with that kind of nonsense.
Alan: Then we are far from standards, and the default config cannot cover every weird situation that might arise. But there's always a way to fix it through the config. Roberto: But the default config/FR's processing MUST cover this, otherwise it a crap, security-wise.
And that's where we disagree. The default configuration does NOT cover every possible weird situation, and WILL NOT cover ever possible weird situation. It is wrong and naive to ask that it does.
Roberto, you've really dived deeply into your specific kind of problem. Why not submit patches that try to improve the default config, if it is this clear what is missing? I would really be interested to see what exactly should change.
"Log TLS cert serial number on Access-Accept".
Except, of course, that isn't enough. Maybe the NAS vendors are broken, as Matthew has pointed out. Then what? You've logged a TLS cert serial number, but you have no idea what device it's for, or where that device is located on the network.
This is why my recommendation (as always) is for people to understand their local network, and configure it to their local needs.
What I haven't understood so far: Given Roberto's situation, _can_ you tweak the config to log the data he wants, or would you need to change the processing at some point (e.g. changing openssl lib calls to extract more information)?
Yes. Update the schemas to include TLS cert serial. Update the SQL queries to log the TLS cert serial.
But, and this is a huge BUT. There are *still* situations where that won't work. So even if we add that to the default configuration, someone *else* will jump in and say "I bought equipment from vendor X, which doesn't put session information into the standard attributes, so FR doesn't log it. OMG, FR is broken!"
Such comments will be dealt with politely at first, and then with repeated slaps upside the head if they continue.
Here's the official recommendations for EAP-TLS:
* use your own CA, so you control which certificates are issued.
* use ONE client certificate per device. Issuing the same certificate to multiple devices is broken and wrong
* include as much information as possible in the client certificate. Names, MAC addresses, etc.
* when a user authenticates, check the information in RADIUS (User-Name, Calling-Station-ID) against the fields in the client cert. If they disagree, then someone is likely doing something bad, and you can reject the user
* if the vendor equipment does stupid things, then most of the time you can work around it by following the previous guideline
* don't buy equipment from broken vendors who do stupid things. It makes your life harder.
* read the debug logs to see what kind of things are sent by the NAS. Then, write rules to store what you need in the DB. Maybe update the DB schema.
* don't write scripts to scan / update the DB. This is almost always unnecessary. Instead, write SQL queries to update the *relevant* fields. Use information taken from the packets, certificates, etc. Read the debug output to see what information is available
* don't tell the FR developers that they're idiots. It won't end well.
* don't ask that the default configuration be updated to match your particular use-case. It won't end well.
I'm currently writing an RFC which says this (not the last 2 points). So that when people argue, I can point to the doc and say "this is how it's done". And also so that when vendors do stupid things, people can point to the doc and say "here's how to do it correctly".
People are free to review the doc and comment. But they need to do so based on understanding how things work, and not by implying that the author is an idiot.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
I'm sorry, but you're still completely missing my points. Matthew and I have both explained them in great detail, so it's not clear why they're not coming across. In short, it is your responsibility to ensure that your local site is secure. The default configuration works most of the time, for most people. We know that vendors do all kinds of stupid things. We know that many fields can be spoofed. We know that when vendors break EAP / RADIUS, there are situations where the default configuration will not work. It is IMPOSSIBLE for us to anticipate every possible situation that uses FreeRADIUS. It is IMPOSSIBLE for us to update the default configuration with examples for every possible site. It is IMPOSSIBLE for the default configuration to log all of the possible information which is needed by all possible networks. The most we can do is to update the documentation to say "Hey, please be aware of this problem, and here are some options for addressing it". When you ask for options in the default configuration to do this, our response is "edit the config files". You DO have options already. What is IMPOSSIBLE is an on/off flag for every possible situation. Sorry, but that's the reality. Blaming us, attacking us, or implying that we're idiots is just not the correct response. Alan DeKok.
participants (5)
-
Alan DeKok -
Martin Pauly -
Matthew Newton -
Michael Ströder -
Roberto.Franceschetti＠ocfl.net