Is it possible to use CHAP authentication with pam_radius?
I'm trying to implement external authentication for an appliance running CentOS 7. My research turned up the easiest solution as simply installing pam_radius from the repository. I did, and it works just fine (tested against a Freeradius 3.0 server with a single test user.) Running freeradiux with '-X' indicates that is using PAP: (0) User-Name = "XXX" (0) User-Password = "XXX" (0) NAS-IP-Address = XXX.XXX.XXX.XXX (0) NAS-Identifier = "sshd" (0) NAS-Port = 15050 (0) NAS-Port-Type = Virtual (0) Service-Type = Authenticate-Only ... (0) Found Auth-Type = PAP (0) # Executing group from file /etc/freeradius/3.0/sites-enabled/default (0) Auth-Type PAP { (0) pap: Login attempt with password (0) pap: Comparing with "known good" Cleartext-Password (0) pap: User authenticated successfully (0) [pap] = ok (0) } # Auth-Type PAP = ok For security reasons, I'd really like to use CHAP instead, but it doesn't seem to support that? The man pages and such don't mention CHAP. I went as far as downloading 1.4.0 and extracting the tarball and looking at the code. User-Password is Radius attribute 2, and looking at the source: 0 radius.h <global> 71 #define PW_PASSWORD 2 and 1 pam_radius_auth.c add_password 541 attr = find_attribute(request, PW_PASSWORD); 2 pam_radius_auth.c add_password 543 if (type == PW_PASSWORD) { 3 pam_radius_auth.c build_radius_packet 721 add_password(request, PW_PASSWORD, password, conf->server->secret); 4 pam_radius_auth.c build_radius_packet 727 add_password(request, PW_PASSWORD, "", conf->server->secret); 5 pam_radius_auth.c talk_radius 975 add_password(request, PW_PASSWORD, password, old_password); 6 pam_radius_auth.c talk_radius 978 add_password(request, PW_PASSWORD, password, server->secret); Am I missing something? Or am I out of luck? Thanks!
On Sep 26, 2019, at 1:06 PM, Dan Swartzendruber <dswartz@druber.com> wrote:
I'm trying to implement external authentication for an appliance running CentOS 7. My research turned up the easiest solution as simply installing pam_radius from the repository. I did, and it works just fine (tested against a Freeradius 3.0 server with a single test user.) Running freeradiux with '-X' indicates that is using PAP: ... For security reasons, I'd really like to use CHAP instead, but it doesn't seem to support that? The man pages and such don't mention CHAP. I went as far as downloading 1.4.0 and extracting the tarball and looking at the code. User-Password is Radius attribute 2, and looking at the source:
The pam_radius_auth module doesn't do CHAP. TBH, any "security" argument is not really relevant. The whole idea of "PAP is insecure" is a marketing checklist, not a security analysis. Alan DeKok.
On 2019-09-26 13:11, Alan DeKok wrote:
On Sep 26, 2019, at 1:06 PM, Dan Swartzendruber <dswartz@druber.com> wrote:
I'm trying to implement external authentication for an appliance running CentOS 7. My research turned up the easiest solution as simply installing pam_radius from the repository. I did, and it works just fine (tested against a Freeradius 3.0 server with a single test user.) Running freeradiux with '-X' indicates that is using PAP: ... For security reasons, I'd really like to use CHAP instead, but it doesn't seem to support that? The man pages and such don't mention CHAP. I went as far as downloading 1.4.0 and extracting the tarball and looking at the code. User-Password is Radius attribute 2, and looking at the source:
The pam_radius_auth module doesn't do CHAP.
TBH, any "security" argument is not really relevant. The whole idea of "PAP is insecure" is a marketing checklist, not a security analysis.
No argument here. Unfortunately, some of our customers are anal-retentive and have security compliance audits run, and having cleartext passwords is going to be problematic. I'm wondering if I could tunnel RADIUS over TCP using an ssh tunnel? This is a very small number of customers who will care, but they have a disproportionate influence...
On Sep 26, 2019, at 2:11 PM, Dan Swartzendruber <dswartz@druber.com> wrote:
No argument here. Unfortunately, some of our customers are anal-retentive and have security compliance audits run, and having cleartext passwords is going to be problematic.
The passwords aren't clear-text. They're encrypted on the wire. Just like PAP.
I'm wondering if I could tunnel RADIUS over TCP using an ssh tunnel? This is a very small number of customers who will care, but they have a disproportionate influence...
The pam_radius module doesn't support TCP. If you care, submit a patch so that the pam_radius module does CHAP. It should be ~30 LoC. Alan DeKok.
On 2019-09-26 14:18, Alan DeKok wrote:
On Sep 26, 2019, at 2:11 PM, Dan Swartzendruber <dswartz@druber.com> wrote:
No argument here. Unfortunately, some of our customers are anal-retentive and have security compliance audits run, and having cleartext passwords is going to be problematic.
The passwords aren't clear-text. They're encrypted on the wire. Just like PAP.
I thought I had seen criticisms that it the encryption wasn't that strong. Maybe I misunderstood...
I'm wondering if I could tunnel RADIUS over TCP using an ssh tunnel? This is a very small number of customers who will care, but they have a disproportionate influence...
The pam_radius module doesn't support TCP.
If you care, submit a patch so that the pam_radius module does CHAP. It should be ~30 LoC.
I might give that a try, thanks!
n Sep 26, 2019, at 2:29 PM, Dan Swartzendruber <dswartz@druber.com> wrote:
On 2019-09-26 14:18, Alan DeKok wrote:
On Sep 26, 2019, at 2:11 PM, Dan Swartzendruber <dswartz@druber.com> wrote:
No argument here. Unfortunately, some of our customers are anal-retentive and have security compliance audits run, and having cleartext passwords is going to be problematic. The passwords aren't clear-text. They're encrypted on the wire. Just like PAP.
I thought I had seen criticisms that it the encryption wasn't that strong. Maybe I misunderstood...
Yes. Lots of people have criticized it. Mainly people who know nothing about nothing. The encryption scheme is best described as "wonky". But no one has managed to crack it. Anyone who says otherwise is lying. If it had been cracked, you would see it on international news. Every ISP and switch manufacturer would be frantically upgrading. Alan DeKok.
On 2019-09-26 15:06, Alan DeKok wrote:
n Sep 26, 2019, at 2:29 PM, Dan Swartzendruber <dswartz@druber.com> wrote:
On 2019-09-26 14:18, Alan DeKok wrote:
On Sep 26, 2019, at 2:11 PM, Dan Swartzendruber <dswartz@druber.com> wrote:
No argument here. Unfortunately, some of our customers are anal-retentive and have security compliance audits run, and having cleartext passwords is going to be problematic. The passwords aren't clear-text. They're encrypted on the wire. Just like PAP.
I thought I had seen criticisms that it the encryption wasn't that strong. Maybe I misunderstood...
Yes. Lots of people have criticized it. Mainly people who know nothing about nothing.
The encryption scheme is best described as "wonky". But no one has managed to crack it. Anyone who says otherwise is lying.
If it had been cracked, you would see it on international news. Every ISP and switch manufacturer would be frantically upgrading.
Good to know, thanks for setting me straight. I'm going to let sleeping dogs lie :)
Hi Dan, On 26.09.2019 21:11, Dan Swartzendruber wrote:
I'm wondering if I could tunnel RADIUS over TCP using an ssh tunnel?
You can forward UDP over SSH. Just search google for "ssh port forwarding" and you will find lot of examples on how to forward traffic over ssh tunnels, like https://www.ssh.com/ssh/tunneling/example -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
You could try to use radsec, i.e. RADIUS over TCP https://wiki.freeradius.org/glossary/RadSec No idea about the current state of support in FR, but there is a tiny software called radsecproxy. Install it on either side of your connection and let it handle the outside traffic over TCP/TLS. This is e.g. in wide use between eduroam members. 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
participants (4)
-
Alan DeKok -
Dan Swartzendruber -
Martin Pauly -
Volodymyr Litovka