3.1 Attribute Properties

Each attribute in this chapter is presented as a separate "nugget" of information. Each nugget contains a quick-reference chart for the particulars of the attribute, followed by a discussion of the attribute, where I discuss any special considerations in the usage or configuration of the attribute, how its use affects or requires other attributes, practical applications of the attribute, and how it sometimes differs from the theoretical implication from the RFC.

Appendix A contains a chart with all of the global standard RADIUS attributes (including those specific to accounting) and their numbers, lengths, values, and packet presence requirements. Chapter 9 presents the attributes introduced and revised in the new RADIUS Extensions RFCs. I have separated these attributes to maintain the distinction exhibited in the RFCs.

Attribute Number	20
Length	3 or more octets
Value	STRING
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute is used when a RADIUS implementation is set up to return a user's call. This is commonly used in corporate situations to avoid long-distance charges in hotel rooms and other remote locations. This value, a STRING, is often the identifier for a profile configured on the service equipment; there is no specific standard for a string name, a triggered action, or something else. In other words, it is environment-specific. RADIUS client gear is allowed to reject a connection if this attribute is present but not supported by that gear.

Attribute Number	19
Length	3 or more octets
Value	STRING
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

The value of this attribute is the number to which the RADIUS client gear should return a call to the authenticating user. Depending on what packet this attribute is found in, different actions may be configured. For instance, if Callback-Number is found in an Access-Request packet, the implementation may assume that the end user is requesting callback service. If the attribute is found in the Access-Accept packet, it can mean anything that the administrator configuring the gear wants it to mean. In fact, in some cases, Callback-ID and Callback-Number will not be found together in one packet.

Coupled with the Callback-ID attribute, this attribute is one of several RADIUS security measures. In addition to being more convenient and cost-effective for companies with employees in hotels needing access to corporate IT resources, the callback mechanism is also a security device. The implementation could be configured to call a certain number when a certain username requests access. This way, if a hacker is located somewhere other than where the genuine user normally connects from, the hacker would not be able to authenticate.

Attribute Number	30
Length	3 or more octets
Value	STRING
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

The value in this packet can tell the NAS gear what number the user dialed to gain access to its service. Using the Dialed Number Identification Service (DNIS), the NAS gear may use this data to authenticate based on location (if each point of presence in various locations has a different number). Also, the Called-Station-ID can be used to identify which RADIUS proxy server forwarded the request. Using this attribute in that manner is called "numbered-realm proxying."

Outside of standard dial-up Internet access, the Called-Station-ID attribute can be used in other applications. For example, in the publicly available wireless access industry, typically you will find the MAC address of the access point to which the wireless card is connected in this field, with the octets separated by hyphens. While this is certainly not a prescribed standard by any RFC, this is a best practice.

Attribute Number	31
Length	3 or more octets
Value	STRING
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute, in effect, is the NAS gear's Caller ID function. The value in this attribute carries the number of the calling party inside an Access-Request packet. This can be used both for convenience and security purposes. For instance, different access-control lists can be created, only allowing callers from certain places to be authenticated. As well, a regional POP could be managed and limited by only allowing callers from certain area codes and exchanges. This attribute could also be used in conjunction with a callback service. Much of the configuration of what the NAS gear does with the Calling-Station-ID attribute is environment specific; there is no standard manner to handle the attribute.

Attribute Number	60
Length	7 or more octets
Value	STRING
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

If a CHAP transaction is involved—in other words, if CHAP responses are requested from or required by the RADIUS client—then the original CHAP challenge is placed in the value field of this attribute. The CHAP request is then sent to another server, which attempts to authenticate the request based on the CHAP-Challenge value. Normally, these values are around 16 bytes, which allows the RADIUS client the option of using the value in this attribute as the request authenticator. The large allowable size of the value makes the attribute secure enough to allow this.

Attribute Number	3
Length	19
Value	STRING
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Required, unless User-Password is present
Maximum Iterations	1

CHAP-Password indicates to the RADIUS client gear that CHAP, instead of PAP, is going to be used for the transaction.

Of particular interest regarding CHAP-Password is the structure of the attribute, which is different than most of the other attributes. The CHAP-Password attribute is structured much like the vendor-specific AVP passed within the standard Vendor-Specific attribute, number 26. This abnormal structure is due to the additional data collected in a CHAP transaction that needs to be passed between the two parties. Let's take a closer look.

The CHAP identifier, a one-octet value that the RADIUS client gear assigned, is placed in the first octet of the attribute's value field. The response, effectively the CHAP password, completes the rest of the value field.

The RADIUS RFC requires that the User-Password and the CHAP-Password attributes be mutually exclusive, but one or the other is required in any transaction at all times.

