Thursday, December 22, 2005
Radius and TACACS
One of the solutions that was designed to accommodate the remote worker is that of RADIUS. Remote Authentication Dial-In User Service is what the acronym actually stands for. It is actually fairly descriptive as that is pretty much what it is used for. The worker will remotely authenticate for access to that remote network. I have previously mentioned that I like to map protocols before to the OSI Reference Model. This helps one visualize just what protocols belong where in the grand scheme of things. In the OSI model RADIUS fits into the application layer. This protocol is no exception either to the client/server model. A client will log into the RADIUS server and supply the required credentials. Also RADIUS uses UDP as a transport protocol to ferry about its information.
Like many well known protocols RADIUS has some well known ports that it is normally configured to be listening on. They are port 1812 and port 1813 with port 1813 being used for RADIUS accounting. Those ports are also RFC compliant, but what does RFC compliant actually mean? Well when the designers of RADIUS were sitting around talking about the design specifications for RADIUS they decided that they would make RADIUS use ports 1812 and 1813. The various design considerations were eventually all consolidated into what is called an RFC. After a period of time that RFC was accepted and thusly the ports of 1812 and 1813 were then called RFC compliant, as they were included in the original design of it.
I want details!
The devil is always in the details, and if you want details it is always best to go to the definitive source. In our case that would be RFC 2138 which deals with RADIUS itself and contains all of the details about it. Seen as most people break out into hives if they think of reading an RFC I will summarize a few important details for you. One of the biggest things to realize about RADIUS is that it will support various authentication methods. Notably, you can use PPP, PAP, and CHAP to name most of them. If you are familiar with Cisco gear or are in charge of supporting the routers and switches from them, then you are no doubt familiar with the various authentication methods offered by RADIUS.
Now once a user has supplied the required username and password combination and the RADIUS server receives it, it will do one of a couple of things. The RADIUS server will check its database for the received credentials and based on that, either reject the session or allow it. Further to the username and password combination, the RADIUS server can also check for validity by the port number. Typically RADIUS works as follows;
Access-Request: where the user sends their credentials to the server
Acess-Challenge: where the server sends a challenge and the user must respond
Based on the above access control the user is either authenticated or rejected. RADIUS itself, as mentioned earlier, uses UDP as its transport protocol, and that was decided during the initial design considerations for RADIUS. Using UDP has its advantages, notably there being less overhead and speed. This and other reasons was the driving force behind the choice of this transport protocol over TCP and its connection oriented design. Lastly, we should also realize that, like many application layer protocols, RADIUS has codes that were written into its core functionality. These codes deal with the access, accounting and status of RADIUS be it client or server. For further reading on this protocol I would suggest reading the above noted hyperlink for RFC 2138.
TACACS and TACACS+
Terminal Access Controller Access Control System or TACACS is similar to RADIUS and is used to regulate access to the network. One of the biggest differences between TACACS and RADIUS is that TACACS primarily uses TCP for its transport protocol needs vice the UDP that RADIUS will use. There are also three versions of TACACS with TACACS+ being the most recent. It is important to note that TACACS+ is not backwards compatible with the other earlier versions. This protocol is also an application layer protocol and observes the client/server model. Seen as TACACS+ is also a well known protocol it stands to reason that there is also a well known port associated with this activity, which is TCP port 49. That being said XTACACS does use UDP. There is always the exception to the rule!
Other notable differences between RADIUS and TACACS+ are that RADIUS only encrypts the password in the access request packet that is sent to the RADIUS server. TACACS+ on the other hand will encrypt the entire packet body, but will leave the TACACS+ header intact. TACACS+ does have weaknesses though, which can be exploited by a determined attacker. It is vulnerable to “birthday attacks” in which two messages use the same hash function and packet sniffing to mention a few.
Like many well known protocols RADIUS has some well known ports that it is normally configured to be listening on. They are port 1812 and port 1813 with port 1813 being used for RADIUS accounting. Those ports are also RFC compliant, but what does RFC compliant actually mean? Well when the designers of RADIUS were sitting around talking about the design specifications for RADIUS they decided that they would make RADIUS use ports 1812 and 1813. The various design considerations were eventually all consolidated into what is called an RFC. After a period of time that RFC was accepted and thusly the ports of 1812 and 1813 were then called RFC compliant, as they were included in the original design of it.
I want details!
The devil is always in the details, and if you want details it is always best to go to the definitive source. In our case that would be RFC 2138 which deals with RADIUS itself and contains all of the details about it. Seen as most people break out into hives if they think of reading an RFC I will summarize a few important details for you. One of the biggest things to realize about RADIUS is that it will support various authentication methods. Notably, you can use PPP, PAP, and CHAP to name most of them. If you are familiar with Cisco gear or are in charge of supporting the routers and switches from them, then you are no doubt familiar with the various authentication methods offered by RADIUS.
Now once a user has supplied the required username and password combination and the RADIUS server receives it, it will do one of a couple of things. The RADIUS server will check its database for the received credentials and based on that, either reject the session or allow it. Further to the username and password combination, the RADIUS server can also check for validity by the port number. Typically RADIUS works as follows;
Access-Request: where the user sends their credentials to the server
Acess-Challenge: where the server sends a challenge and the user must respond
Based on the above access control the user is either authenticated or rejected. RADIUS itself, as mentioned earlier, uses UDP as its transport protocol, and that was decided during the initial design considerations for RADIUS. Using UDP has its advantages, notably there being less overhead and speed. This and other reasons was the driving force behind the choice of this transport protocol over TCP and its connection oriented design. Lastly, we should also realize that, like many application layer protocols, RADIUS has codes that were written into its core functionality. These codes deal with the access, accounting and status of RADIUS be it client or server. For further reading on this protocol I would suggest reading the above noted hyperlink for RFC 2138.
TACACS and TACACS+
Terminal Access Controller Access Control System or TACACS is similar to RADIUS and is used to regulate access to the network. One of the biggest differences between TACACS and RADIUS is that TACACS primarily uses TCP for its transport protocol needs vice the UDP that RADIUS will use. There are also three versions of TACACS with TACACS+ being the most recent. It is important to note that TACACS+ is not backwards compatible with the other earlier versions. This protocol is also an application layer protocol and observes the client/server model. Seen as TACACS+ is also a well known protocol it stands to reason that there is also a well known port associated with this activity, which is TCP port 49. That being said XTACACS does use UDP. There is always the exception to the rule!
Other notable differences between RADIUS and TACACS+ are that RADIUS only encrypts the password in the access request packet that is sent to the RADIUS server. TACACS+ on the other hand will encrypt the entire packet body, but will leave the TACACS+ header intact. TACACS+ does have weaknesses though, which can be exploited by a determined attacker. It is vulnerable to “birthday attacks” in which two messages use the same hash function and packet sniffing to mention a few.
# posted by e247net : 6:14 PM
