RADIUS and Internet Authentication Service

Overview

Internet service providers (ISPs) and other larger organizations have the challenge of managing all types of network access and network accounting from a single point of administration, regardless of the type of network access equipment used.

RFC 2865 and RFC 2866 define the Remote Authentication Dial-In User Service (RADIUS) protocol. The RADIUS protocol carries authentication, authorization, configuration, and accounting information between a network access server (NAS) or any other similar device that needs to authenticate, authorize, and account for the usage of the device, and shared authentication and accounting servers.

RADIUS clients communicate with a RADIUS server over User Datagram Protocol (UDP) ports 1812 and 1813, although earlier versions of RADIUS used UDP ports 1645 and 1646. RADIUS is not supported over TCP.

RADIUS and IAS Server in Windows Server 2003

With RADIUS, a device such as a NAS can be configured to authenticate and authorize a user of its services through the use of the RADIUS protocol. An ISP, for example, needs to authenticate the user of a dial-in network port and then ensure that this user is authorized to use the port. The NAS might also need to get configuration information for this connection, which the RADIUS server can be configured to provide. Once a connection has commenced, the NAS device might need to provide accounting information that can be used for charge-back purposes. These RADIUS access control and accounting functions are shown in Figure 20-1.

Figure 20-1: Overview of RADIUS.

To support more complex networking architectures, you can deploy a RADIUS proxy, which receives RADIUS information from a RADIUS client and relays it to a RADIUS server. RADIUS server responses are sent to the client via the RADIUS proxy. The RADIUS proxy functions are shown in Figure 20-2. Note that both authorization and accounting information can be transferred using a RADIUS proxy.

Figure 20-2: The RADIUS proxy functions.

In the Microsoft Windows Server 2003 family, the Internet Authentication Service (IAS) implements an RFC-compliant RADIUS server and proxy. In Microsoft Windows 2000, IAS only implements the RADIUS server features. In addition, Windows Server 2003 servers running the Routing and Remote Access service can be configured to be aRADIUS client, enabling dial-in or virtual private network (VPN) clients to be authenticated using a RADIUS server.

The RADIUS server component of IAS can authenticate RADIUS client requests against a local account database, a Windows NT 4.0 domain, or Active Desktop. IAS savesRADIUS accounting details, provided by the RADIUS client, to either a text file or a Structured Query Language (SQL) database. The RADIUS proxy feature in IAS can forward both authentication and accounting messages to other RADIUS servers. IAS fully supports the Internet Engineering Task Force (IETF) standards for RADIUS described in RFCs 2865 and 2866. You can configure an IAS server to handle authentication (including authorization), accounting, or both, and you can configure your RADIUS clients or RADIUS proxies to use additional servers for fault tolerance.

IAS has access to user account information held either on the IAS server or from adomain controller (if the IAS server is a member of a domain). This enables the IAS server to check network access authentication credentials and dial-in properties of accounts and, as appropriate, authorize and configure the connection. If configured, a RADIUS client can also log details of the connection for accounting purposes.

Access and accounting transactions between client and server are authenticatedand secured through the use of a shared secret. This shared secret is never sent on the wire but is used in conjunction with the Authenticator field to provide a level of security over the RADIUS message. If additional security is required, the RADIUS server and client could use IPSec to encrypt RADIUS messages, although this is outside the scope of the RADIUS protocol.

RADIUS in Operation

The operation of RADIUS uses a simple client/server protocol, both for authorization and for accounting. The client sends information, encapsulated in UDP, to a server, which then responds as appropriate. There are some differences, however, as described in the following sections.

RADIUS Authentication

When a NAS or other device needs to authenticate and authorize a connection prior to allowing the connection to complete, the device must first obtain the user details with which to perform the authentication and authorization. The credentials for authorization can be obtained from a logon dialog box, where the user would enter a user name and a password, or by use of a link framing protocol, for example, Point-to-Point Protocol (PPP), which can carry authentication credentials from the client.

Once the NAS device has obtained the necessary authentication information, it constructs an Access-Request message and sends it to the RADIUS server. The Access-Request message contains one or more attributes, information that enables the RADIUS server to authorize the use of the NAS and to return certain configuration details for the connection. This information, contained within RADIUS message attributes, includes the user's name, password (which is encrypted), and a RADIUS client port identifier.

After sending the Access-Request message to the server, the RADIUS client waits for a response. If no response is received within a certain amount of time, the RADIUS client retransmits it. A RADIUS client can additionally be configured with the address of multiple RADIUS servers and should the first configured server fail, the client can use a different server. This provides fault tolerance and delivers a measure of load balancing. RFC 2865 suggests that the alternate server can be used either after a number of tries to the primary server fail or using a round-robin scheme. The retry and fallback algorithms are not specified in RFC 2865 and are, at present, vendor-specific.

After the RADIUS server receives the Access-Request, it first validates the RADIUS client. An Access-Request message that is received from a RADIUS client for which the server is not configured is silently discarded. If the Access-Request message came from a valid RADIUS client, the server can then validate the connection and return an Access-Accept or Access-Reject message, based on the success or failure of the validation. The validation of a connection typically includes password verification, but can also be based on other information included in the Access-Request message, such as the NAS port that the connection request was received on or the type of connection.

When the RADIUS server returns an Access-Accept message, the server can return additional configuration information, specified as additional attributes. These can be generic RADIUS attributes or vendor-specific attributes used to configure a particular vendor's NAS (or other) device.

If the RADIUS server is unable to authenticate and authorize the connection, it sends an Access-Reject message back to the client saying that the connection request has failed. The client could then re-request user identity details or simply fail the initial servicerequest. The RADIUS server can include a text message in the Access-Reject message.

RADIUS Accounting

The purpose of RADIUS accounting is to provide details of the resources used by the connections to a NAS to a central accounting server. RADIUS accounting is defined in RFC 2866.

Each service that the RADIUS client provides to an end user constitutes a session. The session begins when the service is first provided and completed when the service is ended. A NAS device, for example, provides a session for a dial-in user that begins once the authentication and authorization has been successfully negotiated and ends when the service ceases to be provided. An end user could have multiple parallel sessions active at the same time, for example using multilink remote access services with Integrated Services Digital Network (ISDN). The RADIUS accounting information can then be used for chargeback or for general usage analysis.

If a RADIUS client is configured to use RADIUS accounting, then it generates an Accounting Start message at the beginning of each session and an Accounting Stop message at the end. The Accounting Start message is used to describe the type of service being provided and to identify the user of the service. The Accounting Stop message contains usage statistics such as the total session time, the number of packets sent and received, and the number of octets sent and received.

The RADIUS server acknowledges receipt of the Accounting Start and Accounting Stop messages by sending the RADIUS accounting client an Accounting-Response message, which tells the accounting client that the Accounting-Request message has been received by the RADIUS accounting server. Unlike the Access-Accept message, an Accounting-Response message does not normally contain attributes.

If a RADIUS accounting server is unable to record the information in the Accounting messages, it does not send a response. If, for whatever reason, the client does notreceive an Accounting Response message, the client retransmits the message at regular intervals until it receives an Accounting-Response message or a configured timeout period is reached. The RADIUS accounting client can also be configured to use additional servers to provide load balancing and fault tolerance.

RADIUS Proxy

A RADIUS proxy is a RADIUS server that can relay access and accounting messagesfrom a RADIUS client to another RADIUS server, as previously illustrated in Figure 20-2. The RADIUS proxy forwards the request to a remote RADIUS server, receives the reply from the remote server, and sends that reply to the RADIUS client. A RADIUS proxy can be used to support dial-in user roaming. Roaming enables the user of one ISP to access another ISP's network. The RADIUS server at the called ISP can use a RADIUS proxy to forward the connection request to a RADIUS server at the user's home ISP. With roaming, a user can access multiple ISPs simultaneously, while maintaining a business client relationship with a single ISP. This can be highly useful for "road warriors" who need Internet access around the globe.