How does the CHAP-Password attribute affect the RADIUS transaction? The sequence is this: a dial-up client connects to an ISP's NAS gear, which in turn issues a CHAP ID and sends it back to the client. The client generates a response to this challenge and places the response in the password section of the value field. The entire lot is then returned to the NAS gear. The NAS gear is relatively flexible in dealing with the challenge: if the challenge generated at the client side is 16 octets, it can be placed in the request authenticator or in the challenge section of the value field.

In either case, once the NAS gear receives the CHAP ID and CHAP password back from the client, it uses a hash computed from information in the Access-Request packet combined with the user's recorded password to construct a CHAP-Response, which is then compared with the information provided in this attribute. Matches result in a successful authentication; mismatches trigger an Access-Reject packet.

Attribute Number	25
Length	3 or more octets
Value	STRING
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	Unlimited

The Class attribute mainly exists to funnel identification and property information to the accounting systems of RADIUS implementations. The RFC mandates that the Class attribute is completely and totally vendor and implementation specific, and also dictates that the RADIUS client not even attempt to act on or interpret the information stored within that attribute.

While the value of this attribute is a string, the RFC dictates that the gear treat the value of that string is a contiguous set of data, or a set of "undistinguished octets." That is to say, the RADIUS client must not expect any boundaries or spaces in the data.

Effectively, this attribute mainly groups and "classifies" connection information. Accounting data is often used to predict demand, determine load, and plan for the future. Although categorized information may be of no use at the present, when the only concern is authenticating, it may prove useful down the road to accounting users.

Attribute Number	11
Length	3 or more octets
Value	STRING
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	Unlimited

Filter-ID is arguably one of the most pragmatic, useful attributes in the RADIUS specification. Filter-ID is based upon the common practice of packet filtering, the use of which is most often found in firewalls and intrusion detection systems. The premise behind packet filtering is to inspect each and every packet in a transaction or data stream in order to determine, based on rules that an administrator configures, whether those packets should be allowed to pass through.

In RADIUS, however, that use is not as distinct. The most parallel example of packet inspection as a security device is when you view the RADIUS client gear as a gateway. Indeed, the RADIUS client is the first hop on the packet's destination to the Internet, and the client can filter based on rules to conclude whether to allow the packet to pass. But in RADIUS, packet filtering examines rules that an administrator configures, known as "filter profiles," which act as guides to what packets can do what actions on what network. Let's take a closer look.

Let's assume that a certain RADIUS implementation has three filter profiles configured: a "Mailonly" profile, a "FullInet" profile, and a "LocalSurf" profile. These profiles correspond to several account types that a local ISP offers: one for families who simply want email service without the ability to surf the Web, one for those who wish to have a full complement of Internet services, and another for those who enjoy accessing the ISP's local resources: a news server, an about-town page, and perhaps technical support sites.

The profiles feature of RADIUS allows each RADIUS client to store profile information that defines and enforces restrictions on a session. So it is feasible for the ISP to create the Mailonly profile that allows a connection bound to that profile to surf only to the IP of the mail server, only on ports 25 and 110. Similarly, the LocalSurf profile would allow connections only to the IP subnet leased to the ISP.

It's important to note that all RADIUS gear, whether acting as a client or a server, must be configured correctly and consistently for filter profiles to work. Depending on the RADIUS client equipment, if a non-existent or incorrectly configured filter is referenced, the NAS could drop the call, allow no traffic, or allow all traffic. This is obviously not what you, the administrator, desire, as otherwise you wouldn't be configuring a filter!

The RADIUS client looks in the Access-Accept packet to determine whether a filter profile should be applied to the connection.

Attribute Number	37
Length	6
Value	INTEGER
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

RADIUS supports a session in which the client computer acts as an AppleTalk router. The Framed-AppleTalk-Link attribute identifies that circumstance to the RADIUS client gear on the far side of the connection. If the value of this attribute is greater than zero, then the value is treated as an AppleTalk network number.

The RFC mandates that this attribute not be used when the client is not acting as an AppleTalk router. This attribute is also exclusive of the Framed-AppleTalk-Network attribute: if both are present in the Access-Accept packet, the connection will be unreliable, and the RADIUS client gear is free to disconnect and/or reject the call.

Attribute Number	38
Length	6
Value	INTEGER
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	Unlimited

If the dial-up user needs AppleTalk access and is not including the Framed-AppleTalk-Link attribute (thus indicating his desire to act as an AppleTalk router), then the RADIUS client gear will retrieve an AppleTalk network number for the connection from the network that is reflected in the Framed-AppleTalk-Network attribute. If the attribute has a zero value, it is an indication that the client wishes to be assigned an AppleTalk network number by the RADIUS client gear.

The RADIUS RFC permits multiple instances of the Framed-AppleTalk-Network attribute to be included in one Access-Accept packet to allow for redundancy and fail-over should the desired network be unavailable or unwilling to grant access.

Attribute Number	39
Length	3 or more octets
Value	STRING
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute indicates the appropriate AppleTalk zone for the connection. Much like the Class attribute, the value in this attribute is a STRING and is therefore read by the RADIUS client as a string of "undistinguished octets."

