"

 RADIUS Question 

I'm taking a Security+ class right now and one of the questions in our book is this:

Which of the following cannot be used as a RADIUS client?
A) VPN server
B) Wireless access point
C) Network access server
D) Windows workstation

Now, the answer according to the book is D) Windows workstation, which we all agreed with. However, we don't know why. Any input would be nice. 

If your windows workstation had a GINA module that acted as a RADIUS client the answer could be all of the above.   

Things like this actually do exist and are used for some applications such as guest networks and cyber cafes.

 Wireless section? 

Is it just me, or does the following not make sense:

Although RADIUS was not initially intended to be a wireless security authentication method, it improves the WEP encryption key standard, in conjunction with other security methods such as EAP-PEAP.

RADIUS does not ""improve"" on WEP; although auth credentials can be transmitted from the NAS/AP to the auth server using RADIUS, the underlying WEP security is still as vulnerable as it otherwise would be. 

Can we delete?

 

 Question - why UDP? 

It's always baffled me why RADIUS uses UDP and not TCP. UDP seems much better suited for streaming applications where the loss of a few packets is tolerable. A perfect example is streaming live video. But as a developer I can't see how these principals apply to what we're trying to achieve with the RADIUS protocol. Surely the overhead of TCP wouldn't have any scalability or performance issues on fast networks and modern hardware? Someone please enlighten me why they chose UDP for RADIUS.  

 Why UDP?  Answer 

RADIUS is designed to scale to large-scale deployments with dozens, maybe hundreds of BASs all talking occasionally to a couple of central servers. Given the underlying reliability of modern networks, the overhead of maintaining hundreds of open TCP connections would have been overkill. The alternative (open a connection each time a packet needs to be sent) would also have been inefficient (no point in performing a 3-way handshake for the sake of a single accounting update). On balance, UDP is probably the best choice.

Remember that RADIUS has built-in acknowledgement/retransmission mechanisms to cope with the occasional lost packet.

For a more flexible and robust protocol, see http://en.wikipedia.org/wiki/DIAMETER.

 

Another reason is that when RADIUS was designed, it was possible to implement a UDP stack in a single embedded chip, but a TCP stack was more complicated (read: more expensive). This seems rather silly now, but it was a real problem designing cheap devices back then.

You can still find the same reasoning in SIP-phones  although SIP can be used both over UDP and TCP, a lot of vendors only implement the UDP part.

  

 Bulk Changes 

Commited some new text at the start to try and speak to what RADIUS is/does for those who don't have much knowledge of it and its associated soup of TLAs. Think it would be good to axe/move some of the existing text especially the paragraphs including and immediatly following 'Many networks services ('

Some ideas for new sections:

One focusing on each of the popular RADIUS auth protocols PAP,CHAP,MSCHAP,EAP..etc centralizing some scattered information.

A second on popular backend databases SQL, password files, LDAP..etc...in the spirit of whatever common practices there are for managing accounts.

Finally security focused protocol criticisms such as use of MD5/secret key lengths/""Just use IPSec"" a security/mitigation section might be helpful.

  

 Cleanup 
Over the next few days, I will spend some time to cleanup this article.  I am planning on adding three figures.  One showing a block diagram of RADIUS in an enterprise where dialup, VPN and Wi-Fi all use the same RADIUS server, a typical protocol stack and a block diagram of a roaming scenario where there is a proxy RADIUS server communicating with a remote RADIUS server connected by a PKI tunnel.  I