If you’re serious about security you know that you need a AAA server to carry out authentication, authorisation and maybe accounting functionality for users on your network. You’ll have set up a AAA server running either the RADIUS or TACACS+ protocol, set the server up with all your user ids and passwords - or pointed it at your Active Directory database - and you’re secure in the knowledge that you have a centralised, manageable system for authentication.
But you can do more with your server than just use it to store passwords. RADIUS was designed, if you remember the acronym, as a Remote Authentication Dial-In User Service (You’ll also see the A as being for Access in some documentation, (but the IETF RFC gives it as Authentication, and it should know). So being designed for dial, there are a lot more options to do with how a user should be connected and what sort of service they can get, that can be useful even if you don’t operate large banks of modems any more (or even if you do).
The functionality revolves round a set of attributes -parameters and their values - that are exchanged between RADIUS clients and servers. These are known as Attribute-Value (AV) Pairs. The RFC specifies 63 of them (including the accounting ones, which are actually detailed in RFC 2866), although more have been added in separate RFCs 2868 & 2869, which cover attributes specific to tunnel support and RADIUS extensions. The RFC also details the type of value that can be associated with each.
For example, the value for the User-Name attribute is any string, while the value for the Session-Timeout one must be an integer. The standard also details in what type of RADIUS packets the attributes are allowed to appear. If you ever have to troubleshoot a RADIUS setup, you’ll see that there are only four types of client-server exchanges: Access-Request, Access-Accept, Access-Reject and Access-Challenge. The first is issued by the client: all others are sent by the RADIUS server. So the Framed-IP-Address attribute may be found in an Access-Request packet, if the client is asking to use a specific address for this session, or an Access-Accept packet, where the server is specifying the IP address that this user must be given, but it’s not allowed for this attribute to appear in an Access-Reject or Access-Challenge packet, and packets should be dropped if attributes appear in the wrong packet type.
Each attribute has a number as well as a name - it’s the number that is actually sent in the packet, although in configuring RADIUS servers, it’s typically the more user-friendly name that is referred to.
In addition to IETF-specified attributes, the RFC allowed for vendors to create their own, for specific authentication and accounting settings for their own equipment. This is managed using attribute number 26 - any packet with this attribute ID will have another AV pair nested within it, that will mean something to the RADIUS client and server in use, although not every RADIUS implementation may understand it.
Examples of these Vendor Specific Attributes (VSAs) include the Bay-Primary-DNS-Server (the value is an IP address) for Nortel equipment, the Microsoft MS-MPPE-Encryption-Type (an integer) or Cisco’s CVPN3000-IPSec-Sec-Association (a string) - there are numerous more, and you’ll have to determine if your RADIUS server implementation supports the options that you might want to use for the RADIUS clients in your network.
Which brings us to what you can do with these attributes. ISPs will make extensive use of RADIUS attributes in DSL and cable service offerings, for instance, to connect users to the correct services, allocate IP addresses, reject connections if the bill’s not been paid, and of course carry out all the accounting functionality necessary to make their business pay.
In the corporate enterprise, too, you can use RADIUS to give you extra control and flexibility. RADIUS is supported on DSL routers, firewalls and VPN concentrators nowadays, not just the modems and access servers (NASs) of before. Remember that it’s usually these network devices that are your RADIUS clients, not the end users’ workstations.
Apart from the obvious attributes that let users enter usernames and passwords, and the RADIUS server allow connectivity, you can use RADIUS to define the connection protocol, put users in the correct VLAN, and set security options, for instance. There’s a new RFC-RFC2868: RADIUS Attributes for Tunnel Protocol Support - that’s been written specifically to cater for tunnel provisioning - among the new attributes included here is number 64:Tunnel-type. This attribute is a value that indicates the tunnelling protocol specified for a particular session (eg PPTP, L2TP, GRE, ESP).
You can use RADIUS to enumerate IPSec policies, H.323 configurations or rate-limiting of multicast traffic on a per-client basis, depending on the attributes you choose. It’s well worth having a look to see what your RADIUS implementation can offer over and above just checking for passwords.