Attribute Number	13
Length	6
Value	ENUM
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	Unlimited

This attribute states the intent for and type of compression to be used over the connection. The value is of the enumerated type and can range from 0 to 3. Table 3-1 lists the corresponding values and compression types allowed for this attribute.

Table 3-1. Appropriate framed-compression values

Value	Associated compression type
0	None
1	Van-Jacobsen-Header-Compression
2	IPX-Header-Compression
3	Stac-LZS-Compression

For IP-based connections, the Van-Jacobsen compression algorithm is used. For all other connection protocols, the value listed in this attribute determines the compression to be used.

The RADIUS RFC permits multiple instances of the Framed-Compression attribute in the Access-Request and Access-Accept packets; if this is the case, then it is the client gear's responsibility to determine the compression method best suited for that particular connection. It is important to note that if the compression-type value received in a packet is not supported by the RADIUS client gear, it is not under any obligation per the RFCs to honor that request.

Attribute Number	8
Length	6
Value	IPADDR
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

In link-framed connections using such protocols as SLIP and PPP, the Framed-IP-Address attribute carries, quite obviously, the value of the IP address to be assigned to the connection. Depending on the origin of the Access-Request packet, the attribute has the following different meanings:

From the RADIUS client

The value of this attribute indicates the client's preference in IP address. The RADIUS server does not have to assign this address, although it may do so.

From the server to the client

The RADIUS server will assign the IP found in this attribute to the connection.

There are exceptions to that rule, however. There are two specific IP values reserved for use by RADIUS. The address 255.255.255.255 is used when the client computer negotiates for the IP it uses—this may be when the user has an assigned static IP address and needs to communicate directly with the IP provisioning equipment in order to get this address. The address 255.255.255.254 is used when the RADIUS client issues the IP address.

Attribute Number	9
Length	6
Value	IPADDR
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute is used when the connection needs a specific netmask number. Even though a client-based DHCP server often assigns netmasks to connections, in certain cases when groups of IP addresses aggregated by CIDR are distributed by the RADIUS server, specific netmasks may be necessary.

While this attribute can appear within an Access-Request packet, the server is not required to honor it, although it may do so.

Attribute Number	23
Length	6
Value	INTEGER
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute assigns IPX network numbers. If there is a value in each octet other than 255, then that value represents the IPX network number that should be used. If each octet is 255, then the RADIUS client should choose a number and pass it back to the client.

Attribute Number	12
Length	6
Value	INTEGER
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute allows the RADIUS server to set the connection's maximum transfer unit (MTU) size to align communications with the way an administrator has configured his network equipment. Briefly, the MTU setting is the largest packet size that can be transmitted over a connection. If the packet size is larger than this value, then the packet is broken up by routers along the path to the destination and then reassembled at the end point.

The RADIUS server will expect the value of this attribute to be somewhere between 64 and 65,535. Most clients or servers will send this attribute, containing a default MTU size of 1,500, inside an Access-Accept packet.

It's important to note that only implementations that strictly support RFC 2138 prohibit the Framed-MTU attribute from being passed in Access-Request. The new RADIUS draft supports this, but some implementations may not have been upgraded to support this change.

Attribute Number	7
Length	6
Value	ENUM
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute signals what type of protocol to use over a link-frame connection. The server treats this attribute as a hint if received inside an Access-Request packet and a required condition if received in an Access-Accept packet. The value of this attribute can range from 1 to 6; Table 3-2 lists the values and their corresponding link protocols.

Table 3-2. Framed-protocol attribute values

Value	Link protocol
1	PPP
2	SLIP
3	ARAP
4	Gandalf SLP/MLP
5	Xylogics IPX/SIP
6	X.75 Synchronous

This attribute should be used when the Service-Type attribute is set to Framed.

Attribute Number	22
Length	3 or more octets
Value	STRING
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	Unlimited

The Framed-Route attribute is used to carry string values corresponding to information to set up a client routing table. The information contained in the STRING-format value is very similar to the information contained in the Windows netstat program. Here is a sample output from netstat -rn run on a Windows 2000 Professional machine for reference:

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 50 56 c0 00 08 ...... VMware Virtual Ethernet Adapter
0x3 ...00 50 56 c0 00 01 ...... VMware Virtual Ethernet Adapter
0x1000005 ...00 a0 cc 60 b6 6d ...... NETGEAR FA310TX Fast Ethernet PCI Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.1.10   192.168.1.100  1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1  1
      192.168.1.0    255.255.255.0    192.168.1.100   192.168.1.100  1
    192.168.1.100  255.255.255.255        127.0.0.1       127.0.0.1  1
    192.168.1.255  255.255.255.255    192.168.1.100   192.168.1.100  1
    192.168.208.0    255.255.255.0    192.168.208.1   192.168.208.1  1
    192.168.208.1  255.255.255.255        127.0.0.1       127.0.0.1  1
  192.168.208.255  255.255.255.255    192.168.208.1   192.168.208.1  1
    192.168.209.0    255.255.255.0    192.168.209.1   192.168.209.1  1
    192.168.209.1  255.255.255.255        127.0.0.1       127.0.0.1  1
  192.168.209.255  255.255.255.255    192.168.209.1   192.168.209.1  1
        224.0.0.0        224.0.0.0    192.168.1.100   192.168.1.100  1
        224.0.0.0        224.0.0.0    192.168.208.1   192.168.208.1  1
        224.0.0.0        224.0.0.0    192.168.209.1   192.168.209.1  1
  255.255.255.255  255.255.255.255    192.168.208.1   192.168.208.1  1
