2.3 Packet Types
| Access-Request |
| Packet Type | Response |
| Code | 1 |
| Identifier | Unique per request |
| Length | Header length plus all additional attribute data |
| Authenticator | Request |
| Attribute Data | 2 or more |
The Access-Request packet is used by the service consumer when it is requesting a particular service from a network. The client sends a Request packet to the RADIUS server with a list of the requested services. The key factor in this transmission is the code field in the packet header: it must be set to 1, the unique value of the Request packet. The RFC states that replies must be sent to all valid Request packets, whether the reply is an authorization or a rejection .
The payload of the Access-Request packet should include the username attribute to identify the person attempting to gain access to the network resource. The payload is required to contain the IP address or canonical name of the network equipment from which it is requesting service. It also has to contain a user password, a CHAP-based password, or a state identifier, but not both types of passwords. The user password must be hashed using MD5.
How do these rules apply to RADIUS proxy chains? Basically, new packets need to be created whenever attributes are changed, since identifying information is changed. Attributes with shared secrets, which are covered in detail later in this chapter, need to be reversed by the proxy server (to obtain the original payload information) and then encrypted again with the secret that the proxy server shares with the remote server.
The Access-Request packet structure is shown in Figure 2-2.
Figure 2-2. A typical Access-Request packet
| Access-Accept |
| Packet Type | Response |
| Code | 2 |
| Identifier | Identical to Access-Request per transaction |
| Length | Header length plus all additional attribute data |
| Authenticator | Response |
| Attribute Data | 0 or more |
The Access-Accept packets are sent by the RADIUS server to the client to acknowledge that the client's request is granted. If all of the requests in the Access-Request payload are acceptable, then the RADIUS server must set the response packet's code field to 2. The client, upon receiving the accept packet, matches it up with the response packet by using the identifier field. Packets not following this standard are discarded.
Of course, to ensure that the request and accept packets are matched upthat is to say, to make sure the accept response is sent in reply to the respective request packetthe identifier field in the Access-Accept packet header must contain an identical value to that of the Access-Request field.
The Access-Accept packet can contain as much or as little attribute information as it needs to include. Most likely the attribute information in this packet will describe the types of services that have been authenticated and authorized so that the client can then set itself up to use those services. However, if no attribute information is included, the client assumes that the services it requested are the ones granted.
The Access-Accept packet structure is shown in Figure 2-3.
Figure 2-3. A typical Access-Accept packet
| Access-Reject |
| Packet Type | Response |
| Code | 3 |
| Identifier | Identical to Access-Request |
| Length | Header length plus all additional attribute data |
| Authenticator | Response |
| Attribute Data | 0 or more |
The RADIUS server is required to send an Access-Reject packet back to the client if it must deny any of the services requested in the Access-Request packet. The denial can be based on system policies, insufficient privileges, or any other criteriathis is largely a function of the individual implementation. The Access-Reject can be sent at any time during a session, which makes them ideal for enforcing connection time limits. However, not all equipment supports receiving the Access-Reject during a pre-established connection.
The payload for this packet type is limited to two specific attributes: the Reply-Message and Proxy-State attributes. While these attributes can appear more than once inside the payload of the packet, apart from any vendor-specific attributes, no other attributes are allowed, under the RFC specification, to be included in the packet. (Vendor-specific attributes are covered in detail both later in this chapter and throughout the remainder of the book.)
The Access-Reject packet structure is shown in Figure 2-4.
Figure 2-4. A typical Access-Reject packet
| Access-Challenge |
| Packet Type | Response |
| Code | 11 |
| Identifier | Identical to Access-Request |
| Length | Header length plus all additional attribute data |
| Authenticator | Response |
| Attribute Data | 0 or more |
If a server receives conflicting information from a user, requires more information, or simply wishes to decrease the risk of a fraudulent authentication, it can issue an Access-Challenge packet to the client. The client, upon receipt of the Access-Challenge packet, must then issue a new Access-Request with the appropriate information included.
It should be noted that some clients don't support the challenge/response process like this; in that case, the client treats the Access-Challenge packet as an Access-Reject packet. Some clients, however, do support challenging, and at that point a message can be given to the user at the client requesting the additional authentication informationit's not necessary in that situation to set off another round of request/response packets.
Much like the Access-Reject packet, there are only two standard attributes that can be included in an Access-Challenge packet: the State and Reply-Message attributes. Any necessary vendor-specific attributes can be included as well. The Reply-Message attribute can be included in the packet multiple times, but the State attribute is limited to a single instance. The State attribute is copied unchanged into the Access-Request that is returned to the challenging server.
The Access-Challenge packet structure is shown in Figure 2-5.
Figure 2-5. A typical Access-Challenge packet
