radsecproxy

radsecproxy@lists.nordu.net

72 discussions

Adding support for dynamic authorisation messages (CoA/Disconnect)
by Harshit Jain 29 Apr '21

29 Apr '21

Hello, I was looking to add support for Dynamic Authorization Messages - Change of Authority (CoA) and Disconnect messages - to radsecproxy. RFC for this can be found here - https://tools.ietf.org/html/rfc5176 . Before diving headfirst, I wanted to ask if it is already on the roadmap or if there has been a design discussion that I can read up on. Thanks and regards, Harshit Jain

2 18

Query regarding setting SO_REUSEADDR to false for datagram sockets
by Harshit Jain 29 Apr '21

29 Apr '21

Hi, I see that we set SO_REUSEADDR to false while binding to a datagram socket whereas we set it to true for stream sockets. Is there a particular reason for this? In my setup, I have radsecproxy listening on *:2083 for UDP requests and I have a local radius server listening on localhost:3799 (among other external servers). I was looking to set a fixed source port from which radsecproxy sends out requests to the local radius server, so I added a source block to the server config like so server localServer { ... source 127.0.0.2:2083 } but I got an error saying "address already in use". I dug around and found that its because SO_REUSEADDR is not set for datagram sockets. Is there a reason for this and if so, is there any other way to add a fixed source port to a local radius server config block? Thanks and regards, Harshit

2 1

next radsecproxy release?
by Janos Mohacsi 22 Apr '21

22 Apr '21

Dear All, When the new radsecproxy is planned to be released? Best Regards, -- János Mohácsi Chief International R&D Officer, T&I service owner GÉANT activity coordinator in Hungary, EOSC GB member T: +36 30 555 7599 mohacsi.janos(a)kifu.gov.hu Kormányzati Informatikai Fejlesztési Ügynökség

2 1

dynamic lookups are not blocking, causes first auth to fail with fallback
by Paul Dekkers 25 Mar '21

25 Mar '21

