RadSec support (RFC 6614 RADIUS TCP over TLS)?

136 views
Skip to first unread message

Colin Gordon

unread,
Dec 11, 2023, 11:48:22 AM12/11/23
to RCDevs Security
Hello, I'd like to use RADIUS Bridge support with OpenOTP.
Does the OpenOTP RADIUS Bridge support RFC 6613 RADIUS over TCP, or  (more importantly) RFC 6614 TLS for RADIUS (aka "RadSec")?

The use case is that we want to use OpenOTP to support testing for IEC 62351-8 RBAC for energy systems which does support RADIUS, but it mandates RADIUS according to RFC 6614 (TCP RADIUS over TLS).

Thanks!

Yoann Traut (RCDevs)

unread,
Dec 11, 2023, 12:04:04 PM12/11/23
to RCDevs Security
Hello, 

As far as I know, we support Radius over TCP from RFC 6613 but not the RFC 6614 for TLS.
I will check with dev team and let you know their feedback. 

Regards

Yoann Traut (RCDevs)

unread,
Dec 12, 2023, 4:36:05 AM12/12/23
to RCDevs Security
Hello, 

The Radius TCP over TLS will be enabled in next Radius Bridge version. 

Regards

Yoann Traut (RCDevs)

unread,
Dec 12, 2023, 11:28:45 AM12/12/23
to RCDevs Security
Hello, 

You can give a try with the following version:

We are interested in your feedback as you are the first one asking us for that feature and we are also not 100% sure it will works as expected. Additionally, we do not have any integration in place to test it. 
It is normally available on the 1812 port over TCP.

Regards

Yoann Traut (RCDevs)

unread,
Dec 20, 2023, 11:47:26 AM12/20/23
to RCDevs Security
Hello, 

Any feedback regarding this topic? 

Regards

Colin Gordon

unread,
Dec 28, 2023, 1:48:17 AM12/28/23
to RCDevs Security
Hello Yoann, I'm setting up a VM to test it now.
Any special instructions for running it?

Colin Gordon

unread,
Dec 28, 2023, 1:48:28 AM12/28/23
to RCDevs Security
Hello Yoann, I did install the RCDevs VM to test this out.
I installed the package you posted here.
I'm stepping through RADIUS UDP, then TCP, then TLS.
I can get RADIUS over UDP to work fine (I get access-accept for the admin user).
However, I cannot get RADIUS over TCP to function. My radtest client gives me an error: 

radtest -P tcp admin password 10.200.1.61:1812 0 testing123
Sent Access-Request Id 124 from 10.200.1.85:41528 to 10.200.1.61:1812 length 75
        User-Name = "admin"
        User-Password = "password"
        NAS-IP-Address = 127.0.1.1
        NAS-Port = 0
        Message-Authenticator = 0x00
        Cleartext-Password = "password"
radclient: Received bad packet: TCP connection has been closed

Here is the radiusd.log:

Wed Dec 27 17:30:16 2023 : Error: Ignoring request to auth proto tcp address * port 1812 (TLS) bound to server default from unknown client 10.200.1.85 port 41528 proto tcp

I modified my radiusd.conf file with the following information:

listen {
        type = auth
        protocol = tcp
        ipaddr = *
        port = 1812
}

Let me know what I could be doing wrong. Thanks!


On Wednesday, December 20, 2023 at 10:47:26 AM UTC-6 Yoann Traut (RCDevs) wrote:

Colin Gordon

unread,
Jan 2, 2024, 3:33:13 AMJan 2
to RCDevs Security
Hello @Yoanne, I *did* get this working successfully.

First, the client I used was radsecproxy 1.9.3 for RadSec testing. Here is my radsecproxy.conf:

tls defaultServer {
    CACertificateFile                   /etc/radsecproxy/certs/ca/test.crt # /opt/radiusd/conf/trusted.crt
    CertificateFile                     /etc/radsecproxy/certs/cert.pem # /opt/radiusd/conf/radiusd.crt
    CertificateKeyFile                  /etc/radsecproxy/certs/cert.key  # /opt/radiusd/conf/radiusd.key
}

client incoming-udp {
        host 0.0.0.0/0
        type udp
        secret testing123
}

server outgoing-tls {
        host                    10.200.1.61
        port                    1812
        IPv4Only                on
        type                    TLS
        tls                     defaultServer
        CertificateNameCheck    off
        secret                  testing123
}

realm * {
        server outgoing-tls
}

From my test machine with radsecproxy I could run this command and authenticate successfully: radtest -P udp admin password 127.0.0.1:1812 0 testing123

Next, my openotp VM setup:
First the /opt/radiusd/conf/clients.conf:

client any {
   ipaddr = *
   proto = *
   secret = testing123
}

Next, I edited /opt/radiusd/conf/radiusd.conf to enable the following:
cert_support = yes
machine_cert = yes

I'm not sure these configurations are needed - you should document this in the next radius bridge release.
Finally, some additional suggestions:
1. Please set the RadSec authentication listener port in /opt/radiusd/lib/radiusd.ini to TCP port 2083 (per RFC 6614). This was highly confusing at first since TCP 1812 is usually dedicated to RADIUS over TCP (RFC 6613).
2. Consider adding a RADIUS TCP (RFC 6613) authentication listener support alongside the RadSec listener to radiusd.ini. All told you would have three RADIUS listeners available:
- UDP port 1812
- TCP port 1812 (RFC 6613)
- TCP port 2086 with TLS (RFC 6614 RadSec)

