Chapter 1 AAA/RADIUS/HWTACACS Configuration
When configuring AAA/RADIUS/HWTACACS, go to these sections for
information you are interested in:
l
AAA/RADIUS/HWTACACS
Overview
l
AAA/RADIUS/HWTACACS
Configuration Task List
l
Configuring AAA
l
Configuring RADIUS
l
Configuring HWTACACS
l
Displaying and
Maintaining AAA/RADIUS/HWTACACS
l
AAA/RADIUS/HWTACACS
Configuration Examples
l
Troubleshooting
AAA/RADIUS/HWTACACS
This section covers these topics:
l
Introduction to AAA
l
Introduction to RADIUS
l
Introduction to
HWTACACS
1.1.1 Introduction to AAA
Authentication, Authorization, and
Accounting (AAA) provides a uniform framework for configuring these three
security functions to implement network security management.
AAA usually uses a client/server model,
where the client runs on the network access server (NAS) and the server maintains
user information centrally. In an AAA network, a NAS is a server for users but
a client for the AAA servers, as shown in Figure 1-1.
Figure 1-1 AAA networking diagram
When a user tries to establish a connection
to the NAS and obtain the rights to access other networks or some network
resources, the NAS authenticates the user or the corresponding connection. The
NAS can also transparently pass the user authentication, authorization and
accounting information to the server (RADIUS server or HWTACACS server). The
RADIUS/HWTACACS protocol defines how to exchange user information between a NAS
and a server.
In the AAA network shown in Figure 1-1,
there is a RADIUS server and a HWTACACS server. You can determine the
authentication, authorization and accounting scheme according to the actual
requirements. For example, you can use the RADIUS server for authentication and
authorization, and the HWTACACS server for accounting.
The three security functions are described
as follows:
l
Authentication: Identifies remote users and
judges whether a user is legal.
l
Authorization: Grants different users different
rights. For example, a user logging into the server can be granted the
permission to access and print the files in the server.
l
Accounting: Records all network service usage
information of users, including the service type, start and end time, and
traffic. In this way, accounting can be used for not only accounting itself,
but also network security surveillance.
You can use AAA to provide only one or two
security functions, if desired. For example, if your company only wants
employees to be authenticated before they access specific resources, you can
configure only an authentication server. If the network usage information is
expected to be recorded, you also need to configure an accounting server.
As mentioned above, AAA provides a uniform
framework to implement network security management. It is a security mechanism
that enables authenticated and authorized entities to access specific resources
and records operations by the entities. The AAA framework thus allows for
excellent scalability and centralized user information management.
AAA can be implemented through multiple
protocols. Currently, the device supports using RADIUS and HWTACACS for AAA,
and RADIUS is often used in practice.
1.1.2 Introduction to RADIUS
Remote Authentication Dial-In User Service
(RADIUS) is a distributed information interaction protocol in the client/server
model. RADIUS can protect networks against unauthorized access and is often
used in network environments where both high security and remote user access
are required. Based on UDP, RADIUS defines the RADIUS packet format and the
message transfer mechanism, and uses UDP port 1812 as the authentication port
and 1813 as the accounting port.
RADIUS was originally designed for dial-in
user access. With the diversification of access methods, RADIUS has been
extended to support more access methods, for example, Ethernet access and ADSL
access. It uses authentication and authorization to provide access service and
uses accounting to collect and record usage of network resources by users.
I. Client/server model
l
Client: The RADIUS client runs on the NASs
located throughout the network. It passes user information to designated RADIUS
servers and acts on the response (for example, rejects or accepts user access
requests).
l
Server: The RADIUS server runs on the computer
or workstation at the network center and maintains information related to user
authentication and network service access. It authenticates a user after
receiving a connection request and returns the processing result (for example,
rejecting or accepting user access requests) to the client.
In general, the RADIUS server maintains
three databases, namely, Users, Clients, and Dictionary, as shown in Figure 1-2:
Figure 1-2 RADIUS server components
l
Users: Stores user information such as the
username, password, applied protocols, and IP address.
l
Clients: Stores information about RADIUS clients
such as the shared keys and IP addresses.
l
Dictionary: Stores the information for
interpreting RADIUS protocol attributes and their values.
II. Security authentication
mechanism
Information exchanged between the RADIUS
client and the RADIUS server is authenticated with a shared key, which is never
transmitted over the network, thus enhancing the security of information
exchange. To prevent user passwords from being intercepted in non-secure
networks, the passwords are encrypted during transmission.
A RADIUS server supports multiple user
authentication methods, such as the Password Authentication Protocol (PAP) and
Challenge Handshake Authentication Protocol (CHAP) of Point-to-Point Protocol
(PPP). In addition, a RADIUS server can act as the client of another AAA server
to provide proxy authentication or accounting service.
III. Basic message exchange
process of RADIUS
For the interaction among the host, the
RADIUS client, and the RADIUS server, see Figure 1-3.
Figure 1-3 Basic message exchange
process of RADIUS
The following is how RADIUS operates:
1)
The host initiates a connection request carrying
the username and password to the RADIUS client.
2)
Having received the username and password, the
RADIUS client sends an authentication request (Access-Request) to the RADIUS
server, where the user password is encrypted by the Message-Digest 5 (MD5)
algorithm with the shared key.
3)
The RADIUS server authenticates the username and
password. If the authentication succeeds, it sends back an Access-Accept
message containing the information of user’s right. If the authentication
fails, it returns an Access-Reject message.
4)
The RADIUS client accepts or denies the user
according to the returned authentication result. If it accepts the user, it
sends a start-accounting request (Accounting-Request) to the RADIUS server.
5)
The RADIUS server returns a start-accounting
response (Accounting-Response) and starts accounting.
6)
The subscriber accesses the network resources.
7)
The host requests the RADIUS client to tear down
the connection and the RADIUS client sends a stop-accounting request
(Accounting-Request) to the RADIUS server.
8)
The RADIUS server returns a stop-accounting
response (Accounting-Response) and stops accounting.
9)
The subscriber stops network resource accessing.
IV. RADIUS packet structure
RADIUS uses UDP to transmit messages. It
ensures the smooth message exchange between the RADIUS server and the client
through a series of mechanisms, including the timer management mechanism,
retransmission mechanism, and slave server mechanism. Figure 1-4
shows the RADIUS packet structure.
Figure 1-4 RADIUS packet structure
Descriptions of fields are as follows:
1)
The Code field (1-byte long) is for indicating
the type of the RADIUS packet. Table 1-1 gives the possible values and
their meanings.
Table 1-1 Main values of the Code field
|
Code
|
Packet type
|
Description
|
|
1
|
Access-Request
|
From the client to the server. A packet
of this type carries user information for the server to authenticate the
user. It must contain the User-Name attribute and can optionally contain the
attributes of NAS-IP-Address, User-Password, and NAS-Port.
|
|
2
|
Access-Accept
|
From the server to the client. If all the
attribute values carried in the Access-Request are acceptable, that is, the
authentication succeeds, the server sends an Access-Accept response.
|
|
3
|
Access-Reject
|
From the server to the client. If any
attribute value carried in the Access-Request is unacceptable, the server
rejects the user and sends an Access-Reject response.
|
|
4
|
Accounting-Request
|
From the client to the server. A packet
of this type carries user information for the server to start/stop accounting
on the user. It contains the Acct-Status-Type attribute, which indicates
whether the server is requested to start the accounting or to end the
accounting.
|
|
5
|
Accounting-Response
|
From the server to the client. The server
sends to the client a packet of this type to notify that it has received the
Accounting-Request and has correctly recorded the accounting information.
|
2)
The Identifier field (1-byte long) is for
matching request packets and response packets and detecting retransmitted
request packets. The request and response packets of the same type have the
same identifier.
3)
The Length field (2-byte long) indicates the
length of the entire packet, including the Code, Identifier, Length,
Authenticator, and Attribute fields. The value of the field is in the range 20
to 4096. Bytes beyond the length are considered the padding and are neglected
after being received. If the length of a received packet is less than that
indicated by the Length field, the packet is dropped.
4)
The Authenticator field (16-byte long) is used
to authenticate the reply from the RADIUS server, and is also used in the
password hiding algorithm. There are two kinds of authenticators: Request
authenticator and Response authenticator.
5)
The Attribute field carries information about
the configuration details of a request or response. This field is represented
in triplets of Type, Length, and Value.
l
Type: One byte, in the range 1 to 255. It
indicates the type of the attribute. Commonly used attributes for RADIUS
authentication and authorization are listed in Table 1-2.
l
Length: One byte for indicating the length of
the attribute in bytes, including the Type, Length, and Value fields.
l
Value: Value of the attribute, up to 253 bytes.
Its format and content depend on the Type and Length fields.
Table 1-2 RADIUS
attributes
|
No.
|
Attribute type
|
No.
|
Attribute type
|
|
1
|
User-Name
|
45
|
Acct-Authentic
|
|
2
|
User-Password
|
46
|
Acct-Session-Time
|
|
3
|
CHAP-Password
|
47
|
Acct-Input-Packets
|
|
4
|
NAS-IP-Address
|
48
|
Acct-Output-Packets
|
|
5
|
NAS-Port
|
49
|
Acct-Terminate-Cause
|
|
6
|
Service-Type
|
50
|
Acct-Multi-Session-Id
|
|
7
|
Framed-Protocol
|
51
|
Acct-Link-Count
|
|
8
|
Framed-IP-Address
|
52
|
Acct-Input-Gigawords
|
|
9
|
Framed-IP-Netmask
|
53
|
Acct-Output-Gigawords
|
|
10
|
Framed-Routing
|
54
|
(unassigned)
|
|
11
|
Filter-ID
|
55
|
Event-Timestamp
|
|
12
|
Framed-MTU
|
56-59
|
(unassigned)
|
|
13
|
Framed-Compression
|
60
|
CHAP-Challenge
|
|
14
|
Login-IP-Host
|
61
|
NAS-Port-Type
|
|
15
|
Login-Service
|
62
|
Port-Limit
|
|
16
|
Login-TCP-Port
|
63
|
Login-LAT-Port
|
|
17
|
(unassigned)
|
64
|
Tunnel-Type
|
|
18
|
Reply_Message
|
65
|
Tunnel-Medium-Type
|
|
19
|
Callback-Number
|
66
|
Tunnel-Client-Endpoint
|
|
20
|
Callback-ID
|
67
|
Tunnel-Server-Endpoint
|
|
21
|
(unassigned)
|
68
|
Acct-Tunnel-Connection
|
|
22
|
Framed-Route
|
69
|
Tunnel-Password
|
|
23
|
Framed-IPX-Network
|
70
|
ARAP-Password
|
|
24
|
State
|
71
|
ARAP-Features
|
|
25
|
Class
|
72
|
ARAP-Zone-Access
|
|
26
|
Vendor-Specific
|
73
|
ARAP-Security
|
|
27
|
Session-Timeout
|
74
|
ARAP-Security-Data
|
|
28
|
Idle-Timeout
|
75
|
Password-Retry
|
|
29
|
Termination-Action
|
76
|
Prompt
|
|
30
|
Called-Station-Id
|
77
|
Connect-Info
|
|
31
|
Calling-Station-Id
|
78
|
Configuration-Token
|
|
32
|
NAS-Identifier
|
79
|
EAP-Message
|
|
33
|
Proxy-State
|
80
|
Message-Authenticator
|
|
34
|
Login-LAT-Service
|
81
|
Tunnel-Private-Group-id
|
|
35
|
Login-LAT-Node
|
82
|
Tunnel-Assignment-id
|
|
36
|
Login-LAT-Group
|
83
|
Tunnel-Preference
|
|
37
|
Framed-AppleTalk-Link
|
84
|
ARAP-Challenge-Response
|
|
38
|
Framed-AppleTalk-Network
|
85
|
Acct-Interim-Interval
|
|
39
|
Framed-AppleTalk-Zone
|
86
|
Acct-Tunnel-Packets-Lost
|
|
40
|
Acct-Status-Type
|
87
|
NAS-Port-Id
|
|
41
|
Acct-Delay-Time
|
88
|
Framed-Pool
|
|
42
|
Acct-Input-Octets
|
89
|
(unassigned)
|
|
43
|
Acct-Output-Octets
|
90
|
Tunnel-Client-Auth-id
|
|
44
|
Acct-Session-Id
|
91
|
Tunnel-Server-Auth-id
|
The attribute types
listed in Table 1-2 are defined by RFC 2865, RFC 2866, RFC 2867, and RFC 2568.
V. RADIUS extended attributes
The RADIUS protocol features excellent
extensibility. Attribute 26 (Vender-Specific) defined by RFC 2865 allows a vender
to define extended attributes to implement functions that the standard RADIUS
protocol does not provide.
A vendor can encapsulate multiple
type-length-value (TLV) sub-attributes in RADIUS packets for extension in
applications. As shown in Figure
1-5, a sub-attribute that can be encapsulated in
Attribute 26 consists of the following four parts:
l
Vendor-ID (four bytes): Indicates the ID of the
vendor. Its most significant byte is 0 and the other three bytes contain a code
complying with RFC 1700. The vendor ID of H3C is 2011.
l
Vendor-Type: Indicates the type of the
sub-attribute.
l
Vendor-Length: Indicates the length of the
sub-attribute.
l
Vendor-Data: Indicates the contents of the
sub-attribute.
Figure 1-5 Segment of a RADIUS packet
containing an extended attribute
1.1.3 Introduction to HWTACACS
Huawei Terminal
Access Controller Access Control System (HWTACACS) is an enhanced security
protocol based on TACACS (RFC 1492). Similar to RADIUS, it uses the
server/client model for information exchange between NAS and HWTACACS server.
HWTACACS implements AAA mainly for such
users as Point-to-Point Protocol (PPP) users, Virtual Private Dial-up Network
(VPDN) users, and terminal users. In a typical HWTACACS application, a terminal
user needs to log onto the device for operations. Working as the HWTACACS
client, the device sends the username and password to the HWTACACS sever for
authentication. After passing authentication and being authorized, the user can
log into the device to perform operations.
I. Differences between HWTACACS
and RADIUS
HWTACACS and RADIUS have many common
features, like implementing AAA, using a client/server model, using shared keys
for user information security and having good flexibility and extensibility.
Meanwhile, they also have differences, as listed in Table 1-3.
Table 1-3 Primary differences between HWTACACS and RADIUS
|
HWTACACS
|
RADIUS
|
|
Uses TCP, providing more reliable network
transmission
|
Uses UDP, providing higher transport
efficiency
|
|
Encrypts the entire packet except for the
HWTACACS header
|
Encrypts only the password field in an
authentication packet
|
|
Protocol packets are complicated and
authorization is independent of authentication. Authentication and
authorization can be deployed on different HWTACACS servers.
|
Protocol packets are simple and
authorization is combined with authentication.
|
|
Supports authorized use of configuration
commands. For example, an authenticated login user can be authorized to
configure the device.
|
Does not support authorized use of
configuration commands.
|
II. Basic message exchange process
of HWTACACS
The following takes Telnet user as an
example to describe how HWTACACS performs user authentication, authorization,
and accounting. Figure 1-6 illustrates the basic message exchange process of HWTACACS.
Figure 1-6 Basic message exchange
process of HWTACACS for a Telnet user
1)
A Telnet user applies to access the NAS.
2)
Upon receiving the request, the HWTACACS client
sends a start-authentication packet to the HWTACACS server.
3)
The HWTACACS server sends back an authentication
response requesting the username.
4)
Upon receiving the request, the HWTACACS client
asks the user for the username.
5)
The user enters the username.
6)
After receiving the username from the user, the
HWTACACS client sends to the server a continue-authentication packet carrying
the username.
7)
The HWTACACS server sends back an authentication
response, requesting the login password.
8)
Upon receipt of the response, the HWTACACS
client requests of the user the login password.
9)
The user enters the password.
10)
After receiving the login password, the HWTACACS
client sends to the HWTACACS server a continue-authentication packet carrying
the login password.
11)
The HWTACACS server sends back an authentication
response indicating that the user has passed authentication.
12)
The HWTACACS client sends the user authorization
request packet to the HWTACACS server.
13)
The HWTACACS server sends back the authorization
response, indicating that the user is authorized now.
14)
Knowing that the user is now authorized, the
HWTACACS client pushes the configuration interface of the NAS to the user.
15)
The HWTACACS client sends a start-accounting
request to the HWTACACS server.
16)
The HWTACACS server sends back an accounting
response, indicating that it has received the start-accounting request.
17)
The user logs off.
18)
The HWTACACS client sends a stop-accounting
request to the HWTACACS server.
19)
The HWTACACS server sends back a stop-accounting
packet, indicating that the stop-accounting request has been received.
The protocols and standards related to AAA,
RADIUS, and HWTACACS include:
l
RFC 2865: Remote Authentication Dial In User
Service (RADIUS)
l
RFC 2866: RADIUS Accounting
l
RFC 2867: RADIUS Accounting Modifications for
Tunnel Protocol Support
l
RFC 2868: RADIUS Attributes for Tunnel Protocol
Support
l
RFC 2869: RADIUS Extensions
l
RFC 1492: An Access Control Protocol, Sometimes
Called TACACS
I. AAA configuration task list
II. RADIUS configuration task list