Default Gateway:      192.168.1.10
===========================================================================
Persistent Routes:
  None
Route Table

The information in the attribute value must include a destination address, a gateway address, and relevant (but optional) metrics. The RFC suggests that each routing entry be masked in standard CIDR notation. For example, the format for a standard entry would be:

<n.n.n.n>/<nn> <n.n.n.n>/<nn> [<metrics>]

So an entry directing hosts 192.168.2.0 through 192.168.3.0 to a gateway router at 192.168.10.5 would be:

192.168.2.0/23 192.168.10.5/32 1

There are several other ways in which this value can be carried and interpreted:

• If some network devices don't support CIDR notation, then the /nn representation can signal the number of bits (8, 16, or 24) to use instead of classful routing. If this is not present, the RADIUS client will resort to the traditional routing of an 8-bit class A address, a 16-bit class B address, or a 24-bit class C address.

• The gateway address can be assigned to the client's interface by passing 0.0.0.0 as the gateway routing entry in this attribute.

• RADIUS implementations are mandated by the RFC to support multiple instances of this attribute inside an Access-Accept packet. Primarily, support for multiple iterations allows custom routing tables to be built for a client, but the applications are not limited to that.

Attribute Number	10
Length	6
Value	ENUM
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

The routing policies of the client connections are set using the value of this attribute. In some cases, clients may act as routers, passing packets to computers and/or connections other than themselves. In these circumstances, the RADIUS client will need to be able to listen to the broadcasts this client router sends out about its route paths. The values in this attribute, ranging from 0 to 3 and described in Table 3-3, depict the broadcast behaviors for the connection in question.

Table 3-3. Framed-routing attribute values

Value	Broadcast policy
0	None
1	Broadcast routing tables and notifications
2	Listen for routing notification broadcasts
3	Broadcast and listen for notifications

The RFC does not require or recommend a specific routing policy protocol, such as router information protocol (RIP) or open-shortest-path-first (OSPF), nor does it designate specific routing announcements to be broadcast or ignored. In other words, the doors are wide open.

Attribute Number	28
Length	6
Value	ENUM
Allowed in	Access-Accept, Access-Challenge
Prohibited in	Access-Request, Access-Reject
Presence in Packet	Not required
Maximum Iterations	1

An administrator may configure the Idle-Timeout attribute so that the client gear or RADIUS server disconnects a session after a predetermined period of inactivity. The value in this attribute, four-octets long, is the maximum number of seconds a connection may remain active yet idle.

The Idle-Timeout attribute was a good idea for its time. Unfortunately, an administrator must be wary of many small software applications that exist today that are designed to defeat this mechanism. The software ranges in complexity from simple to—wait for it—complex. The lower end of the software simply pings a random server at steady intervals (usually every minute), while the upper end uses sophisticated algorithms to generate traffic more regular yet unpredictable than a ping.

Attribute Number	36
Length	34
Value	STRING
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

The LAT protocol uses a form of authentication based on a bit pattern known as the "group code," and this RADIUS attribute allows the group code to be carried inside Access-Request and Access-Accept packets. Much like other attributes that can be found inside both the Request and Accept packets, its presence inside the Request packet is simply a hint, while its presence in the Accept packet is definite.

If this attribute is present, then the Login-Service attribute must also be present.

RADIUS and Local Area Transport These attributes are specific to RADIUS's support of the Local Area Transport (LAT) protocol, originally developed by Digital Equipment for use of networks consisting of VAX equipment. LAT is unique because it allows the client to create a virtual terminal connection by using asynchronous connections across some type of LAN. LAT has some specific characters and operators that it recognizes inside a packet, so the RADIUS RFC has created a special string data type called LAT STRING, which distinguishes some characters, $, -, ., _, and most of the characters in the ISO Latin-1 set. Further, these strings must be case sensitive.

Attribute Number	35
Length	3 or more octets
Value	STRING
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute and its corresponding value indicate the LAT node to which a client should be connected. If this attribute is present in an Access-Accept packet, the Login-Service must also be present.

The Login-LAT-Node attribute operates under the LAT STRING modifications to the RADIUS RFC, and modern implementations should support distinguishing the characters inside the value.