With RADIUS proxy, the NAS sends the RADIUS Access-Request message to the RADIUS proxy, which then forwards it to the target RADIUS server (for example, the user's home ISP). The target RADIUS server can then send appropriate responses (for example,Access-Accept, Access-Reject, and Accounting-Response messages) to the RADIUSproxy, which then sends the response to the NAS.

When a RADIUS proxy sends a message from a RADIUS client to a RADIUS server, it adds an additional attribute into the message, Proxy-State, which informs the server that the RADIUS message was received from a proxy and not from the RADIUS client. When the server sends a response back to the RADIUS proxy, this attribute is copied, unmodified, into the response. The RADIUS proxy removes this attribute when sending the response back to a client.

A server can function as both a RADIUS proxy and a RADIUS server, enabling the server to proxy some requests to a remote RADIUS server and process others locally. In addition, it is possible to have multiple proxies, as shown in Figure 20-3. If multiple proxies exist, each proxy server adds an additional Proxy-State attribute to the RADIUS message when it is passed toward the RADIUS server and removes this when responses are sent back to the original RADIUS client.

Figure 20-3: Multiple RADIUS proxies.

RADIUS Attributes

RADIUS clients and servers communicate by sending messages to each other. The specific message type is defined in the message header. The details of each message are contained as a set of three fields: type, length, and value 3-tuples. Each 3-tuple is collectively known as an attribute. An attribute's type and length fields have a fixed length, whereas the variable-length value field has its length indicated in the length field. An attribute represents a specific data item, such as a user name or the tunneling protocol in use, sent between the RADIUS client and server. RADIUS messages consist of a header followed by a variable number of attributes, where each attribute can be of a variable length. The structure of attribute fields is shown later in this chapter.

Two types of RADIUS attributes are contained in RADIUS messages: standard attributes and vendor-specific attributes. Standard attributes are defined in RFCs 2865 through 2869 and are used by all RADIUS clients and servers. Vendor-specific attributes are proprietary. Not all RADIUS clients and servers implement all vendor attributes.

Vendor-specific attributes are identified with a vendor attribute, which includes the vendor's enterprise number and a vendor attribute ID. The assigned enterprise numbers were originally defined in RFC 1700, but to avoid regular reissues of this RFC, vendor IDs are now specified at http://www.iana.org/assignments/enterprise-numbers. Forexample, Microsoft's enterprise ID is 0x137 (311 in decimal format). Microsoft-specific vendor extensions have been submitted for RFC status in RFC 2548, although this RFC documents earlier versions of RADIUS; extra attributes have been added in Window Server 2003 that are not described in RFC 2548.

If a RADIUS server cannot make use of a vendor-specific attribute, it is ignored. The RADIUS server can create log entries regarding the ignored attribute, but this is notrequired. If a RADIUS client receives a vendor-specific attribute that is not supported, the client should attempt to work without the information, although doing so could result in degraded service to the end user.

RADIUS in Windows Server 2003

The Windows Server 2003 family of products implements RADIUS client, server, and proxy functions. The Windows Server 2003 Routing and Remote Access service can be configured to be a RADIUS client, enabling authentication of dial-in and VPN clients against a RADIUS server. The IAS service in Windows Server 2003 provides both RADIUS server and proxy facilities.

RADIUS Authentication in Routing and Remote Access

The Routing and Remote Access service in Windows Server 2003 can be configured to perform authentication using RADIUS. When configured this way, the Routing and Remote Access service obtains the necessary user credentials through several PPP configurable authentication protocols and can then pass these details to the RADIUS server, along with other connection connection attributes.

The Routing and Remote Access service can also be configured to send authentication and accounting messages to multiple RADIUS servers. Microsoft's Routing and RemoteAccess service uses a proprietary scoring method to determine the RADIUS server to which RADIUS messages should be sent. In this scheme, the Routing and Remote Access service maintains a quality rating, known as the score, for each configured RADIUS server. It then uses the scores to determine the best RADIUS server to use at any given moment.

The scoring method used by Routing and Remote Access works as follows:

• The client initially assigns each configured RADIUS server a default value of 30.
• Each time a RADIUS message is sent to a RADIUS server and no response is received, the score decreases by 3, to a minimum of 0.
• Each time a RADIUS message is sent to a RADIUS server and a response isreceived, the server's score is increased by 1, to a maximum of 30.
• Routing and Remote Access service sends RADIUS messages to the RADIUS server that has the highest score.
• If only one RADIUS server is configured, or if all servers are nonresponsive, Routing and Remote Access retransmits the RADIUS message every 5 seconds.

The administrator can configure Windows Server 2003 Routing and Remote Access service either to require no authentication or to authenticate the end user of a dial-in or VPN connection using the following protocols:

• Password Authentication Protocol (PAP), which sends passwords unencrypted between the access client and the NAS
• Shiva Password Authentication Protocol (SPAP)
• Challenge Handshake Authentication Protocol (CHAP)
• Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
• Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), which provides mutual authentication
• Extensible Authentication Protocol (EAP), which supports authentication using an MD5 challenge, smart card, or certificate

The specific attributes transmitted by Routing and Remote Access service to the RADIUS server are based on the particular authentication protocol being used. You can see the attributes being exchanged in the following Network Monitor trace (Capture 20-01 in the Captures folder on the companion CD-ROM). The following trace illustrates the Access-Request and Access-Accept messages sent between a Routing and Remote Access server and a Windows Server 2003 RADIUS server:

Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src
Other Addr Dst Other Addr Type Other Addr
1 6.479317 005056404FAB 0050DABA49EE RADIUS Message Type: Access
Request(1) 10.10.1.150 10.10.1.201 
+ IP: ID = 0x78A2; Proto = UDP; Len: 277
+ UDP: Src Port: Unknown, (3065); Dst Port: Unknown (1812); Length = 257
(0x101)
 RADIUS: Message Type: Access Request(1)
 RADIUS: Message Type = Access Request
 RADIUS: Identifier = 12 (0xC)
 RADIUS: Length = 249 (0xF9)
 RADIUS: Authenticator = DB 60 44 6A 2B 19 83 57 FF 75 F1 1D 19 2C 1A 7F
 + RADIUS: Attribute Type: NAS IP Address(4)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: NAS Port(5)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: NAS Port Type(61)
 + RADIUS: Attribute Type: Tunnel Type(64)
 + RADIUS: Attribute Type: Tunnel Media Type(65)
 + RADIUS: Attribute Type: Calling Station ID(31)
 + RADIUS: Attribute Type: Tunnel Client Endpoint(66)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: User Name(1)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
******************************************************************************
Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src 
Other Addr Dst Other Addr Type Other Addr
2 6.549418 0050DABA49EE 005056404FAB RADIUS Message Type: Access
Accept(2) 10.10.1.201 10.10.1.150 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x9ABF; Proto = UDP; Len: 242
+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (3065); Length = 222 
(0xDE)
 RADIUS: Message Type: Access Accept(2)
 RADIUS: Message Type = Access Accept
 RADIUS: Identifier = 12 (0xC)
 RADIUS: Length = 214 (0xD6)
 RADIUS: Authenticator = 5F C7 93 40 22 EA 31 7A A3 4F 82 B1 FA DE 15 77
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Class(25)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)

As noted in this trace, the Routing and Remote Access service sends both standard and vendor attributes in the Access-Request message and receives a combination in theAccess-Accept message. The specific attributes sent by Routing and Remote Access service are based on the specific method used for authentication (the preceding example was based on a connection using PAP).

The following trace (part of Capture 20-02 in the Captures folder on the companionCD-ROM) illustrates an Access-Reject message being returned to the RADIUS clientdenying the attempted connection:

Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src
Other Addr Dst Other Addr Type Other Addr 
1 22.001636 005056404FAB 0050DABA49EE RADIUS Message Type: Access 
Request(1) 10.10.1.150 10.10.1.201 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x72D9; Proto = UDP; Len: 277
+ UDP: Src Port: Unknown, (2938); Dst Port: Unknown (1812); Length = 257
(0x101)
 RADIUS: Message Type: Access Request(1)
 RADIUS: Message Type = Access Request
 RADIUS: Identifier = 7 (0x7)
 RADIUS: Length = 249 (0xF9)
 RADIUS: Authenticator = 96 54 C5 23 F6 5E 17 1E C3 0D 07 7A 17 7C 40 77
 + RADIUS: Attribute Type: NAS IP Address(4)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: NAS Port(5)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: NAS Port Type(61)
 + RADIUS: Attribute Type: Tunnel Type(64)
 + RADIUS: Attribute Type: Tunnel Media Type(65)
 + RADIUS: Attribute Type: Calling Station ID(31)
 + RADIUS: Attribute Type: Tunnel Client Endpoint(66)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: User Name(1)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