3. Finally, just minor documentation to notify folks you've added support for RFC 6613 and RFC 6614 and how to tweak/enable it.

That's all I can think of for now. Thanks for considering support for RadSec - industrial cyber standards require RFC 6614 (IEC 62351-8:2020).

- Colin



Colin Gordon

unread,
Jan 4, 2024, 5:37:11 AMJan 4
to RCDevs Security
Three edits:

RadSec is TCP Port 2083 (not 2086)
Also, I generated and used the OpenOTP "admin" user PKI certificate for the RadSec client authentication:

    CertificateFile                     /etc/radsecproxy/certs/cert.pem # "admin" user cert radiusd.crt
    CertificateKeyFile                  /etc/radsecproxy/certs/cert.key  # "admin" user cert private key radiusd.key

I didn't know if those steps were necessary, so it would be good to know in the updated documentation if user cert generation is necessary to authenticate the TLS channel with RadSec.
Thanks

Yoann Traut (RCDevs)

unread,
Jan 4, 2024, 6:20:15 AMJan 4
to RCDevs Security
Hello, 

There is nothing to configure in order to enable Radius TCP over TLS with the provided package. 
It is enabled by default after the update and it is using the default 1812 port on TCP.

[root@webadm1 conf]# netstat -tulpn | grep rad

tcp        0      0 0.0.0.0:1812            0.0.0.0:*               LISTEN      304771/rcdevs-radiu 

tcp        0      0 0.0.0.0:1813            0.0.0.0:*               LISTEN      304771/rcdevs-radiu 

tcp        0      0 0.0.0.0:18120           0.0.0.0:*               LISTEN      304771/rcdevs-radiu 

udp        0      0 0.0.0.0:18120           0.0.0.0:*                           304771/rcdevs-radiu 

udp        0      0 0.0.0.0:1812            0.0.0.0:*                           304771/rcdevs-radiu 

udp        0      0 0.0.0.0:1813            0.0.0.0:*                           304771/rcdevs-radiu 


You can change the port in your client configuration in order to use the 1812 instead of 2083. If on your client side, you can not change it, then you can change the port in /opt/radiusd/lib/radiusd.ini


Our radtest client is just a small script which is using the radclient package located in  /opt/radiusd/libexec/radclient : 


[root@webadm1 bin]#  ../libexec/radclient

radclient: Insufficient arguments

Usage: radclient [options] server[:port] <command> [<secret>]

  <command>              One of auth, acct, status, coa, disconnect or auto.

  -4                     Use IPv4 address of server

  -6                     Use IPv6 address of server.

  -c <count>             Send each packet 'count' times.

  -d <raddb>             Set user dictionary directory (defaults to /opt/radiusd/conf).

  -D <dictdir>           Set main dictionary directory (defaults to /opt/radiusd/lib/dictionaries).

  -f <file>[:<file>]     Read packets from file, not stdin.

                         If a second file is provided, it will be used to verify responses

  -F                     Print the file name, packet number and reply code.

  -h                     Print usage help information.

  -n <num>               Send N requests/s

  -p <num>               Send 'num' packets from a file in parallel.

  -q                     Do not print anything out.

  -r <retries>           If timeout, retry sending the packet 'retries' times.

  -s                     Print out summary information of auth results.

  -S <file>              read secret from file, not command line.

  -t <timeout>           Wait 'timeout' seconds before retrying (may be a floating point number).

  -v                     Show program version information.

  -x                     Debugging mode.

  -P <proto>             Use proto (tcp or udp) for transport.


So you can use directly the radclient provided with ou Radius bridge package in order to perform your tests if needed.

If you are trying to authenticate the Radius client calling our Radius Server, then you should not use a user certificate but a client certificate which can be issued from WebADM GUI.


Regards

Yoann Traut (RCDevs)

unread,
Jan 4, 2024, 6:47:02 AMJan 4
to RCDevs Security
But if the goal is to use EAP protocols for users and/or computers authentications, you need to enable the following settings: 


# OpenOTP authentication support

# You may set to 'no' if you want RadiusBridge to support EAP-TLS (ie. cert_support) only.

# OpenOTP authentication is the default RadiusBridge operating mode and is enabled by default.

auth_support = yes


# EAP-TLS Wifi support

# Enable cert_support if you want to use EAP-TLS authentication for Enterprise Wifi.

# With EAP-TLS, the user authentication uses a user certificate only (no username, password or OTP). 

# The user certificates are generated in WebADM or the self-services. You need to enable the OCSP

# service URL below with EAP-TLS.

cert_support = yes


# EAP-TLS with machine certificates

# Allows WebADM client certificates to be used for EAP-TLS Wifi authentication.

# By default, 'cert_support' allows login with user-registered certificates only.

machine_cert = yes


Yoann Traut (RCDevs)

unread,
Jan 4, 2024, 6:47:25 AMJan 4
to RCDevs Security
https://docs.rcdevs.com/howtos/eap_cert_auth/eap/


Reply all
Reply to author
Forward
0 new messages