Attribute Number	63
Length	4 octets
Value	ENUM
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

The Login-LAT-Port attribute designates the port to which the client should be connected. Like the other LAT-related attributes, this one must be accompanied by the Login-Service attribute inside an Access-Accept packet to indicate that LAT service is indeed desired.

This attribute also operates under the LAT STRING specification in the RADIUS RFC, meaning some characters inside the string value should be distinguished by the RADIUS implementation.

Attribute Number	34
Length	3 or more octets
Value	STRING
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

There are often other auxiliary services associated with LAT service, and this attribute provides a means for access to those services to be granted to the client. The Login-Service attribute must be included in the same packet and specify the LAT service.

Some LAT services are offered on other machines and may require more information to authenticate, or they may need access to other machines to provision the service. The Login family of standard RADIUS attributes may be used for this purpose in conjunction with the standard LAT attribute family.

This attribute also operates under the LAT STRING specification in the RADIUS RFC, meaning some characters inside the string value should be distinguished by the RADIUS implementation.

Attribute Number	14
Length	6
Value	IPADDR
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	Unlimited

This value carries the IP address of the host that provides the login service for a specific connection. Most commonly this IP address is the address of the actual host, but there are two reserved values that specialize the RADIUS client's behavior. If a value of 255.255.255.255 (0xFFFFFFFF) is placed in this attribute, then the client needs to assign this host IP itself. If a value of 0.0.0.0 (0x00000000) is placed in this attribute, then the client user should determine and configure this IP address for his connection.

Multiple instances of this packet may be present. The RFC doesn't specify what behavior the RADIUS client should present when it encounters this, but an educated guess would be to allow a selection of host IP addresses for redundancy, fault tolerance, and load balancing.

Attribute Number	15
Length	6
Value	ENUM
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This value specifies the type of service granted to the client. This attribute is intended for use in situations where plain terminal dial-up (i.e., to a shell account) is used. The attribute is exclusive from other framed protocol services. There are eight possible enumerated values for this attribute, which are listed in Table 3-4.

Table 3-4. Login-service attribute values

Value	Login service type
0	Telnet
1	Rlogin
2	TCP Clear
3	PortMaster (Lucent/Livingston)
4	LAT
5	X25-PAD
6	X25-T3POS
7	TCP Clear Quiet

A few of these services deserve further mention.

The standard services that are found most commonly in practice are the Telnet (0) and Rlogin (1) services. Both function to create a connection between the client and the remote host with the RADIUS client acting as a sort of proxy to each party. Most often these services are used to connect users to a Unix shell account or some other terminal service. TCP Clear (2) and TCP Clear Quiet (7) open a direct stream of TCP connectivity between the client and a remote host (the Quiet option simply suppresses announcements from the RADIUS client). The PortMaster (3) service is a proprietary service that connects the user to Livingston (now Lucent) NAS equipment. Finally, the LAT service (4) is used with the Login-LAT family of standard RADIUS attributes.

Attribute Number	16
Length	6
Value	INTEGER
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Required, unless NAS-IP-Address is present
Maximum Iterations	1

This attribute specifies the remote port used to connect the client to the login service given by the Login-Service attribute. The range of values allowed for this attribute are between 0 and 65,535, though the standard ports below 1,024 are considered privileged and usually require an administrator to configure the service to listen on those ports.

In transactions involving a proxy server, this value can become mangled.

Attribute Number	32
Length	3 or more octets
Value	STRING
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Required, unless NAS-IP-Address is present
Maximum Iterations	1

This attribute identifies the NAS that constructed the Access-Request packet. Most often, the fully qualified domain name (FQDN) is used in the value portion of this attribute (for instance, local-nas3.raleigh.corp.hasselltech.net), although the RFC states that the value must be treated as a series of undistinguished octets. The FQDN is often used to eliminate duplicate NAS identifiers and reduce confusion for the client.

This attribute is often vendor specific and each implementation may have customized the use and behavior of this attribute. Additionally, in transactions involving a proxy server, this value can become mangled.

Attribute Number	4
Length	6
Value	IPADDR
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Required, unless NAS-Identifier is present
Maximum Iterations	1

This attribute specifies the IP address of the NAS gear that requests service on behalf of the client computer. Each implementation may customize the use and behavior of this attribute, but the RADIUS RFC does not permit both this attribute and the NAS-Identifier attribute to be used in the same packet. However, one of the two must be present in any packet.

Attribute Number	5
Length	6
Value	INTEGER
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Required, unless NAS-Port-Type is present
Maximum Iterations	1

The value in this attribute represents the port to which the client user is connected. It is important to note that this value is not the socket port which might identify the protocol the client is using; this value represents the actual, tangible, physical port on the NAS gear to which the client has connected.

