2.2 Packet Formats
| The RADIUS protocol uses UDP packets to pass transmissions between the client and server. The protocol communicates on port 1812, which is a change from the original RADIUS RFC document. The first revision specified that RADIUS communications were to take place on port 1645, but later this was found to conflict with the "Datametrics" service. RADIUS uses a predictable packet structure to communicate, which is shown in Figure 2-1. Figure 2-1. A depiction of the RADIUS data packet structure The data structure is broken down into five distinct regions , which are discussed later in this chapter. 2.2.1 CodeThe code region is one octet long and serves to distinguish the type of RADIUS message being sent in that packet. Packets with invalid code fields are thrown away without notification. Valid codes are:
2.2.2 IdentifierThe identifier region is one octet long and is used to perform threading, or the automated linking of initial requests and subsequent replies. RADIUS servers can generally intercept duplicate messages by examining such factors as the source IP address, the source UDP port, the time span between the suspect messages, and the identifier field. 2.2.3 LengthThe length region is two octets long and is used to specify how long a RADIUS message is. The value in this field is calculated by analyzing the code, identifier, length, authenticator, and attribute fields and finding their sum. The length field is checked when a RADIUS server receives a packet to ensure data integrity. Valid length values range between 20 and 4096. The RFC specification requires certain behaviors of RADIUS servers with regard to incorrect length data. If the RADIUS server receives a transmission with a message longer than the length field, it ignores all data past the end point designated in the length field. Conversely, if the server receives a shorter message than the length field reports , the server will discard the message. 2.2.4 AuthenticatorThe authenticator region, often 16 octets long, is the field in which the integrity of the message's payload is inspected and verified . In this field, the most important octet is transmitted before any otherthe value used to authenticate replies from the RADIUS server. This value is also used in the mechanism to conceal passwords. There are two specific types of authenticator values: the request and response values. Request authenticators are used with Authentication-Request and Accounting-Request packets. In the request value, the field is 16 octets long and is generated on a completely random basis so as to thwart any attacks. While RADIUS doesn't make a provision for protecting communication against wiretapping and packet capture, random values coupled with a strong password make attacking and snooping difficult. The response authenticator is used in Access-Accept , Access-Reject , and Access-Challenge packets. The value is calculated using a one-way MD5 hash generated from the values of the code, identifier, length, and request-authenticator regions of the packet header, followed by the packet payload and the shared secret. (I'll cover shared secrets in detail later in this chapter.) Example 2-1 shows an equation to represent how this hash is computed. Example 2-1. From RFC 2865, the MD5 hash for the response authenticator header fieldResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) |
