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 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:
This number denotes the type of attribute presented in the packet. The attribute’s name is not passed in the packet—just 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.