********************************************************************************
2 22.011651 0050DABA49EE 005056404FAB RADIUS Message Type: Access Reject 
(3) 10.10.1.201 10.10.1.150 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x2EA; Proto = UDP; Len: 70
+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (2938); Length = 50 (0x32)
 RADIUS: Message Type: Access Reject(3)
 RADIUS: Message Type = Access Reject
 RADIUS: Identifier = 7 (0x7)
 RADIUS: Length = 42 (0x2A)
 RADIUS: Authenticator = 14 BF A3 62 F1 6C 88 42 19 A8 8C 3F 4F 83 7F 4C
 + RADIUS: Attribute Type: Vendor Specific(26)

RADIUS Accounting in Windows Server 2003

The Routing and Remote Access service can be configured to send accounting messages to a RADIUS server independently of how user authentication and authorization are performed; the Routing and Remote Access service can be configured to use Windows for authentication and authorization and use RADIUS for accounting. The start and stop of each session, for accounting purposes, is indicated by an Accounting-Request message: the value of the Acct-Status-Type attribute defines if the accounting request is for the start or stop of a connection.

The following trace (Capture 20-03 in the Captures folder on the companion CD-ROM) shows the messages exchanged at the start and end of a VPN connection. Routing andRemote Access service transmits an accounting request message when the VPN connection is created and another message when the VPN connection is dropped:

Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src
Other Addr Dst Other Addr Type Other Addr
1 10.314832 005056404FAB 0050DABA49EE RADIUS Message Type: Accounting
Request(4) 10.10.1.150 10.10.1.201 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x78B3; Proto = UDP; Len: 303
+ UDP: Src Port: Unknown, (3066); Dst Port: Unknown (1813); Length = 283
 (0x11B)
 RADIUS: Message Type: Accounting Request(4)
 RADIUS: Message Type = Accounting Request
 RADIUS: Identifier = 3 (0x3)
 RADIUS: Length = 275 (0x113)
 RADIUS: Authenticator = EA BB 33 E2 85 8D F8 D5 A6 5C 40 76 54 73 49 09
 + RADIUS: Attribute Type: Acct Status Type(40)
 + RADIUS: Attribute Type: Acct Delay Time(41)
 + RADIUS: Attribute Type: NAS IP Address(4)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: NAS Port(5)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: NAS Port Type(61)
 + RADIUS: Attribute Type: Tunnel Type(64)
 + RADIUS: Attribute Type: Tunnel Media Type(65)
 + RADIUS: Attribute Type: Calling Station ID(31)
 + RADIUS: Attribute Type: Tunnel Client Endpoint(66)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Class(25)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Acct Session ID(44)
 + RADIUS: Attribute Type: User Name(1)
 + RADIUS: Attribute Type: Framed IP Address(8)
 + RADIUS: Attribute Type: Framed MTU(12)
 + RADIUS: Attribute Type: Acct Multi-Session ID(50)
 + RADIUS: Attribute Type: Acct Link Count(51)
 + RADIUS: Attribute Type: Unknown(55)
 + RADIUS: Attribute Type: Acct Authentic(45)
 + RADIUS: Attribute Type: Vendor Specific(26)
*********************************************************************************
2 10.324846 0050DABA49EE 005056404FAB RADIUS Message Type: Accounting
Response(5) 10.10.1.201 10.10.1.150 
+ Frame: Base frame properties 
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x9C57; Proto = UDP; Len: 48
+ UDP: Src Port: Unknown, (1813); Dst Port: Unknown (3066); Length = 28 (0x1C)
 RADIUS: Message Type: Accounting Response(5)
 RADIUS: Message Type = Accounting Response
 RADIUS: Identifier = 3 (0x3)
 RADIUS: Length = 20 (0x14)
 RADIUS: Authenticator = F0 A9 27 34 0D 42 36 4B 7E C7 8A 83 E4 B6 98 41
********************************************************************************
3 21.160427 005056404FAB 0050DABA49EE RADIUS Message Type: Accounting
Request(4) 10.10.1.150 10.10.1.201 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x78CD; Proto = UDP; Len: 339
+ UDP: Src Port: Unknown, (3068); Dst Port: Unknown (1813); Length = 319
 (0x13F)
 RADIUS: Message Type: Accounting Request(4)
 RADIUS: Message Type = Accounting Request
 RADIUS: Identifier = 4 (0x4)
 RADIUS: Length = 311 (0x137)
 RADIUS: Authenticator = D1 D8 B8 45 DB 6D 4C C9 0D 84 83 27 7E A9 DF A9
 + RADIUS: Attribute Type: Acct Status Type(40)
 + RADIUS: Attribute Type: Acct Delay Time(41)
 + RADIUS: Attribute Type: NAS IP Address(4)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: NAS Port(5)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: NAS Port Type(61)
 + RADIUS: Attribute Type: Tunnel Type(64)
 + RADIUS: Attribute Type: Tunnel Media Type(65)
 + RADIUS: Attribute Type: Calling Station ID(31)
 + RADIUS: Attribute Type: Tunnel Client Endpoint(66)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Class(25)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Acct Session ID(44)
 + RADIUS: Attribute Type: User Name(1)
 + RADIUS: Attribute Type: Framed IP Address(8)
 + RADIUS: Attribute Type: Framed MTU(12)
 + RADIUS: Attribute Type: Acct Multi-Session ID(50)
 + RADIUS: Attribute Type: Acct Link Count(51)
 + RADIUS: Attribute Type: Unknown(55)
 + RADIUS: Attribute Type: Acct Authentic(45)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Acct Session Time(46)
 + RADIUS: Attribute Type: Acct Output Octets(43)
 + RADIUS: Attribute Type: Acct Input Octets(42)
 + RADIUS: Attribute Type: Acct Output Packets(48)
 + RADIUS: Attribute Type: Acct Input Packets(47)
 + RADIUS: Attribute Type: Acct Terminate Cause(49)
*******************************************************************************
4 21.160427 0050DABA49EE 005056404FAB RADIUS Message Type: Accounting
Response(5) 10.10.1.201 10.10.1.150 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xA04D; Proto = UDP; Len: 48
+ UDP: Src Port: Unknown, (1813); Dst Port: Unknown (3068); Length = 28 (0x1C)
 RADIUS: Message Type: Accounting Response(5)
 RADIUS: Message Type = Accounting Response
 RADIUS: Identifier = 4 (0x4)
 RADIUS: Length = 20 (0x14)
 RADIUS: Authenticator = 36 D6 7D D5 7E 26 9A EF 3E 0A B4 73 5C 52 FD D5

Unlike authentication, the Routing and Remote Access service sends the same attributes to the RADIUS server irrespective of the authentication method. The Routing and Remote Access service sends the following standard attributes in an Accounting Start message:

• Accounting Status TypeIndicates the type of accounting request (connection start or stop).
• Acct Delay TimeIndicates how long the client has been attempting to send the message.
• NAS IP AddressGives the IP address of the NAS (Routing and RemoteAccess server).
• Service TypeGives the type of service (for example, Framed).
• Framed ProtocolIf Service Type is Framed, then this is the framed protocol used (typically this is PPP).
• NAS PortIndicates a port ID on the NAS that the connection is being made through.
• NAS Port TypeSet to Virtual for VPN connections.
• Tunnel Type (for VPN Connections)The VPN protocol (for example, Point-to-Point Tunneling Protocol [PPTP]).
• Calling Station IDThe IP address or phone number of the remote access client.
• Tunnel Client EndpointFor VPN connections, this is the IP address of the VPN client.
• ClassA string whose format and usage is not defined in RFC 2865.
• Accounting Session IDA unique ID for a session, used to enable matching of session start and stop records.
• User NameThe name of the authenticated user of the service.
• Framed IP AddressThe user's IP address assigned by the Routing andRemote Access service.
• Framed MTUMaximum transmission unit for this connection.
• Multi-Session IDA unique accounting ID that helps to link multiple related sessions (for example, when the client is using multilink and ISDN).
• Link CountThe number of links that are known to have been used in a multilink session at the time the accounting message is generated.
• Accounting AuthenticUsed to indicate how the user was authenticated(using RADIUS, locally or remotely).
• Event TimestampIndicates the time that this event occurred on the NAS.