The information passed in this value can be useful for identifying load problems or debugging connection problems, either in the NAS itself or possibly in the hunt group connected to that NAS. Most NAS vendors include special software to configure how this information is supplied and most also include special software that will generate algorithms based on the slot number of the NAS, the specific modem, and the NAS port that show call center distribution and other statistical gems.

This attribute can co-exist with the NAS-Port-Type attribute. One of the two attributes, though, must always be present in a packet.

Attribute Number	61
Length	6
Value	ENUM
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Required, unless NAS-Port is present
Maximum Iterations	1

The enumerated value in this attribute depicts what kind of NAS port to which the user has connected. There are 20 physical port types, which are listed in Table 3-5.

Table 3-5. NAS-Port-Type attribute values

Value	Type of port
0	Asynchronous
1	Synchronous
2	ISDN Synchronous
3	ISDN Asynchronous V.120
4	ISDN Asynchronous V.110
5	Virtual
6	PIAFS
7	HDLC Clear Channel
8	X.25
9	X.75
10	G.3 Fax
11	SDSL
12	ADSL-CAP
13	ADSL-DMT
14	IDSL
15	Ethernet
16	XDSL
17	Cable
18	Wireless other
19	Wireless CCITT 802.11

This list of ports covers almost all of the types that would be used in practice. For clarification, I'll discuss a few of the different options that are more commonly found in everyday use:

Asynchronous connections (0)

The most common type of port used for dial-up clients.

Synchronous (2) connections

ISDN clients most often use this connection, but they may also use two flavors of asynchronous (3 and 4) connections as well.

PIAFS (6), or PHS Internet Access Forum Standard

A protocol used primarily in Japan to allow access to devices such as digital cameras, connection concentrators, cellular and mobile telephones, and other handy devices.

Symmetric DSL (11), asymmetric DSL (12 and 13), and DSL over ISDN (14)

Are offered for DSL types.

802.11b protocol (19)

Most often used for wireless connections.

Attribute Number	62
Length	6
Value	INTEGER
Allowed in	Access-Accept, Access-Request
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

The value of this attribute dictates the upper limit on the number of ports that NAS is authorized to give to the client. In practice, the use of this packet is most often found in support for bonding channels together with ISDN or for multilink point-to-point (MLPPP) protocol, which allows a user to aggregate two modems and phone lines into one IP channel.

There are a couple of caveats to the implementation of the Port-Limit attribute. The problem lies squarely in the fact that the enforcement of this attribute is done at the NAS machine, not at the RADIUS server. In implementations where there is more than one NAS machine, the effective port-limit would be the number of NAS machines present multiplied by the value in Port-Limit. Realistically, some sort of mechanism is needed to keep track of active logins over the entire network lest the efficacy of the Port-Limit attribute be reduced to zero. This exemplifies the need for some sort of third-party session management software, especially in large, distributed networks.

Attribute Number	33
Length	3 or more octets
Value	STRING
Allowed in	All
Prohibited in	None
Presence in Packet	Not required
Maximum Iterations	Unlimited

This attribute is used when a RADIUS server acts as a proxy and needs to save information about an outstanding request, such as IP addresses, domain names, or other unique integer identifiers. There are a couple of rules to use this attribute, as specified by the RFC:

• If the Proxy-State attribute is found in an Access-Request packet, the information must be included unmodified in the response to the packet, whether the packet is accepted, challenged, or rejected.

• Since multiple instances of this attribute are allowed inside a packet, the order in which they are presented is relevant. When the values of the State attribute are copied, they must be copied in the order in which they were included in the original packet.

It should be noted that some RADIUS client equipment does not follow the RFC specification for the Proxy-State attribute, and this can result in the mangling of any data included in the AVP.

Attribute Number	18
Length	3 or more octets
Value	STRING
Allowed in	Access-Accept, Access-Reject, Access-Challenge
Prohibited in	Access-Request
Presence in Packet	Not required
Maximum Iterations	Unlimited

This value is used to provide a message to the client in response to another packet. It is often found in Access-Accept messages to provide a welcome message, an error message, or other information to the user.

It is not prudent for an administrator to bet on the end user seeing whatever message is sent in the Reply-Message attribute. Specific consumer/client software may ignore the attribute or present its own notification to the user based on the packet in which this attribute is found.

Attribute Number	6
Length	6
Value	ENUM
Allowed in	Access-Accept, Access-Request
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute describes the type of network service that is offered by the RADIUS client gear to the service consumer. The value, a four-octet enumerated integer, works in conjunction with other attributes present in the Access-Request and Access-Accept packets to define and further qualify an offered service. There are 11 specific values appropriate for this attribute, which are listed in Table 3-6.

Table 3-6. Service-Type attribute values

Value	Service type
1	Login
2	Framed
3	Callback Login
4	Callback Framed
5	Outbound
6	Administrative
7	NAS Prompt
8	Authenticate Only
9	Callback NAS Prompt
10	Call Check
11	Callback Administrative

