RADIUS Attributes

Many RADIUS users have come to know the habits of vendors to invent new ways to represent their information in RADIUS packets, even when perfectly suitable encapsulation mechanisms already exist. Sadly, RFC 2865 doesn't require the contents of the RADIUS vendor- specific attribute (attribute 26) to contain the same fields as normal attributes have to specify their attribute ID and length. This has led to varieties like 2- and 4-octet attribute numbers, length specifications that don't include the attribute- and length fields, multiple vendor attributes inside one encapsulating attribute 26, etc. Luckily, ClearBox Server can receive and send all these types of attributes.

Attribute Values

The value of each RADIUS attribute has a well-defined data type.

ClearBox Server distinguishes five basic value types that may be a numer (possibly with a list of named possible values), byte string, text string, IP or IPX address, date/time.
For example, Callback-Number is of string type and contains a telephone number. NAS-Port-Type is an integer item from a list, and may be 'Sync', 'Async', and so forth.

Some attributes may have Tag field to provide a means of grouping attributes in the same packet. These attributes have F_TAGGED flag set.

Further information on this page is about RADIUS authorization.

Multi-valued Attributes

Attributes may be single- or multi-valued; in other words, certain attributes may appear at most once in the RequestMatch list or Response list, while others may appear multiple times. (Read about RequestMatch lists and Response lists.)

If an attribute appears more than once in the RequestMatch list, this means that any of the values is valid. For example, server extension (external module ClearBox Server uses to process packets) may set up the RequestMatch list to include both Sync and Async values for attribute NAS-Port-Type. This means that the user can dial into a Sync port or an Async port, but not into one of the ISDN ports.

If an attribute appears more than once in the Response list, this results in each value of the attribute being sent as part of the response packet. For example, to enable both IP and IPX header compression for a user, the Framed-Compression attribute should appear twice in the Response list; once with the value 'VJ-TCP-IP-header-compression' and once with the value 'IPX-header-compression'.

Orderable Attributes

Certain multi-valued Response list attributes are also orderable; that is, the attribute may appear more than once in a RADIUS response, and the order in which the attributes appear is important.

For example, the Reply-Message attribute allows text messages to be sent back to the user for display. A multi-line message is sent by including this attribute multiple times in the Response list, with each line of the message in its proper sequence.

The Echo Property

Using the Echo property, which is done via applying F_ECHO flag to a RADIUS attribute, server extension can force an attribute from the RADIUS request to be echoed in the RADIUS response.
Suppose, for example, server extension adds Callback-Number to the Response list and sets F_ECHO for this attribute. ClearBox Server will take the value of the Callback-Number it receives in the RADIUS request and echo it back to the client in the RADIUS response; if it receives no Callback-Number, it echoes nothing.
Let us further suppose that server extension puts Callback-Number one or more times into the RequestMatch list. This indicates that one of the callback numbers supplied must be present in the RADIUS request, and that number should be echoed in the RADIUS response.

Default Values

By applying F_DEFAULT flag for any RequestMatch list attribute, server extension may indicate that if the RADIUS request does not include this attribute, the request should not be rejected. Instead, the value supplied as the default should be used as if it were received as part of the request.

One use for default values is to require that an attribute in a RADIUS request must have one of several values, or must not be present at all.

Another use would be to provide a default value for an attribute in conjunction with the echo property (F_ECHO flag) in the Response list. If an attribute appears once in the RequestMatch list marked as default, and the same attribute appears in the Response list marked as echo, this means the following:

• If the attribute does appear in the RADIUS request, the server will echo it in the RADIUS response.
• If the attribute does not appear in the RADIUS request, the server will echo the default value (from the RequestMatch list) in the response.

Note that if server extension adds multiple values of the same attribute to the RequestMatch list, only one of them can have F_DEFAULT flag set.

Suppose, for example, server extension adds several Callback-Number values to the RequestMatch list and marks one of them as default. Also, server extension adds Callback-Number to the Response list and marks it as echo. Here's what happens: If a Callback-Number is present in the RADIUS request, it must match one of the RequestMatch list values or the user will be rejected. If it matches, the user is accepted and the value supplied is echoed in the RADIUS response. If no Callback-Number is supplied in the request, the user is accepted and the default value is echoed in the response. Other RequestMatch list attributes are used to provide configuration for the user, such as time-of-day and concurrent-login-limit information.

List of RADIUS Attributes

List of standard RADIUS attributes can be found here.