Hi, If you have this realm block: realm /@.+\..+$/ { server dynamic server fallback.server.here accountingResponse on } radsecproxy will start to send the request to fallback.server.here because the dynamic part didn't resolve yet: it's not blocking. Only as soon as the config for the dynamic realm is in place, when the dynamicLookupCommand had a result, it will continue with that host. This results in part of the conversation going via one path, part of it via another. This breaks "the first" authentication for a realm. Unless there is no fallback of course: or if the fallback is done in the lookup script (else at the end, which is what I'm using now). So, while this not being problematic for me ;-) I was wondering if someone else stumbled upon this, and whether we can have the dynamic lookup blocking for the request? That would allow fallback "as documented". Regards, Paul

3 10

CACertificatePath does not seem to be working
by Imtiyaz Mohammad 20 Jan '21

20 Jan '21

Hi, In my setup, I am trying to verify the working of *CRLCheck *option in the tls config block of radsecproxy. I currently have a CACertificateFile statement in the radsecproxy config that is pointing to a ca.pem. I created a CRL using the ca.pem and ca.cnf and issued a SIGHUP to radsecproxy only to find the following error message:- Jan 18 11:31:56 2021: verify error: num=3:unable to get certificate CRL:depth=0:/C=FR/ST=Radius/O=Example Inc./CN= 127.0.0.1/emailAddress=admin(a)example.org Jan 18 11:31:56 2021: tlsconnect: SSL connect to 127.0.0.1 failed: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed Looked like radsecproxy tried to pick up the CRL file but it could not find it where it was expecting it. Hence I removed the CACertificateFile option from the TLS block of the config file and added CACertificatePath option that points to the directory that has the CA and CRL files and now I am getting this error. What am I missing here ? ....Jan 19 08:05:36 2021: tlsconnect: connecting to 127.0.0.1 Jan 19 08:05:36 2021: connecttcphostlist: trying to open TCP connection to 127.0.0.1 port 2083 Jan 19 08:05:36 2021: Connection up Jan 19 08:05:36 2021: connecttcphostlist: TCP connection to 127.0.0.1 port 2083 up Jan 19 08:05:36 2021: verify error: num=19:self signed certificate in certificate chain:depth=1:/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin(a)example.org/CN=Example Certificate Authority Jan 19 08:05:36 2021: tlsconnect: SSL connect to 127.0.0.1 failed: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed Jan 19 08:05:36 2021: tlsconnect: SSL connect to 127.0.0.1 failed Jan 19 08:05:36 2021: Next connection attempt to 127.0.0.1 in 60s ....Jan 19 08:06:36 2021: tlsconnect: connecting to 127.0.0.1 Thanks Imtiyaz

2 2

Logs are not being written to options.logdestination when -f (foreground) is passed to radsecproxy
by Imtiyaz Mohammad 05 Jan '21

05 Jan '21

Hello Fabian, We have noticed that the log destination option in the radsecproxy configuration file is completely ignored when radsecproxy is made to run in the foreground with the -f argument. Looking at the code ( snippet pasted below ), it looks to be something intentional. In radsecproxy.c radsecproxy_main() { //// if (!foreground) { debug_set_destination(options.logdestination ? options.logdestination : "x-syslog:///", LOG_TYPE_DEBUG); if (options.ftickssyslogfacility) { debug_set_destination(options.ftickssyslogfacility, LOG_TYPE_FTICKS); free(options.ftickssyslogfacility); } } } However, we think that if the configuration file has a log destination, it should override any other directive and we should write logs to that log destination instead of using* -f* as a toggle to write to STDOUT vs the log destination. Let us know what you think about this ? Here is my suggested fix , change the above snippet of code to:- if (options.logdestination) { debug_set_destination(options.logdestination, LOG_TYPE_DEBUG); free(options.logdestination); } else if (!foreground) { debug_set_destination("x-syslog:///", LOG_TYPE_DEBUG); } if (options.ftickssyslogfacility) { debug_set_destination(options.ftickssyslogfacility, LOG_TYPE_FTICKS); free(options.ftickssyslogfacility); } Thanks, Imtiyaz

2 1

Why is tlsreloadcrls() only reloading CA and CRLs and not client certs ?
by Imtiyaz Mohammad 18 Dec '20

18 Dec '20

Hello Fabian/Others, We were trying to handle the client certificate expiry using the SIGHUP mechanism that invokes *tlsreloadcrls*(). Just realized that the designated role for this function is to only reload CAs and CRLs and not client certificates. What was the intention behind this ? I would assume that since the CA certificates are used to sign the client certificates, A re-read / re-cache of just the CA certificates does not make sense as the client certificates were signed by an earlier version of the CA certificate and we are still working with the cached copies. Thanks Imtiyaz

2 2

Has someone tried to make radsecproxy handle config changes dynamically ?
by imtiyaz＠arista.com 20 Nov '20

20 Nov '20

Hello folks ! Greetings ! I am looking at a usecase wherein we want radsecproxy to handle config changes on the fly instead of having to restart the whole process. For example, say we add/del new radius servers or clients without affecting the existing sessions/threads. As I am comparing a few design choices to make this happen, wanted to check if someone has already worked on it ? If it is in roadmap for the immediate future, any design concepts someone might have already thought of but were not able to implement it ? Thanks, Imtiyaz

3 5

RADIUS/TLS dynamic discovery peer validation extravaganza
by Stefan Winter 24 Aug '20

24 Aug '20

Hello! right now I'm looking at a use case of RADIUS/TLS peer connections which is a bit different from standard. I wonder if someone could comment on the feasilibility/desirability if one uses certificates as sketched below. The idea is to cram EAP-specific authorization information into the certificates. They do not only contain the FQDN of the server one connects to, but also verifies whether that same server is authorized to authenticate certain realms. Both of the information elements (FQDN and NAI realm list) are to be included in the same certificate by the server. The FQDN of the server itself would be in the Subject (CN=server.fqdn.example); the list of authoritative realms would be in an arbitrarily long set of subjectAltName:DNS extensions. The client, when presented such a certificate from a server it connects to, should always exclusively look at the CN and abort the connection attempt when the server's name doesn't match the expectation (i.e. the discovered hostname from a NAPTR discovery). Notably, if the FQDN happens to be in the sAN:DNS list, it should still disconnect. CN is the only field that counts. Only if the CN matches, the next step would be to check the realm that was used as a starting point for NAPTR discovery, and verify that this realm is one of the sAN:DNS in the certificate. Again, the client should disconnect if that is not true. [1] Example: realm to be authenticated = userrealm.example NAPTR for userrealm.example yields FQDN server.example.com Client connnects to server.example.com Does server certificate have CN=server.example.com ? If not, disconnect. Does server certificate have a sAN:DNS=userrealm.example ? If not, disconnect. Still connected? Send RADIUS request through this connection. Is this kind of behaviour supported in radsecproxy at the present time? Could it? Greetings, Stefan Winter [1] This behaviour is "almost" like the semantically cleaner behaviour of RFC7585 - except that the list of realms is in a dedicated certificate extension called NAIRealm in the RFC, while here one would overload sAN:DNS instead.

3 2

Re: radsecproxy-1.8.2 released
by Fabian Mauchle 07 Aug '20

07 Aug '20

On 07.08.20, 07:45, "Fabian Mauchle" <fabian.mauchle(a)switch.ch> wrote: It took way too long, but finally I can announce the release of radsecproxy-1.8.0. Oops... of course radsecproxy-1.8.2 was released! -- Fabian

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

radsecproxy