RADIUS Dictionaries

Unlike text-based protocols such as SMTP or HTTP, RADIUS is a binary protocol; therefore, although attributes are commonly referred to by name (for example, "User-Name"), these names have no meaning in the protocol. Data (i.e., "User-Name") are encoded in a message as a binary header with binary data, and not as text strings.

Dictionary files are used to map between the names used by people and the binary data in the RADIUS packets. FreeRADIUS ships with over 100 dictionaries, totalling nearly 5000 attribute definitions. These dictionaries are used to simplify the configuration of the server and to allow easy extensibility without source code compilation.

The packets sent by the NAS contain attributes that have a number, a length, and binary data. By contrast, a dictionary file consists of a list of entries with name, number, and data type.

The server uses the dictionaries to interpret the binary data as follows: the server searches the dictionaries to match the number from the packet, and the corresponding data type in the dictionary entry is then used by the server to interpret the binary data in the packet. The name within the dictionary entry appears in all logs and debug messages, in order to present the attribute in a form that is understandable to people.

This process also works in reverse: the server uses the dictionaries to encode a string (i.e., "User-Name = Bob") as "number, length, binary data" in a packet.

For example, a server may receive a packet that contains the number 1 and some binary data. The server would not be able to decode these attributes without knowing if the binary data were in the form of a string, an IP address, or an integer. The corresponding dictionary entry may state: the number '1' is called 'User-Name' and it is in the data type 'string'. This information which is contained in the dictionary entry allows the server to successfully decode the packet into a form usable by policies and administrators.

Adding new attributes to RADIUS software is made simpler through the use of dictionaries, as they allow the administrator to create new mappings without upgrading the software.

Vendors can define new attributes in the dictionary without changing any of the server or client source code. These new attributes can then be incorporated in policy decisions or logged in an accounting record.Vendors can also define new functionality for their equipment by publishing a new dictionary file. Server support for an NAS can easily be added by writing the correct dictionary file for that NAS.

Note that there is no direct connection between the NAS and the dictionary files, as the dictionary files reside only on the server. For example, if names are edited in a local dictionary file, there is no effect on any other NAS or RADIUS server, because these names appear only in the local dictionary file. The RADIUS packets remain in binary format and contain only numbers, not names.

Note that the NAS and server may use different dictionaries, which may cause problems if they are not coordinated (a set of data may be interpreted differently by the NAS and the server, i.e., as a string by the NAS and an IP address by the server)

Since the attribute names are not sent in RADIUS packets, the dictionaries are limited to the local server and to the policy implemented by that server.

In this respect, NAS implementations are much simpler than server implementations. Each NAS "looks" in the RADIUS packet for what it "understands" and ignores everything else. In contrast, each RADIUS server is presented with all of the information from every NAS in the RADIUS deployment. Each RADIUS server must be capable of "understanding" the functionality and configure-ability of every attribute that is necessary to authenticate or authorize the users.