In the following section, I'll step through each of these predefined service types and discuss their functions within the client transaction.

Login

This value allows the user to have terminal login service. Several standard attributes can be used to further define and enhance the service offered to the user, and these values as well as authentication can be passed using an automated dial-up client rather than sitting at a virtual terminal screen.

Framed

This value indicates that the connection will use a frame protocol such as PPP or SLIP, and each of these protocols will likely require further definition and configuration using additional standard RADIUS attributes. The Framed-* family of attributes defines the IP address, netmask number, MTU, routing, and compression options for a framed connection.

Callback Login

This value indicates the current session will be dropped and the network equipment will call the user back. Apart from that difference, the service is identical to the standard Login (1) service.

Callback Framed

This value directs the RADIUS client to use a frame-based connection upon calling back the client. Apart from that difference, the service is identical to the standard Framed (2) service.

Outbound

Some network service providers may include access to lines available to place outbound calls, and this attribute indicates that the user should be allowed to use those outbound circuits.

Administrative

This value indicates to the RADIUS client that the user should be given administrator rights over its configuration. Some vendors have specific procedures for administrative logins, including entering the administrative user into a special, enhanced, command environment, a root shell on a NAS machine, or simply modifying their privileges so that access to configuration is permitted and then treating the user as a standard client.

NAS Prompt

This value directs the NAS to prompt the user for a login and password directly to the NAS, which may offer the user a way to execute special commands and configurations normal clients would not have.

Authenticate Only

Some implementations may store service information and user password and authentication information on different servers. When a client dials in, sometimes all that is needed is a signal of authentication: no services need to be allowed for or provisioned, and this value directs the RADIUS server to simply perform the authentication without any extra overhead. This value would most likely be found in practice in a proxy configuration, in which the authorizing server may not have access to the equipment being provisioned. In this case, the proxy would pass just the authentication information to the authorizing server without any service detail. Upon authenticating, the authorizing server would simply pass the Access-Accept back to the proxy, and the proxy then inserts the relevant service information.

Callback NAS Prompt

This value indicates that the NAS should call the user back and then prompt him for a login and password to access the NAS machine proper. Apart from that difference, this service is identical to the NAS Prompt (7) service.

Call Check

In basic terms, the Call Check value allows an administrator to configure his implementation so that authentication takes place before calls are negotiated on the NAS equipment. Let's take a look at this in more detail.

The typical sequence of events in a RADIUS transaction follows a pattern: the user dials the NAS equipment, the NAS equipment answers and the modem negotiation (the ever-present "screeching") follows, and finally, the server receives the access requests and either accepts or rejects them. The Call Check value allows some slight yet effective modifications to this sequence.

Say, for instance, a user is in a hotel, which charges for telephone use by the minute. On top of that, the user will incur long-distance charges. It is desirable in these circumstances to allow a call to fail as soon as possible if it is indeed known the call will be rejected. An administrator can configure his RADIUS implementation so that the Access-Request packets are sent before the modem negotiations are finished. If the call will fail, the modems are disconnected, and the user has not had to wait for the negotiation procedures to finish for him to find out his call is rejected. This can save a lot of money on connection charges and, arguably more importantly, it doesn't waste the client's time.

The implementation of this feature depends a great deal on which vendor manufacturers the NAS and RADIUS server, but two keys to check for are the Service-Type attribute being set to Call Check (8), and the User-Name attribute being the distinguished name or the called station identifier.

Callback Administrative

This value indicates that the NAS should drop the immediate connection and call the user back with the connection set up so that the called-back user has administrative privileges of the NAS machine itself. Apart from that difference, this service is identical to the Administrative (6) service.

Attribute Number	27
Length	6
Value	INTEGER
Allowed in	Access-Accept, Access-Challenge
Prohibited in	Access-Request, Access-Reject
Presence in Packet	Not required
Maximum Iterations	1

This attribute indicates the maximum length of time in seconds that a user may remain connected to the network before the RADIUS client will kick him off. This is primarily used to enforce connect-time limits on certain account package types or to prevent camping on a line. (Camping is when a user treats a non-dedicated connection, such as a dial-up account, as a dedicated connection by keeping the line up 24 hours a day, 7 days a week.)

Much like the Idle-Timeout attribute, there are many software packages meant for the client side that detect a disconnected session and immediately reconnect it. There is no inherent mechanism on the RADIUS server, at least as specified in the RFC, to prevent usage of this software, since the Session-Timeout value is just a counter that is stateless and memory-less. It can be and is reset each time a new connection is made.

Attribute Number	24
Length	3 or more octets
Value	STRING
Allowed in	Access-Accept, Access-Request, Access-Challenge
Prohibited in	Access-Reject
Presence in Packet	Not required
Maximum Iterations	1

The State attribute, valid over an entire connection session, is an implementation-specific attribute that can be used for a variety of purposes. For example, in a proxy implementation, some session information may need to be saved and accessed to expedite authentication or provide services for inherently stateless connections.

