Computer networks have arguably helped worker efficiency and helped a company’s bottom line. Well with that has come the need for workers to, at times, remotely log into the corporate network. This is ideally done via secure means. Within the confines of this article we will look at several of these methods.
Corporate networks have not only grown in size over the years, but they have also grown in complexity. Over the years new services have appeared and been implemented to satisfy the growing demand for easy to use programs. This driving force to meet end user satisfaction goes on relentlessly and has accounted for much of today’s innovations. One of the most desired advantages has been for some workers to have the ability to work from home. These tele-commuters are one of the recent changes that have affected the work force and much to the benefit of the worker. This ability to tele-commute has greatly affected employee morale for the better. The problem is that these workers must also be able to communicate with the corporate network both remotely and securely. It is of little surprise that these concerns have been dealt with via a variety of solutions that all work quite well.
RADIUS is not just for Algebra
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.
While the above noted are two means of using authentication methods, they are not the only ones. Every network has its quirks and various architectures. With that said you would be best to take into account the various details of your network and from there make the best decision regarding what authentication method best suits your needs. Some of these methods can also in turn use other ones as well, such as TACACS+ and Kerberos. The bottom line is that every time you involve another layer or program to your network you are introducing another possible attack vector. You would be well advised to go with a mature technology for your remote authentication solution.
Lastly, it also makes sense that before purchasing such a means, that you make sure you can integrate it seamlessly into your existing production environment. While this article was very much a high level overview of some of the methods, there is a veritable mass of information available on this courtesy of the Internet and Google. Taking the time to research them will pay dividends later. I sincerely hope you enjoyed this article, and as always I welcome your feedback. Till next time!