The Routing and Remote Access service also sends the following vendor-specific attributes, each of which are identified with the Microsoft Vendor ID of 0x127 (311 decimal) in an Accounting Start message:

• Microsoft Vendor attribute 0x08Microsoft Point-to-Point Encryption (MPPE) encryption type
• Microsoft Vendor attribute 0x09Routing and Remote Access vendor ID
• Microsoft Vendor attribute 0x0AMS-CHAP domain
• Microsoft Vendor attribute 0x12Identifies the name and version number of the Routing and Remote Access service (MSRASV5.10)
• Microsoft Vendor attribute 0x23Identifies the name and version number of the Routing and Remote Access service (MSRASV5.10)
• Microsoft Vendor attribute 0x22Identifies the machine name of the Routing and Remote Access client

When the session has completed, the Routing and Remote Access service sends the same attributes that were included in an Accounting Start message in theAccounting Stop message, plus the following additional attributes:

• Acct Session TimeThe length of the user session, in seconds
• Acct Output OctetsNumber of octets sent to the remote access client from the Routing and Remote Access service
• Acct Input OctetsNumber of octets received from the remote access client by the Routing and Remote Access service
• Acct Output PacketsNumber of packets sent to the remote access client from the Routing and Remote Access service
• Acct Input PacketsNumber of packets received from the remote access client by the Routing and Remote Access service
• Acct Terminate CauseThe reason the session was terminated (for example, user hung up)

The Routing and Remote Access service also sends the following vendor-specific attributes, each of which are identified with the Microsoft vendor ID of 0x127 (311 decimal) in an Accounting Stop message:

• Microsoft Vendor attribute 0x08MS-MPPE encryption type
• Microsoft Vendor attribute 0x09MS Routing and Remote Accessservice vendor
• Microsoft Vendor attribute 0x0AMS-CHAP domain
• Microsoft Vendor attribute 0x12MS Routing and Remote Access service version, which identifies the name and version number of the Routing andRemote Access service (MSRASV5.10)
• Microsoft Vendor attribute 0x23Identifies the name and version number of the Routing and Remote Access service (MSRASV5.10)
• Microsoft Vendor attribute 0x22Identifies the computer name of theremote access client

RADIUS Proxy in Windows Server 2003

In Windows Server 2003, IAS supports RADIUS proxy, and can support proxying of both authentication and accounting messages, as previously shown in Figure 20-2. The IAS service in Windows 2000 did not support RADIUS proxy functions, although the Routing and Remote Access service could send RADIUS messages to a RADIUS proxy.

The administrator can configure a connection request policy on IAS so that all specified RADIUS requests are forwarded to a specific remote RADIUS server group. A remote RADIUS server group is a set of one or more RADIUS servers to which requests can be forwarded. This remote RADIUS server group enables the administrator to nominate both a primary RADIUS server and one or more backup RADIUS servers. The administrator can also configure IAS to use the backup servers only if the primary server cannot be contacted, or to distribute the RADIUS messages across all servers in the group.

An IAS server can evaluate an Access-Request message against the connection request policies that have been configured to determine whether to forward the RADIUS message, and if so, to which remote RADIUS server group. The administrator can specify a condition on the connection request policy that is specific to the realm or domain name within the User Name attribute of an incoming message. Based on the realm name in the message, the portion of the user name that identifies the location of the account (such as a domain name), IAS can forward RADIUS messages to one server group for one realm, and to other server groups for other realm names.

When IAS, acting as a RADIUS proxy, forwards a RADIUS message to another RADIUS server, it adds a Proxy-State attribute to the forwarded RADIUS message. This indicates to the target RADIUS server that the original request has been proxied.

In the following trace (part of Capture 20-03 in the Captures folder on the companion CD-ROM), a RADIUS client sends a RADIUS Access-Request to a RADIUS proxy (Frame 1). The RADIUS proxy adds the Proxy-State attribute and sends the Access-Request to aRADIUS server (Frame 2). The server authenticates the request and sends the successful Access-Accept message back to the RADIUS proxy (Frame 3), which sends it back to the RADIUS client (Frame 4).

Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src
Other Addr Dst Other Addr Type Other Addr
1 1.843750 005056404FAB 0050DABA49EE RADIUS Message Type: Access
Request(1) 10.10.1.150 10.10.1.201 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x1D8F; Proto = UDP; Len: 278
+ UDP: Src Port: Unknown, (1711); Dst Port: Unknown (1812); Length = 258
 (0x102)
 RADIUS: Message Type: Access Request(1)
 RADIUS: Message Type = Access Request
 RADIUS: Identifier = 8 (0x8)
 RADIUS: Length = 250 (0xFA)
 RADIUS: Authenticator = B2 3F 8A 21 54 25 F4 14 4C 30 08 4E 34 5A 82 27
 + RADIUS: Attribute Type: NAS IP Address(4)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: NAS Port(5)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: NAS Port Type(61)
 + RADIUS: Attribute Type: Tunnel Type(64)
 + RADIUS: Attribute Type: Tunnel Media Type(65)
 + RADIUS: Attribute Type: Calling Station ID(31)
 + RADIUS: Attribute Type: Tunnel Client Endpoint(66)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: User Name(1)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
******************************************************************************
Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src
Other Addr Dst Other Addr Type Other Addr
2 1.843750 0050DABA49EE 0003FF4D34F0 RADIUS Message Type: Access
Request(1) 10.10.1.201 10.10.1.151 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xB4E; Proto = UDP; Len: 288
+ UDP: Src Port: Unknown, (2203); Dst Port: Unknown (1812); Length = 268
 (0x10C)
 RADIUS: Message Type: Access Request(1)
 RADIUS: Message Type = Access Request
 RADIUS: Identifier = 2 (0x2)
 RADIUS: Length = 260 (0x104)
 RADIUS: Authenticator = B2 3F 8A 21 54 25 F4 14 4C 30 08 4E 34 5A 82 27
 + RADIUS: Attribute Type: NAS IP Address(4)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: NAS Port(5)
 + RADIUS: Attribute Type: NAS Port Type(61)
 + RADIUS: Attribute Type: Tunnel Type(64)
 + RADIUS: Attribute Type: Tunnel Media Type(65)
 + RADIUS: Attribute Type: Calling Station ID(31)
 + RADIUS: Attribute Type: Tunnel Client Endpoint(66)
 + RADIUS: Attribute Type: User Name(1)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Proxy State(33)
****************************************************************************** 
Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src
Other Addr Dst Other Addr Type Other Addr
3 1.937500 0003FF4D34F0 0050DABA49EE RADIUS Message Type: Access
Accept(2) 10.10.1.151 10.10.1.201 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x1447; Proto = UDP; Len: 250
+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (2203); Length = 230
 (0xE6)
 RADIUS: Message Type: Access Accept (2)
 RADIUS: Message Type = Access Accept
 RADIUS: Identifier = 2 (0x2)
 RADIUS: Length = 222 (0xDE)
 RADIUS: Authenticator = B7 87 6F 17 EC 00 8B 66 0B E9 33 5C 61 B8 BF 72
 + RADIUS: Attribute Type: Proxy State(33)
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Class(25)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
******************************************************************************
Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src
Other Addr Dst Other Addr Type Other Addr
4 1.937500 0050DABA49EE 005056404FAB RADIUS Message Type: Access
Accept(2) 10.10.1.201 10.10.1.150 
+ Frame: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xB50; Proto = UDP; Len: 240
+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (1711); Length = 220
(0xDC)
 RADIUS: Message Type: Access Accept(2)
 RADIUS: Message Type = Access Accept
 RADIUS: Identifier = 8 (0x8)
 RADIUS: Length = 212 (0xD4)
 RADIUS: Authenticator = DF 3D 1B DB 9E 9F D8 B0 B3 B1 5C 2C C0 F9 5B BA
 + RADIUS: Attribute Type: Framed Protocol(7)
 + RADIUS: Attribute Type: Service Type(6)
 + RADIUS: Attribute Type: Class(25)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)
 + RADIUS: Attribute Type: Vendor Specific(26)

