RADIUS and Change of Authorization

[deanwebb]

https://tools.ietf.org/rfc/rfc2865.txt RADIUS
https://tools.ietf.org/rfc/rfc5176.txt Dynamic extensions to RADIUS

NAC and Wireless have a massive overlap with RADIUS and what it's used to do. Not only is it used to authenticate wireless uses, but it can also transfer users between SSIDs handled by different controllers. This means a remote office whose users are handled by one wireless controller for the business network can use an authentication with that controller to gain access to the guest network handled by a completely different controller in the DMZ.

First, though, RADIUS should be required reading. It's a vital protocol and the RFC for it is not boring reading. There's some funny stuff in there and some great explanations about why certain choices were made - and those explanations can help broaden understanding of other protocols, given that similar choices faced developers of those protocols. For example, on whether or not to use RADIUS keepalives, the RFC states:

Some implementers have adopted the practice of sending test RADIUS
   requests to see if a server is alive.  This practice is strongly
   discouraged, since it adds to load and harms scalability without
   providing any additional useful information.  Since a RADIUS request
   is contained in a single datagram, in the time it would take you to
   send a ping you could just send the RADIUS request, and getting a
   reply tells you that the RADIUS server is up.  If you do not have a
   RADIUS request to send, it does not matter if the server is up or
   not, because you are not using it.

   If you want to monitor your RADIUS server, use SNMP.  That's what
   SNMP is for.

I love that.

Anyway, I'm reading these RFCs not for any upcoming test, but because they're part of my job and I want to have a better understanding of what it is that I do. Here at networking-forums.com, we encourage everyone to have a passion like that for your work. What better way to encourage that passion than to lead by example, right? 

What do I get from these? Well, I have to look at packet captures to troubleshoot issues. The RFCs tell me what to expect in those captures and how to read them. If, for example, I can be at a point where I don't have to look up the difference between RADIUS Code 2 and Code 3, then I can provide much more rapid assessment of a capture.

In the RADIUS RFC, note 5.26 - the vendor-specific attribute (VSA). That's where the RFC gives free rein for vendors to do proprietary spooky magic, but does specify that devices that can't handle it MUST ignore it. This can be a big deal if your solution makes heavy use of VSAs, and can be used as a driving point by a certain vendor to use exclusively their gear.

5.27 - 5.29 are also important, as they define TCP-like properties for the UDP protocol.

I admit that I passed over stuff for AppleTalk and VAX connections. Such is my experience that those are rarely encountered, but if I need that info, I know where to look.

[deanwebb]

So on to the RFC 5176... That document deals with how RFC 2865 does not deal with a RADIUS server initiating contact with a switch or wireless controller. 2865 says pretty much the only entity allowed to initiate a RADIUS session is a client, when it is attaching to the network. 5176 allows for other ways to use RADIUS that are pretty cool.

One of these ways is the disconnect message. If, for whatever reason, a server is informed that a session should be terminated, it can contact the switch or WLC to cut off access. The other cool thing is the Change of Authorization or CoA: that message can move an endpoint between VLANs or SSIDs. This CoA is what can allow for some cool stuff with your guest wireless networks.

Note that the disconnect and CoA packets are NOT sent on the RADIUS port - UDP 1812 - but on a different port, UDP 3799. If your CoA solution isn't working but your RADIUS authentication is working, check intermediate devices (switches, routers, firewalls, IPS) to see if UDP 3799 is permitted along with UDP 1812.

It's also important to note that your RADIUS client, the switch or WLC, must support the RFC 5176 features or they will be rejected. Check with your vendor to see if their gear in question supports CoA and disconnect messages before you embark on using those features.