2.5 Attributes and Values

Although at this point the attribute field in a RADIUS packet may seem like nothing more than a glorified way to determine header information, there's a lot more going on than meets the eye. Specifically , the entire RADIUS transaction is built around passing to and from the client and server attribute-value pairs (AVPs) that contain virtually every property and characteristic of the AAA transaction.

To enhance security, the RADIUS RFC restricts some attributes from being sent in certain packetsor to be more specific, the timing of certain packets. For instance, to prevent the password from ever crossing the wire more than once for one authentication/authorization process, the User -Password attribute is never allowed to be sent in a reply packet from the server to the client. Even more stringently, the RFC prevents some attributes from even being present in certain transactions, while others can appear more than once, and still others only once. More information on restrictions like these is presented in the sections that follow.

Attributes in a packet all follow a specific field format. From this point on, I'll refer to this field format as:

Attribute Number

This number denotes the type of attribute presented in the packet. The attribute's name is not passed in the packetjust the number. Generally , attribute numbers can range from 1-255, with one specific number serving as a "gateway" of sorts for vendors to provide their own specific attributes.

Attribute Length

This field describes the length of the attribute field, which must be three or greater. It behaves in much the same way as the length field of the RADIUS packet header.

Value

Containing the property or characteristic of the attribute itself, this field is required for each attribute presented, even if the value itself is null. The length of this will vary based on the inherent nature of the attribute itself.

The concepts of attributes and values themselves are worthy of a bit more discussion.

2.5.1 Attributes

Attributes simply describe a behavior or a property of a type of service. While most attributes are included to denote a particular setting for a service type, the presence of some attributes in the packet tells the RADIUS server what it needs to know. As you'll see later in this chapter, the very inclusion of the CHAP-Password attribute in a packet signals to the RADIUS server the proper hashings and password-concealing processes to perform for that particular transaction. This is a unique property of attributesthey can stand alone, while values simply cannot.

Attributes are transmitted inside the RADIUS packet in a predetermined, standard format, as shown in Figure 2-6.

Figure 2-6. The standard AVP transmission pattern

The AVP structure shown in Figure 2-6 consists of a continuous set of bytes containing at least three octets, with the first octet being the type, the second the length, and the final octet the value of the attribute itself.

The RADIUS server knows enough about an attribute that its official name need not be transmitted in the packet. The code number (the attribute number) is enough to deduce the kind of information being transmitted in that particular value. Note that while there is an official guide to all of the attribute names in the RFC, these aren't required, and some vendors may modify the diction of the names in their specific implementations .

2.5.1.1 Attribute types

The RADIUS implementation, according to the RFC, is designed to look for certain types of values in the value field of a particular attribute. For example, you wouldn't want random numbers in an attribute designed to pass a date, nor would you expect to have an IP address (consisting of numbers) in a random character string. To ease the confusion surrounding multiple attribute values being passed in one transaction, each attribute's corresponding value has been assigned a certain type. This simply describes what the value isa number, an IP address, a date, and so on. There are six types as outlined in the RFC:

Integer (INT)

Integer types are values that contain whole numbers, which are read "as they come." An attribute like Idle-Timeout might be set to the integer value of 15.

Enumerated (ENUM)

Data that is of the enumerated type consists of an integer, but the value is based on a user-configurable set of range values and meanings. You may encounter enumerated values called semantic integer values , whereas non-semantic integer values are simply integer types. There will be more information later in this chapter about ENUM values.

IP Address (IPADDR)

This data type is a 32-bit number designed to pass a correctly formed IP address. While RADIUS by default looks at an IP address at face value, some implementations can be configured to handle it with a preconfigured value, such as a particular subnet mask. Also, a recent extension to the RADIUS protocol allows IPv6 addresses to be used in this type. Much of the handling of this data type is left up to the implementation and operating environment.

Character String (STRING)

Character strings are generally defined to be UTF-8 printable strings that can be read at face value. The data is passed as a character array that can be bounded or unbounded, whichever is appropriate. The RADIUS RFC has specific notes regarding handling character arrays (particularly with printing issues) that are beyond the scope of this discussion.

Date (DATE)

The date type is a 32-bit unsigned number representing elapsed seconds since January 1, 1970.

Binary (BINARY)

Often peculiar to an implementation, binary values ("0" or "1") are read at face value.

The all-caps notations contained in the parentheses beside each term heading indicate the proper notational abbreviation for each of the attribute types.

2.5.1.2 Vendor-specific attributes

As with most of the RADIUS protocol, there is much flexibility for vendor-specific attribute types to come about in different implementations. Much of this is created to directly support special, non-standard or value-added features that some particular RADIUS client equipment is capable of provisioning. Of course, presumably because there in fact is a standard, some vendorsnotably US Robotics/3Comdo not follow the RFC specification.

As mentioned earlier in this chapter, the RADIUS protocol defines a particular AVP as a "gateway" AVP in which vendor-specific attributes, or VSAs, can be encapsulated. The VSA is carried in value payload of the standard AVP 26, called Vendor-Specific . Figure 2-7 shows the standard AVP and how the VSA information is carried within.

Figure 2-7. The passing of a VSA within a standard AVP