RADIUS Message Structure

All RADIUS messages are transmitted using UDP. Each UDP datagram contains a single RADIUS message. The RADIUS message is contained in the UDP datagram's message field. RADIUS access messages are sent by default, from the client to the server (and from a proxy to a server) using a UDP destination port field of 1812 and an ephemeral UDP source port. RADIUSaccounting messages are sent using UDP destination port 1813 and an ephemeral UDP source port. When responses are sent, the source and destination ports are reversed.

All RADIUS messages have a common structure, illustrated in Figure 20-4.

Figure 20-4: RADIUS message structure.

Earlier implementation of RADIUS used UDP port 1645 for access messages and UDP port 1656 for accounting messages. However, this conflicted with two other existing protocols: Diametrics, which used UDP port 1645, and Sa-msg-port, which used UDP port 1646. To avoid potential conflicts, RADIUS now uses UDP ports 1812 and 1813. Most RADIUS servers, including IAS in Windows Server 2003, allow the administrator to choose the port that the RADIUS server uses for authentication and accounting messages.

Common RADIUS Header

Each RADIUS message has a common header, indicating the purpose of the message and a variable number of attributes that comprise the data of the message. The common header consists of the following fields:

• CodeIndicates the RADIUS message type
• IdentifierHelps match a RADIUS request and its related reply
• LengthThe length of the RADIUS message
• AuthenticatorUsed to authenticate a reply from the RADIUS server and to ensure that the RADIUS client and server or proxy have the same shared secret

The Code field is a single octet to RADIUS message type. If a RADIUS client, proxy, or server receives a RADIUS message with an invalid, unassigned code, the message is discarded silently. Assigned RADIUS message types and their uses are shown in Table 20-1.

Table 20-1: RADIUS Attributes and Usage

RADIUS Code(Decimal)	Message	Used for
1	Access-Request	Used by a NAS to request authorization and authentication of a connection
2	Access-Accept	Used by a RADIUS server to accept a connection request and sent in response to an Access-Request message
3	Access-Reject	Used by a RADIUS server to reject a connection request and sent in response to an Access-Request message
4	Accounting-Request	Used by a NAS to send accounting information to a RADIUS server
5	Accounting- Response	Sent by a RADIUS server to indicate that an Accounting- Request message has been received
11	Access-Challenge	Used by the RADIUS server to direct the RADIUS client to obtain more information about the connection (typically user credentials)
12	Status-Server	Experimental and not supported by IAS
13	Status-Client	Experimental and not supported by IAS
255	Reserved	Reserved

The 1-octet Identifier field is used by RADIUS clients and proxies to match requests withreplies. This field also enables a RADIUS server to detect a duplicate request—a request that came within a short span of time from the same client source IP address and source UDP port and with the same identifier. The Routing and Remote Access service, asa RADIUS client, starts with an initial identifier of 1 and increases it by 1 for each new RADIUS request.

When a RADIUS proxy sends a message to a RADIUS server, the proxy creates a new value for the Identifier field. The RADIUS proxy sends replies back to a RADIUS client with the value of the identifier corresponding to the initial request. This can be seen in Capture 20-04, which shows a RADIUS proxy receiving a message from a RADIUS client and sending it on to a RADIUS server. Each proxied message has an identifier different from that in the initial request.

The 16-bit Length field indicates the entire length, in octets, of the RADIUS message, which includes the common header and all attributes. If, for some reason, a RADIUS message is shorter than the Length field indicates, it is silently discarded. Should there be additional data octets contained in the UDP Data field that are outside the range indicated by the Length field, they are ignored. The Length field has a minimum value of 20 octets and maximum value of 4096 octets.

The Authenticator field is 16 octets long and is used by a RADIUS client to authenticate a reply received from a RADIUS server. The Authenticator field provides proof of knowledge of a shared secret configured between a RADIUS client and its RADIUS server, whether that server is a RADIUS proxy or a RADIUS server.

Attributes

RADIUS attributes carry data values that are used in the authentication, authorization, and accounting functions carried out by RADIUS clients, servers, and proxies. These attributes can appear in access and accounting requests and in response messages. Some attributes can be included more than once, the effect of which is dependent on the specific attribute. When used as a RADIUS proxy, IAS preserves the order of the attributes received from the client in messages transmitted to a RADIUS server.

The layout of RADIUS attributes is shown in Figure 20-5.

Figure 20-5: RADIUS attribute structure.

The Type field in the RADIUS attribute structure is a 1-octet field that defines thespecific RADIUS attribute. You can find up-to-date values for the RADIUS Attribute Type field on the Internet Assigned Numbers Authority's Web site at http://www.iana.org/assignments/radius-types. Common RADIUS attributes are listed in Table 20-2, along with their purposes.

Table 20-2: Common RADIUS Attributes