The State attribute is part of a group of interchangeable yet singly required attributes: at all times one of the User-Password, CHAP-Password, or State attributes must be present in a packet. How the RADIUS client behaves when it sees a State attribute depends on the type of packet in which the attribute is found.

• If the State attribute is found in an Access-Accept packet, then the RADIUS client must include the value of the attribute in any new Access-Request packets. For this to work properly, the value of the Terminate-Action attribute must also be set to RADIUS-Request. (See the next attribute for more information on Terminate-Action.)

• If the State attribute is found in an Access-Challenge packet, then the value of the State attribute must be included, unmodified, in the Access-Request packet sent in response to the challenge. It is NOT permitted for the RADIUS client to interpret the value of State, and no operation of the core protocol may be affected by the value of State.

Attribute Number	29
Length	6
Value	ENUM
Allowed in	Access-Accept
Prohibited in	Access-Request, Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute passes a value that dictates the behavior that the RADIUS client gear should portray upon terminating a client's connection. There are two possible values for this attribute, neither of which are required to be supported by the RADIUS server (but the lack of support of these values cannot affect the standard operation of the core RADIUS protocol): a 0, to indicate the server should perform its default termination action; and a 1, to indicate the client desires to have the RADIUS client send new Access-Request packets upon a session's completion.

Attribute Number	1
Length	3 or more octets
Value	STRING
Allowed in	Access-Request, Access-Accept
Prohibited in	Access-Reject, Access-Challenge
Presence in Packet	Not required
Maximum Iterations	1

This attribute carries the distinguished name of the client requesting access to services on the network. Since usernames come in all sizes and flavors, there is not a specified maximum length for this value. It has been recommended by the RADIUS committee and those who follow its proceedings that support for a larger username space be provided (up to 64 bytes in length) to allow the implementation-specific RADIUS client gear to perform its own compliancy and validity checking. This allows each administrator to customize the requirements for a valid username without having a standard dictate to them how usernames are constructed.

There are no specific requirements for the format in which these usernames must be represented, but there are a number of possible ways in which usernames are commonly passed in the User-Name attribute. Monolithic, or alphanumeric, passwords consist of all letters and numbers. UTF-8 characters are also supported. Additionally, usernames can be passed that conform to the Network Access Identifier (NAI) ASN.1 format—this is often known as the "distinguished name"—or some other format common to both the client and the RADIUS implementation. Because of this flexibility, administrators have a wide realm of possibilities for creating username standards.

RADIUS servers may also use a username to determine appropriate behavior for a transaction. For instance, if a username is passed in realm format (i.e., WEST/aslyter), then the RADIUS server may change its configuration to act as a proxy for that transaction, forwarding the request to an appropriate server within the WEST realm. Of course, the username can be ignored and simply passed, in which the RADIUS server acts like a transparent proxy and simply hands the requests on without filtering or preprocessing.

Attribute Number	2
Length	18 to 130 octets
Value	STRING
Allowed in	Access-Request
Prohibited in	Access-Accept, Access-Reject, Access-Challenge
Presence in Packet	Required, unless CHAP-Password is present
Maximum Iterations	1

This attribute is designed to carry authentication information that a user provides in order to gain access to network services. Primarily, the content of this value will be an encrypted password, but sometimes it can be the response from an Access-Challenge packet sent to the client from the RADIUS server. Most commonly, the length of the value is 16 octets, which is the RFC minimum, but the RFC also permits the value of this attribute to span as long as 130 octets.

As mentioned in Chapter 1 and Chapter 2, the presence of the User-Password attribute typically indicates that the given transaction will use PAP authentication in lieu of CHAP. Refer to Chapter 2 for an explanation of the hiding and encrypting process used in PAP authentication.

Attribute Number	26
Length	7 or more octets
Value	STRING
Allowed in	Access-Accept, Access-Request, Access-Challenge
Prohibited in	Access-Reject
Presence in Packet	Not required
Maximum Iterations	Unlimited

This attribute is used to carry attributes that are not specified in the RADIUS RFC. Vendors, NAS manufacturers, and others may want to transmit various implementation-specific information to the client and server and, thus, need a way to pass that information. However, this vendor information passed in addition to the standard global attributes absolutely cannot affect the operation of the base RADIUS protocol in any way. In Chapter 2, I discussed the format of a vendor-specific AVP and how one is carried inside this attribute.

Of particular interest is the type of this attribute. It is listed as a STRING type, but effectively it is seen as a pattern of undistinguished octets—this is to ensure the parts of the implementation that are not aware of the vendor-specific values do not misconfigure themselves or otherwise do detriment to the connection. Further, the value of the VSA within the vendor-specific AVP actually has several specification fields—think of them as "microfields" that further qualify the VSA. This eliminates any confusion and conflict between attributes specific to a vendor's implementation and attributes generally available per the RADIUS RFC.