In Figure 2-7, the four standard parts of any VSA can be distinguished: the vendor ID, the vendor type, the length, and the value.

Vendor ID

This section of the VSA contains four octets that represent the VSA's developer/designer/owner. These standard codes are defined in the RFC 1700 document as "Assigned Numbers." More specifically, the individual vendors are coded with unique numbers called Network Management Private Enterprise Codes, or NMPECs.

The order of the vendor ID field contents is based on a stringent standard, with the highest-order byte of the four-octet value being set to zero, and then the last three bytes set to the NMPEC code as described previously. The whole lot is then converted into the portable byte format known as "network byte ordering." (A discussion of network byte ordering is beyond the scope of this chapter. A web search engine can turn up detailed information and history on this if you wish.)

Vendor type

The vendor type field, which is one octet in length, functionally behaves in much the same way as the attribute number in a standard AVP. Vendor types are values with a range between 1 and 255, and the significance and meaning of each of the values is known to the vendor-specific logic inside the RADIUS server.

Length

This field is a one-octet number that indicates the length of the entire VSA, with the minimum length of the entire VSA being seven. Again, the behavior of this field is similar to the length field in a standard, RFC-defined AVP.

Value

The value field is required to be at least one octet in length and contains data that is specific to the VSA itself. Most of these values are read, interpreted, and analyzed by RADIUS clients and servers on the receiving end that are aware of the special features and non-standard abilities that their particular implementations support.

2.5.2 Values

Recall that all attributes must have values, even if the value of the attribute is null. Values represent the information that each particular attribute was designed to convey . They carry the "meat" of the information. Values must conform to the attribute type rules outlined previously. Table 2-1 shows examples of each attribute type and the expected value field payload for each.

Table 2-1. Attribute types and value field payloads

Attribute type	Length (in octets)	Size/Range	Example payloads
Integer (INT)	4	32-bit unsigned	6 256 2432 65536
Enumerated (ENUM)	4	32-bit unsigned	3 = Callback-Login 4 = Callback-Framed 13 = Framed-Compression 26 = Vendor-Specific
String (STRING)	1-253	Variable	"Charlotte" "Raleigh" "206.229.254.2" "aslyterdesign.com"
IP Address (IPADDR)	4	32-bit	0xFFFFFE 0xC0A80102 0x1954FF8E 0x00000A
Date (DATE)	4	32-bit unsigned	0xC0A80102 0xFFFFFE 0x00000A 0x1954FF8E
Binary (BINARY)	1	1 bit	1

Each of these value properties is enumerated (pun intended) and explained in the RADIUS RFC.

2.5.3 Dictionaries

The RADIUS server machines must have a way of relating which attribute corresponds to which attribute number and expected type. It also must be aware of any vendor-specific attributes it must support to contact the RADIUS client equipment that is operating in the same environment. Much like a dictionary of the English language contains words, their word types (verb, noun, preposition, etc.), and their definitions, a RADIUS dictionary keeps track of the properties of all standard and the appropriate vendor-specific attributes.

The commonly found RADIUS flexibility is extended to the dictionary implementation. Dictionaries can be stored in flat text files, in databases, or by just about any other meansthe only constraint here is the accessibility of the information to the RADIUS server. While more exotic means of storing the file are not out of the question, experience shows that by far the two most common methods of storing the dictionary information are in text files and databases.

Here is an excerpt of a common flat text file dictionary:

 #  ATTRIBUTE-NAME                TYPE #-------------------------------------- 1  User-Name                     STRING 2  User-Password                 STRING 3  CHAP-Password                 STRING 4  NAS-IP-Address                IPADDR 5  NAS-Port                      INT 6  Service-Type                  ENUM 7  Framed-Protocol               ENUM 8  Framed-IP-Address            IPADDR 9  Framed-IP-Netmask            IPADDR 10 Framed-Routing                ENUM 

Earlier in this chapter, I said that RADIUS implementations have enough information so that the text name of each attribute doesn't need to be transmitted. Most dictionary files do include this information for the sake of the administratorit's difficult to edit a file based solely on numbers, and in the name of convenience, the full name is included. The full name is not transmitted in a packet.

Recall from the discussion of attribute types earlier that a special type of integer value, the enumerated (ENUM) type, is simply a set of integers whose values are of different significance based on the specific attribute. For instance, in the previous example, the Framed-Protocol attribute is of the enumerated type; thus, the RADIUS server will need to know the meanings of the different values the Framed-Protocol attribute will pass. Consider this next example, which shows the way a RADIUS server would account for the different meanings of the enumerated values for the Framed-Protocol attribute:

 # VALUE-MEANING                        FOR ATTRIBUTE #--------------------------------------------- 1 PPP                                  7 2 SLIP                                 7 3 AppleTalk Rem. Acc. Protocol (ARAP)  7 4 Gandalf SingleLink/MultiLink         7 5 Xylogics proprietary IPX/SLIP        7 6 X.75 Synchronous                     7 

Each RADIUS implementation may store information about any vendor-specific attributes in a dictionary as well. The format of a flat text file dictionary complete with vendor-specific attributes would look similar, except the vendor ID code (based from the NMPEC code) must be included as well.