Attribute Type(Decimal)	Attribute Name	Purpose of Attribute
1	User-Name	Sent in Access-Request messages, this attribute indicates the name of the user that is to be authenticated.
2	User-Password	Sent in Access-Request messages, when authenti- cation is by PAP, this field is the password to be used to authenticate the user. The password is encrypted in Access-Request messages. The pass- word is first padded at the end with nulls (0x00) to a multiple of 16 octets. Next, a one-way MD5 hash is calculated over a stream of octets consisting of the RADIUS shared secret followed by the Request Authenticator. This value is XORed with the first16-octet segment of the password and placed in the first 16 octets of the String field of the User-Password attribute. If the password is longer than 16 charac- ters, a second one-way MD5 hash is calculated over a stream of octets consisting of the RADIUS shared secret followed by the result of the first XOR. That hash is XORed with the second 16-octet segment of the password and placed in the second 16 octets of the String field of the User-Password attribute. If necessary, this operation is repeated, with each XOR result being used along with the shared secret to generate the next hash, to no more than128 characters.
3	CHAP-Password	This attribute is sent in Access-Request messages to indicate the response value provided by a PPP CHAP user in response to a CHAP challenge. The value of the CHAP challenge is also included in Access-Request messages sent by the Routing and Remote Access service.
4	NAS-IP-Address	This attribute is sent in Access-Request messages to indicate the IP address of the RADIUS client that is requesting authentication.
5	NAS-Port	This attribute is sent in Access-Request messages to indicate the physical port of the RADIUS client that is requesting authentication
6	Service-Type	This attribute is sent in Access-Request and Access- Accept messages to indicate the type of service the RADIUS client has requested, or the type of service to be provided. The Value field is 4 octets long and can have the following values: Login Framed Callback Login allback Framed Outbound Administrative NAS Prompt Authenticate Only Callback NAS Prompt Call Check Callback Administrative
7	Framed-Protocol	This attribute is contained in Access-Request messages to indicate the specific framed protocol being requested. Possible values for this attribute are as follows: PPP Serial Line Internet Protocol (SLIP) AppleTalk Remote Access Protocol (ARAP) Gandalf proprietary SingleLink/MultiLink protocol Xylogics proprietary IPX/SLIP X.75 Synchronous
8	Framed-IP-Address	This attribute is included in accounting requests and indicates the IP address of the access client.
12	Framed-MTU	This attribute is included in Routing and Remote Access accounting requests and indicates the MTU configured for the RADIUS client
25	Class	This attribute is available to be sent by the server to the client in an Access-Accept message and is then sent, unmodified, by the RADIUS client to the RADIUS accounting server as part of any accounting records. This attribute contains a string identifying the NAS originating the Access-Request message.
31	Calling-Station-Id	This attribute is used only in Access-Request messages. The NAS (or other device) uses this attribute to send either the phone number that the call came from for dial-up connections, or the IP address of the VPN client for VPN connections
32	NAS-Identifier	This attribute is used only in the Access-Request message to contain a string identifying the NAS originating the Access-Request. The NAS-Identifier is not used to select the shared secret used to authenticate the request.
33	Proxy-State	This attribute is added to an Access-Request by a RADIUS proxy and is returned unmodified in the Access-Accept, Access-Reject, or Access-Challenge message. When a RADIUS proxy receives a response to its request, it removes its own Proxy- State (the last Proxy-State in the message) before forwarding the response to the NAS. If a Proxy- State attribute is added when forwarding a RADIUS message, the Proxy-State attribute is added after any existing Proxy-State attributes (which allows chaining RADIUS proxy servers).
40	Acct-Status-Type	This is sent in an Accounting-Request message to indicate the beginning or end of the user session or an interim update. Possible values include the following: 1Start 2Stop 3Interim-Update 7Accounting-On 8Accounting-Off 9–14Reserved for Tunnel Accounting 15Reserved for Failed
41	Acct-Delay-Time	This is sent in an Accounting-Request message to indicate for how many seconds the RADIUS client has been trying to send this request. By subtracting this value from the time of arrival on the RADIUS server, the server can approximate the time of the event generating this Accounting-Request message.
42	Acct-Input-Octets	This is sent in an Accounting-Request message in which Acct-Status-Type is set to Stop. It contains the number of data octets that have been received from the port during the accounting session.
43	Acct-Output-Octets	This is sent in an Accounting-Request message where Acct-Status-Type is set to Stop. It contains the number of data octets that have been sent to the port during the accounting session.
44	Acct-Session-Id	This attribute is sent in Accounting Start and Accounting Stop messages and contains a unique ID to identify a session. This makes it easier to match start and stop records in RADIUS log files, because the start and stop records for a given session have the same Acct-Session-Id. A RADIUS client can send send this attribute in an Access-Request message. If so, the NAS must send same Acct-Session-Id in Accounting-Request messages for that session.
46	Acct-Session-Time	This attribute is contained in Accounting Stop messages to indicate how many seconds the NAS has provided the service (that is, the time of the connection).
47	Acct-Input-Packets	This attribute is contained in Accounting Stop messages to indicate how many IP datagrams the NAS has received.
48	Acct-Output-Packets	This attribute is contained in Accounting Stop packets to indicate how many IP datagrams the NAS has sent.
49	Acct-Terminate-Cause	This attribute is contained in Accounting Stop messages to indicate the reason for the session being terminated. Possible values are as follows: User Request Lost Carrier Lost Service Idle Timeout Session Timeout Admin Reset Admin Reboot Port Error NAS Error NAS Request NAS Reboot Port Unneeded Port Preempted Port Suspended Service Unavailable Callback User Error Host Request
50	Acct-Multi-Session-Id	This attribute is sent in accounting messages to enable the RADIUS accounting server to link together multiple related sessions in the RADIUS logs. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id.
51	Acct-Link-Count	This attribute is sent in accounting messages to enable the RADIUS accounting server to record the number of links that are used in a multilink session at the time the accounting record is generated. The NAS might include the Acct-Link-Count attribute in any Accounting-Request that might have multiple links.
55	Event-Timestamp	This attribute is included in an Accounting-Request message. It records the time that this event occurred on the NAS, in seconds since January 1, 1970 00:00 UTC (Coordinated Universal Time).
60	CHAP-Challenge	This attribute contains the CHAP Challenge sent by the NAS to the access client. It is only used in Access-Request messages.
61	NAS-Port-Type	This attribute indicates the type of the physical port of the NAS that is authenticating the user and is con- tained in Access-Request packets. Possible values include the following: Async Sync ISDN Sync ISDN Async V.120 ISDN Async V.110 Virtual PIAFS HDLC Clear Channel X.25 X.75 G.3 Fax Symmetric DSL (SDSL) Asymmetric DSL, Carrierless Amplitude Phase(ADSL-CAP) modulation Asymmetric DSL, Discrete Multi-Tone(ADSL-DMT) ISDN Digital Subscriber Line (IDSL) Ethernet Digital Subscriber Line of unknown type (xDSL) Cable Wireless–Other Wireless–IEEE 802.11
64	Tunnel-Type	This attribute is used in Access-Request messages to indicate the type of VPN tunnel that the NAS is attempting to set up. Possible values include the following: PPTP Layer Two Forwarding (L2F) Layer Two Tunneling Protocol (L2TP) Ascend Tunnel Management Protocol (ATMP) Virtual Tunneling Protocol (VTP) IP Authentication Header in the Tunnel-mode (AH) IP-in-IP encapsulation (IP-IP) Minimal IP-in-IP encapsulation (MIN-IP-IP) IP Encapsulating Security Payload in the Tunnel-mode (ESP) Generic Route Encapsulation (GRE) Bay Dial Virtual Services (DVS) IP-in-IP Tunneling [10]
65	Tunnel-Medium-Type	This attribute is used when authenticating a VPN connection and indicates the transport medium that is being used when creating a tunnel for those protocols (such as L2TP) that can operate over multiple transports. Possible values are as follows: IPv4 (IP version 4) IPv6 (IP version 6) Network Service Access Point (NSAP) High-level Datalink Control (HDLC) (8-bit multidrop) BBN 1822 802 (includes all 802 media plus Ethernet canonical format) E.163 (Plain Old Telephone Service [POTS]) E.164 (Switched Multimegabit Data Service[SMDS], Frame Relay, Asynchronous Transfer Mode [ATM]) F.69 (Telex) X.121 (X.25, Frame Relay) IPX AppleTalk Decnet IV Banyan Vines E.164 with NSAP format subaddress
66	Tunnel Client Endpoint	This attribute contains the address of the VPN client and can be included in both Access-Request and Access-Accept messages when a VPN tunnel is being set up.
80	Message Authenticator	This attribute is used in RADIUS Access-Request messages to provide proof of the knowledge of the RADIUS shared secret.

Vendor Specific Attributes

RFC 2865 provides a mechanism to enable vendors to extend the range of attributes that are implemented. This enables vendors to provide their own attributes for use on their hardware.

If a RADIUS client sends vendor-specific attributes to a RADIUS server that the server cannot interpret, the server ignores them. Likewise, if a client receives vendor-specific attributes from a RADIUS server, it should attempt to operate without using them, although this could result in degraded performance, depending on the specific attribute.

Vendor-specific attributes are encoded in RADIUS messages as normal attributes with an attribute type of 26. As shown in Figure 20-6, there are two formats for vendor-specific attributes, with the second format preferred. In Windows Server 2003, both Routing and Remote Access and IAS use the preferred format.

Figure 20-6: Vendor-specific attribute structure.

RFC 2548 defines the Microsoft-specific attributes that are supported by Routing and Remote Access and IAS. This RFC was originally written for the Routing and Remote Access service for Microsoft Windows NT 4.0 Server, but these vendor-specific attributes are valid with Windows Server 2003. Both IAS and Routing and Remote Access set the Vendor-ID field of the Vendor-Specific attribute to 311 (0x0137), which denotes Microsoft.

Table 20-3 contains the most common vendor-specific attributes that Routing and Remote Access and IAS use.

Table 20-3: Common Vendor-Specific Attributes

