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 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:

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:

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:

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:

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:

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:

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:

  1. Login

  2. Framed

  3. Callback Login

  4. allback Framed

  5. Outbound

  6. Administrative

  7. NAS Prompt

  8. Authenticate Only

  9. Callback NAS Prompt

  10. Call Check

  11. 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:

  1. PPP

  2. Serial Line Internet Protocol (SLIP)

  3. AppleTalk Remote Access Protocol (ARAP)

  4. Gandalf proprietary SingleLink/MultiLink protocol

  5. Xylogics proprietary IPX/SLIP

  6. 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:

  1. User Request

  2. Lost Carrier

  3. Lost Service

  4. Idle Timeout

  5. Session Timeout

  6. Admin Reset

  7. Admin Reboot

  8. Port Error

  9. NAS Error

  10. NAS Request

  11. NAS Reboot

  12. Port Unneeded

  13. Port Preempted

  14. Port Suspended

  15. Service Unavailable

  16. Callback

  17. User Error

  18. 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:

  1. Async

  2. Sync

  3. ISDN Sync

  4. ISDN Async V.120

  5. ISDN Async V.110

  6. Virtual

  7. PIAFS

  8. HDLC Clear Channel

  9. X.25

  10. X.75

  11. G.3 Fax

  12. Symmetric DSL (SDSL)

  13. Asymmetric DSL, Carrierless Amplitude Phase(ADSL-CAP) modulation

  14. Asymmetric DSL, Discrete Multi-Tone(ADSL-DMT)

  15. ISDN Digital Subscriber Line (IDSL)

  16. Ethernet

  17. Digital Subscriber Line of unknown type (xDSL)

  18. Cable

  19. Wireless–Other

  20. 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:

  1. PPTP

  2. Layer Two Forwarding (L2F)

  3. Layer Two Tunneling Protocol (L2TP)

  4. Ascend Tunnel Management Protocol (ATMP)

  5. Virtual Tunneling Protocol (VTP)

  6. IP Authentication Header in the Tunnel-mode (AH)

  7. IP-in-IP encapsulation (IP-IP)

  8. Minimal IP-in-IP encapsulation (MIN-IP-IP)

  9. IP Encapsulating Security Payload in the Tunnel-mode (ESP)

  10. Generic Route Encapsulation (GRE)

  11. Bay Dial Virtual Services (DVS)

  12. 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:

  1. IPv4 (IP version 4)

  2. IPv6 (IP version 6)

  3. Network Service Access Point (NSAP)

  4. High-level Datalink Control (HDLC) (8-bit multidrop)

  5. BBN 1822

  6. 802 (includes all 802 media plus Ethernet canonical format)

  7. E.163 (Plain Old Telephone Service [POTS])

  8. E.164 (Switched Multimegabit Data Service[SMDS], Frame Relay, Asynchronous Transfer Mode [ATM])

  9. F.69 (Telex)

  10. X.121 (X.25, Frame Relay)

  11. IPX

  12. AppleTalk

  13. Decnet IV

  14. Banyan Vines

  15. 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:

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:

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:

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:

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:

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:

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:

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

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

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:

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.

Related

Категории