In the earlier posts I have written about Radius PAP authentication and learnt about Radius packets construction/decryption through wireshark. In this post we will learn about creating RADSEC tunnels using RADSEC proxy, and learn how the classic UDP radius frames are protected using RADSEC.

We will use radsec proxy to create RADSEC Tunnels, as this is an open source.

Please go through the below posts thoroughly to understand this post better, as we are not discussing just the call flows.

RADIUS-ACCESS-REQUEST-DECRYPTION

RADIUS-ACCONTING-PACKET-DECRYPTION

We will be working with Radsec TLS1.2 tunnels in this post.

RADIUS security is based on the MD5 algorithm, which has been proven to be insecure. Very few attributes are encrypted (ex : Password, Md5 Authenticators etc). Most of the attributes are in clear text, it might help an attacker to get most of the information through packet capture.

RADSEC transports RADIUS UDP datagrams over TCP and TLS.

RADSEC gives the security for the RADIUS frames as the frames are being sent in a TLS Tunnels.

In this post, we will use the radsec proxy to create the Radsec Tunnels for Radius PAP, and we will check how the Radius frames are being sent in a TLS Tunnel.

We will discuss only about UDP -> TLS Tunnels Traffic in this post.

RADSEC PROXY

Below Figure 1 is the test setup that I have used to create Radsec tunnels.

Below are the steps to send the plain udp tunnels in a TLS tunnel.

Radsec client and radsecproxy will have the common shared secret and they will be operating on ports 1812/1813. Radsecproxy and radius server will have the shared secret must be “radsec” as per the RFC-6614 and they will be operating on port 2083.

The below sniffer capture shows the call flow for the scenario shown in the above Figure 1. I have filtered only the required frames in the below capture.

Below are the IP addresses of the servers in our scenario.

Radius Client = 172.16.10.25

Radsec Proxy = 172.16.10.27

Radius server = 172.16.10.132

Below are the steps to send the UDP datagrams into radsec tunnels.

Step 1

1. Create client and server certificates and have a TLS session in between Radsec Proxy and Radius server.
   1. We can create self signed certificates using openssl.

Step 2

1. Now we will simulate sending the radius access request to the Radsec proxy.
   1. There are multiple ways to simulate this, I have used radlogin as a radius client to send the radius access request and accounting request.
   2. You can also write your own script to send the radius access request by properly creating the md5 authenticators.
   3. Radius clients will send the frames to the port 1812/1813.
   4. The below figure shows the plain access request from Radius client to radsec proxy.

Step 3

1. Once the plain udp packet reaches the radsec proxy, it verifies the md5 authenticator of a radius frame (it will be calculated by shared secret). Once this is authenticator check is successful. radsec proxy will send the radius access request in a TLS tunnel to the Radius server.
   1. Note that , shared secret between radius client and radsec proxy should be known to the both of them.
   2. shared secret between radsec proxy and radius server must be “radsec” as per RFC-1644.
   3. radsec proxy will send the frames to the port 2083.
   4. Radsec proxy will calculate the md5 authenticator received from radius client. If the verification is successful, Radsec proxy sends the frame to the radius server by generating the authenticators using the shared secret “radsec”. If the verification fails, radsec proxy simply drop the radius frame.
      1. Note that radsec proxy will not simply replay the entire frame received from radius client, how ever the plain text authenticators will be changed [ Go through the earlier Radius PAP authentication to understand the purpose of this plain authenticator, and how is it different from md5 authenticator].

Step 4

1. Once the radius server receives the Radsec TLS frame, it decrypts the data and verifies it. If the authentication is successful, it replies to the radsec proxy in a radsec TLS tunnel to the port 2083.
   1. Note that if the md5 authenticatior of a Radius TLS frame is failed, it means that shared secret is wrong and radius server simply ignores the frame.
   2. If the md5- authenitcator of a frame is succesful, but the user-name or password entered is wrong , then Radius server will simply send the radius access reject.

Step 5

1. After receiving the radsec TLS response packet from radius server, radsec proxy will decrypt the frame and verifies the authenticators and sends the response received from the radius server in a plain UDP.
   1. Note the these responses will not be a just replay. Radius access responses will be generated based on the values received from the radius requests. [ Go through the earlier posts to understand how these responses will be calculated].

This is how the Radius Frames are being sent in a TLS tunnels.

Accounting Packets in a TLS Tunnel

Accounting packets will also be sent in a TLS tunnels. So, the accounting packets will also be secured.

Observe the below Accounting Request that is being sent from the Radius client to Radsec Proxy. Observe that most of the attributes are in a clear text.

Observe the below Radius Accounting Request that is being sent in a Radsec TLS Tunnel. Observe that the whole packet is sent in a TLS tunnel, and all the attributes are encrypted.

This is how we provide the security for radius frames.

Note that , we are having a separate proxy to create radsec tunnels because it is open source. If we have a radsec code deployed in a Radius client, then we can have a end-end Radius Tunnels between radius client and radius server. So, we will not have any plain radius udp packets going through the network.

In the next posts we will learn about decrypting the radsec TLS1.2/1.3 on wireshark.