Vendor AttributeID (Decimal)	Attribute Name	Purpose of Attribute
1	MS-CHAP-Response	Sent in authentication requests that use CHAP to contain the CHAP response received from the access client.
9	MS-RAS-Vendor	Sent in authentication requests to identify the vendor(Microsoft).
10	MS-CHAP-Domain	This attribute, which can be in both Access-Accept and Accounting-Request messages, indicates the Windows Server 2003 domain in which the user has been authenticated.
11	MS-CHAP-Challenge	The CHAP challenges used in authentication requests that use CHAP, MS-CHAP, or MS-CHAP v2.
16	MS-MPPE-Send-Key	This attribute holds a session key for use by MPPE. This key is intended for encrypting messages sent from the NAS to the access client and is sent only in Access-Accept messages. This attribute is encrypted using the shared secret.
17	MS-MPPE-Recv-Key	This attribute contains a session key for use by MPPE. This key is intended for encrypting packets received by the NAS from the access client and is used only in Access-Accept messages.
18	MS-RAS-Version	The version of Routing and Remote Access sending the RADIUS message. This is sent in Access-Request and Accounting-Request messages. This attribute is encrypted using the shared secret.
25	MS-CHAP2-Response	For Authentication requests that use MS-CHAP v2, the CHAP response received from the Access client.
26	MS-CHAP2-Success	For authentication requests that use MS-CHAP v2, the indication that the authentication was successful.

RADIUS Messages

RADIUS clients, such as a NAS device or the Routing and Remote Access service inWindow Server 2003, send two types of messages to a RADIUS server:

• Authentication messagesDefined in RFC 2865, these enable the RADIUS client to authenticate and authorize connection attempts.
• Accounting messagesDefined in RFC 2866, these messages enable the NAS or other RADIUS client to record details of the resources used by the Access client.

When a RADIUS server receives a valid authentication or accounting message, it sends a response back to the RADIUS client indicating the success, failure, or a request for more information for the authentication request or the success of an accounting request.

Authentication

There are four RADIUS Authentication messages sent between RADIUS clients and servers, described in the following sections.

Access-Request

An Access-Request message is sent by a RADIUS client to the RADIUS server to determine whether a connection to the RADIUS client (the NAS) is allowed. The message also enables the RADIUS client to enquire whether there are any special requirements for the use of that service. The Access-Request message contains the information needed to identify the RADIUS client's users to perform the authentication and to enable theRADIUS server to ascertain whether any special requirements exist for this request.

When the RADIUS server receives the Access-Request message, it first checks that the message came from a known client. The server then attempts to perform the requested authentication and authorization and responds with an appropriate reply.

Access-Request messages contain the following fields:

• Code field set to 1 to indicate an Access-Request.
• Identifier field set to a value that identifies this specific request. This field is changed whenever the content of the attribute's field changes and when a valid reply has been received for a previous request. If the RADIUS client needs to retransmit an Access-Request, this field is not changed.
• A Request Authenticator field to enable the client to authenticate the server in the server's response.
• NAS-IP-Address attribute or a NAS-Identifier attribute (or both).
• A User-Name attribute to identify the user to be authenticated.
• Either a User-Password or a CHAP-Password (but not both). When a User-Password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5.

An Access-Request can also contain additional attributes as a hint to the RADIUS server, but the server is not required to honor the hint. The Routing and Remote Access service, for example, sends several Microsoft vendor attributes, including the version of Routing and Remote Access service in use.

Access-Challenge

An Access-Challenge message is sent by a RADIUS server to the RADIUS client, requesting that the RADIUS client obtain additional information from the access client to complete the authentication. Access-Challenge messages are used when EAP is the authentication method, in which each Access-Challenge message is an EAP message from the RADIUS server to the access client.

If the connection requires additional information that can be obtained by an Access-Challenge message, the server responds to an Access-Request message by transmitting an Access-Challenge message. When the RADIUS client receives an Access-Challenge message, it matches the Identifier field of a pending Access-Request and verifies that the Response Authenticator field contains the correct response for the pending AccessRequest. Invalid messages are silently discarded.

A RADIUS client that does not support challenge and response treats the Access-Challenge as though it had received an Access-Reject message instead. This has the effect of denying the requested access. If the RADIUS client supports challenge and response, the receipt of a valid Access-Challenge message indicates that a new Access-Request is to be sent, which should contain updated request information. The RADIUS client can display a text message to the user and then prompt the user for a response. The RADIUS client then sends its original Access-Request with a new request ID and Request Authenticator, with the User-Password attribute replaced by the user's response to the challenge, suitably encrypted. If the Access-Challenge contained a State attribute from the Access-Challenge, this is also returned. Note that the Access-Request messages can contain, at most, one instance of the State attribute.

Access-Challenge messages contain the following fields:

• Code field set to 11 to indicate an Access-Challenge message.
• Identifier field is a copy of the Identifier field of the Access-Request message that caused this Access-Challenge message.
• Response Authenticator is calculated from the Authenticator field in theAccess-Request message and the shared secret, as described earlier.
• Vendor-Specific, Idle-Timeout, Session-Timeout, and Proxy-State are the only attributes that can be included in an Access-Challenge message, although these are optional.

Access-Accept

An Access-Accept message is sent by a RADIUS server to a RADIUS client to allow a connection request and optionally to provide configuration information necessary for the connection.

When the RADIUS client receives an Access-Accept message, the client matches the Identifier field with a pending Access-Request and ensures that the Response Authenticator field contains the correct response for this pending Access-Request message. Invalid messages are silently discarded. The Identifier field in an Access-Accept message is a copy of the Identifier field of the Access-Request that caused this Access-Accept message.

Access-Accept messages contain the following fields:

• Code field set to 2 to indicate an Access-Accept message.
• Identifier field is a copy of the Identifier field of the Access-Request message that caused this Access-Accept message.
• Response Authenticator is calculated from the Access-Request value, asdescribed earlier.

In addition to these fields, a RADIUS server can send zero or more attributes back to the RADIUS client. With IAS the administrator can configure the RADIUS server to return a large variety of RADIUS attributes to the RADIUS client, based on the remote access policies set at the IAS server.

Access-Reject

An Access-Reject message is sent by a RADIUS server to a RADIUS client to deny a connection request. If the RADIUS server receives an Access-Request message but either cannot authenticate the user credentials or cannot authorize the connection, itreturns an Access-Reject message to the RADIUS client. The RADIUS client can then either send a message to the client denying the request for service or re-request credentials and then attempt the authentication by sending a new Access-Request message.

Access-Reject messages contain the following fields:

• Code field set to 3 to indicate an Access-Reject message.
• Identifier field is a copy of the Identifier field of the Access-Request that caused this Access-Reject.
• Response Authenticator is calculated from the Access-Request message.
• Accounting Status Type attribute is set to indicate whether this request is for the start or stop of an accounting record.

If the authentication was performed using CHAP, MS-CHAP, or MS-CHAP v2, an IAS server sends an MS-Chap-Error attribute back to the RADIUS client to indicate the failure.

RADIUS Authentication Message Exchanges

There are two primary sets of authentication message exchanges that are normally seen between a RADIUS client and a RADIUS server:

• Access-Request, followed by Access-AcceptThis occurs when a RADIUS server successfully authenticates and authorizes a connection on behalf of a RADIUS client. Once the authentication has been successfully completed,the RADIUS client (for example, Routing and Remote Access service) can then commence service to a client (that is, a Routing and Remote Access server can provide remote access service to a dial-up or VPN client).
• Access-Request, followed by Access-RejectThis occurs when a RADIUS server does not successfully authenticate and authorize a connection on behalf of a RADIUS client. The RADIUS client can then attempt to get new credentials, which it can resubmit in a new Access-Request message.

A third, less frequently seen type of exchange involves an Access-Challenge. In this exchange, the RADIUS client first sends an Access-Request to the RADIUS server, which responds with the RADIUS Access-Challenge. The RADIUS client obtains additionalinformation from the access client, and then sends another Access-Request to the server. There can be multiple Access-Challenge messages sent by the RADIUS server.

Presence of RADIUS Proxy

A RADIUS proxy that forwards RADIUS messages between RADIUS clients and RADIUS servers, as illustrated in Figure 20-2. When a RADIUS proxy is used, the RADIUS proxy adds an additional attribute, Proxy-State, to the original Access-Request message before sending it to the RADIUS server. The response (Access-Accept, Access-Reject, or Access-Challenge) is sent from the RADIUS server to the RADIUS proxy with the Proxy-State attribute. The RADIUS proxy then removes the Proxy-State attribute and sends the remainder of the RADIUS message back to the RADIUS client. In all cases, the RADIUS client is unaware of the presence, or absence, of the RADIUS proxy.

