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
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
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
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
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
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
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
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
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.
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
