| [ Team LiB ] |
|
2.5 Attributes and ValuesAlthough 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 packets—or 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:
The concepts of attributes and values themselves are worthy of a bit more discussion. 2.5.1 AttributesAttributes 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 attributes—they 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 typesThe 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 is—a number, an IP address, a date, and so on. There are six types as outlined in the RFC:
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 attributesAs 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 vendors—notably US Robotics/3Com—do 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.
2.5.2 ValuesRecall 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.
Each of these value properties is enumerated (pun intended) and explained in the RADIUS RFC. 2.5.3 DictionariesThe 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 means—the 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
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.  |
| [ Team LiB ] |
|