Accounting

There are two RADIUS Accounting messages sent between RADIUS clients and RADIUS servers: Accounting-Request and Accounting-Response. The RADIUS client sends an Accounting-Request message to a RADIUS server. This message indicates that an accounting session has started, describes the type of service being delivered, and identifies the user receiving the service. The RADIUS server responds with an Accounting-Responsemessage indicating that the accounting start was received and recorded.

When the service being provided by the RADIUS client (for example, remote access) has been completed, the RADIUS client generates a further Accounting-Request message called an Accounting Stop message. This describes the type of service that was delivered and statistics such as elapsed time, input and output octets, or input and output packets, which could be used for billing or charge-back purposes. The RADIUS server then sends the client an Accounting-Response message to indicate that the message was received and recorded.

Accounting-Request

An Accounting-Request message is sent by a RADIUS client to inform a RADIUS accounting server of an accounting event. The Accounting-Request message holds the information needed to provide accounting for the service being provided for the RADIUS client. When the RADIUS server receives an Accounting-Request message, it records the accounting information and replies with an Accounting-Response message. If the server cannot record the accounting information, no Accounting-Response message is sent.

The RADIUS client can send any valid RADIUS attribute in the Accounting-Request message, except for User-Password, CHAP-Password, Reply-Message, and State. A RADIUS client always includes either the NAS-IP-Address or NAS-Identifier in the Accounting-Request. If the Accounting-Request message includes a Framed-IP-Address, this attribute contains the IP address assigned to the connection.

Accounting-Request messages contain the following fields:

• Code field set to 4 to indicate an Accounting-Request.
• Identifier field is one octet to identify this Accounting-Request.
• Length field is 2 octets, which defines the length of the message, including the Code field.
• Authenticator is a 16-octet value used to authenticate the messages between the client and RADIUS accounting server. This field contains a one-way MD5 hash calculated over a stream of octets consisting of the concatenation of the Code, Identifier, Length, a field of 16 zero octets, all request attributes, and the shared secret.
• Acct-Status-Type is used to indicate whether this Accounting-Request message is the start or stop of a connection. The RADIUS client can also send interim updates and can indicate the start and stop of accounting (for example, theclient can indicate to the RADIUS server that accounting has started afterbooting and that accounting has stopped just prior to a reboot).

As can be seen in Capture 20-03, the Routing and Remote Access service sends the following standard attributes in an Accounting Start request:

• User Name (attribute value 1)The user name and domain of the userrequesting the service.
• NAS IP Address (4)Set to the IP address of the RADIUS client.
• NAS Port (5)The port on the NAS relating to this Accounting-Request.
• Service Type (6)The same as for RADIUS authentication.
• Framed Protocol (7)Indicates the framing protocol to be used forframed access.
• Framed IP Address (8)For a VPN, this holds the client IP address allocated by the VPN server.
• Framed MTU (12)The MTU for the connection.
• Class (25)Defines the class of the authentication request. Its usage is not defined in RFC 2865.
• Calling Station ID (31)Set to the IP address of the access client.
• Acct-Status-Type (40)Set to 1 to indicate accounting start.
• Acct-Delay-Time (41)Indicates how many seconds the RADIUS client has been trying to send this accounting request.
• Acct-Session-Id (44)Used to identify a particular session and to match up the session start and end messages.
• Acct-Authentic (45)Indicates how the user was authenticated. This is set to 0x01 to indicate RADIUS authentication.
• Acct-Multi-Session-Id (50)Identification field used to link multiple related sessions together. This is typically used for dial-up sessions using multilink ISDN.
• Acct-Link-Count (51)The count of the links in a given multilink session.
• Event-Timestamp (55)Records the time that the accounting event occurred on the NAS, in seconds since midnight January 1, 1970 (UTC).
• NAS-Port-Type (61)Indicates that this is a VPN connection.
• Tunnel-Type (64)For VPNs, the VPN protocol (for example, PPTP).
• Tunnel-Medium-Type (65)For VPNs, denotes the transport medium used when creating the VPN tunnel.

The Routing and Remote Access service, when acting as a RADIUS client, also sends the following vendor-specific attributes to the RADIUS server:

• MS-MPPE-Encryption-Type (8)Indicates the MPPE encryption type used.
• MS-RAS-Vendor (9)Identifies the vendor (Microsoft).
• MS-RAS-Version (18)Indicates the version of Routing and Remote Access service (for Windows Server 2003, MSRASVS5.10).

When the RADIUS client (for example, the Routing and Remote Access service) completes offering its service, it sends an Accounting Stop message. This is similar to the Accounting Start message, noted earlier, but with the Acct-Status-Type attribute set to 2 and with extra attributes to reflect the usage of the NAS or other device.

In addition to the attributes sent in an Accounting Start message, the Routing and Remote Access service sends the following attributes:

• Acct-Input-Octets (42)Indicates how many octets have been received by the NAS while the service was being provided.
• Acct Output Octets (43)Indicates how many octets have been sent to the NAS while the service was being provided.
• Acct Session Time (46)Indicates how long (in seconds) the service was provided.
• Acct-Input-Packets (47)Indicates how many packets have been received by the NAS while the service was being provided.
• Acct-Output-Packets (48)Indicates how many packets have been sent to the NAS while the service was being provided.
• Acct-Terminate-Cause (49)Specifies how the session was terminated. Values can include the following:
  • 1User Request
  • 2Lost Carrier
  • 3Lost Service
  • 4Idle Timeout
  • 5Session Timeout
  • 6Admin Reset
  • 7Admin Reboot
  • 8Port Error
  • 9NAS Error
  • 10NAS Request
  • 11NAS Reboot
  • 12Port Unneeded
  • 13Port Preempted
  • 14Port Suspended
  • 15Service Unavailable
  • 16Callback
  • 17User Error
  • 18Host Request

Accounting-Response

An Accounting-Response message is sent by the RADIUS accounting server to the RADIUS client to acknowledge that the Accounting-Request has been received and recorded successfully. When the RADIUS client receives the Accounting-Response message, it matches the response with a pending Accounting-Request to complete the accounting for this event. If no Accounting-Response is received, the RADIUS client retransmits the Accounting-Request.

As with other RADIUS messages, the Response Authenticator field holds the authenticator that relates to the pending Accounting-Request. Additionally, invalid packets, which can include those in which the authenticator cannot be validated, are silently discarded.

A RADIUS Accounting-Response is not required to contain any attributes. The IAS server does not send any attributes in an Accounting-Response message, as can be seen in Capture 20-03.

RADIUS Accounting Message Exchanges

There is only one type of message exchange with RADIUS accounting: an Accounting-Request followed by an Accounting-Response. The Accounting-Request can indicate the start or completion of a user session (for example, a VPN connection to a Routing and Remote Access server). Additionally, RADIUS clients can post interim accounting records and are able to indicate the start and stop of accounting (for example, an Accounting-On message can be sent after the NAS boots and an Accounting-Off message sent just prior to a scheduled reboot).

If the RADIUS client sends an Accounting-Request, but no Accounting-Response isreceived, the administrator can configure the client to send the request to alternate servers if the original server is not responsive. The retransmission technique used by the Routing and Remote Access service was described earlier in this chapter.

Presence of RADIUS Proxy with RADIUS Accounting Messages

As with RADIUS authentication messages, the administrator can configure a RADIUS server to serve as a proxy that forwards the accounting message to another server. The accounting proxy works in the same manner as the authentication proxy, as described earlier inthis chapter.

Summary

RADIUS is a mature and powerful protocol for authentication, authorization, and accounting and is used extensively on the Internet and for authenticated access to private networks (dial-up, VPN, and wireless connections). RADIUS provides authentication and authorization for NAS connections through an exchange of Access-Request/Access-Accept messages between a RADIUS client and a RADIUS server. RADIUS provides accounting for NAS connections through an exchange of Accounting-Request/Accounting-Response messages between a RADIUS client and a RADIUS server. A RADIUS proxy can be used to forward RADIUS messages between RADIUS clients and RADIUS servers.