Chapter 1 AAA & RADIUS & HWTACACS Configuration
AAA is an acronym for the three security
functions: authentication, authorization and accounting. It provides a uniform
framework for you to configure the three security functions to implement
network security management.
The network security mentioned here mainly refers
to access control. It mainly controls:
l
Which users can access the network,
l
Which services are available to the users who
can access the network, and
l
How to charge the users who are using network resources.
Accordingly, AAA provides the following three
functions:
I. Authentication
AAA supports the following authentication
methods:
l
None authentication: Users are trusted and are
not checked for their validity. Generally, this method is not recommended.
l
Local authentication: User information
(including user name, password, and some other attributes) is configured on this
device, and users are authenticated on this device instead of on a remote
device. Local authentication is fast and requires lower operational cost, but has
the deficiency that information storage capacity is limited by device hardware.
l
Remote authentication: Users are authenticated
remotely through RADIUS or HWTACACS protocol. This device (for example, a H3C
series switch) acts as the client to communicate with the RADIUS or TACACS
server. For RADIUS protocol, you can use extended RADIUS protocol as well as
standard RADIUS protocol.
II. Authorization
AAA supports the following authorization
methods:
l
Direct authorization: Users are trusted and directly
authorized.
l
Local authorization: Users are authorized
according to the related attributes configured for their local accounts on this
device.
l
RADIUS authorization: Users are authorized after
they pass RADIUS authentication. In RADIUS protocol, authentication and
authorization are combined together, and authorization cannot be performed alone
without authentication.
l
HWTACACS authorization: Users are authorized by a
TACACS server.
III. Accounting
AAA supports the following accounting
methods:
l
None accounting: No accounting is performed for
users.
l
Remote accounting: User accounting is performed
on a remote RADIUS or TACACS server.
Generally, AAA adopts client/server structure,
where the client acts as the managed resource and the server stores user
information. This structure has good scalability and facilitates the
centralized management of user information.
An Internet service provider (ISP) domain
is a group of users who belong to the same ISP. For a user name in the format
of userid@isp-name, the isp-name following the "@" character
is the ISP domain name. The access device uses userid as the user name for
authentication, and isp-name as the domain name.
In a multi-ISP environment, the users
connected to the same access device may belong to different domains. Since the
users of different ISPs may have different attributes (such as different forms
of user name and password, different service types/access rights), it is
necessary to distinguish the users by setting ISP domains.
You can configure a set of ISP domain
attributes (including AAA policy, RADIUS scheme, and so on) for each ISP domain
independently in ISP domain view.
AAA is a management framework. It can be
implemented by not only one protocol. But in practice, the most commonly used
protocol for AAA is RADIUS.
I. What is RADIUS
RADIUS (remote authentication dial-in user service)
is a distributed information exchange protocol based on client/server structure.
It can prevent unauthorized access to your network and is commonly used in
network environments where both high security and remote user access service are
required.
The RADIUS service involves three
components:
l
Protocol: Based on the UDP/IP layer, RFC 2865
and 2866 define the message format and message transfer mechanism of RADIUS,
and define 1812 as the authentication port and 1813 as the accounting port.
l
Server: RADIUS Server runs on a computer or
workstation at the center. It stores and maintains user authentication information
and network service access information.
l
Client: RADIUS Client runs on dial-in access
server devices throughout the network.
RADIUS is based on client/server model. A
switch acting as a RADIUS client passes user information to a specified RADIUS
server, and takes appropriate action (such as establishing/terminating user
connection) depending on the responses returned from the server. The RADIUS
server receives user connection requests, authenticates users, and returns all required
information to the switch.
Generally, a RADIUS server maintains the
following three databases (see Figure 1-1):
l
Users: This database stores information about users
(such as user name, password, protocol adopted and IP address).
l
Clients: This database stores information about
RADIUS clients (such as shared key).
l
Dictionary: The information stored in this
database is used to interpret the attributes and attribute values in the RADIUS
protocol.
Figure 1-1 Databases in a RADIUS server
In addition, a RADIUS server can act as a
client of some other AAA server to provide authentication or accounting proxy service.
II. Basic message exchange
procedure in RADIUS
The messages exchanged between a RADIUS
client (a switch, for example) and a RADIUS server are verified through a
shared key. This enhances the security. The RADIUS protocol combines the
authentication and authorization processes together by sending authorization
information along with the authentication response message. Figure 1-2 depicts the message exchange procedure between user, switch and RADIUS server.
Figure 1-2 Basic message exchange
procedure of RADIUS
The basic message exchange procedure of
RADIUS is as follows:
1)
The user enters the user name and password.
2)
The RADIUS client receives the user name and
password, and then sends an authentication request (Access-Request) to the
RADIUS server.
3)
The RADIUS server compares the received user
information with that in the Users database to authenticate the user. If the
authentication succeeds, the RADIUS server sends back to the RADIUS client an
authentication response (Access-Accept), which contains the user’s access
right information. If the authentication fails, the server returns an
Access-Reject response.
4)
The RADIUS client accepts or denies the user
depending on the received authentication result. If it accepts the user, the
RADIUS client sends a start-accounting request (Accounting-Request, with the
Status-Type attribute value = start) to the RADIUS server.
5)
The RADIUS server returns a start-accounting
response (Accounting-Response).
6)
The user starts to access network resources.
7)
The RADIUS client sends a stop-accounting
request (Accounting-Request, with the Status-Type attribute value = stop) to
the RADIUS server.
8)
The RADIUS server returns a stop-accounting response
(Accounting-Response).
9)
The access to network resources is ended.
III. RADIUS message format
RADIUS messages are transported over UDP,
which does not guarantee reliable delivery of messages between RADIUS server
and client. As a remedy, RADIUS adopts the following mechanisms: timer
management, retransmission, and backup server. Figure
1-3 depicts the format of RADIUS messages.
Figure 1-3 RADIUS message format
1)
The Code field (one byte) decides the type of
RADIUS message, as shown in Table 1-1.
Table 1-1 Description
on the major values of the Code field
|
Code
|
Message type
|
Message description
|
|
1
|
Access-Request
|
Direction: client->server.
The client transmits this message to the
server to determine if the user can access the network.
This message carries user information.
It must contain the User-Name attribute and may contain the following
attributes: NAS-IP-Address, User-Password and NAS-Port.
|
|
2
|
Access-Accept
|
Direction: server->client.
The server transmits this message to
the client if all the attribute values carried in the Access-Request message are
acceptable (that is, the user passes the authentication).
|
|
3
|
Access-Reject
|
Direction: server->client.
The server transmits this message to
the client if any attribute value carried in the Access-Request message is
unacceptable (that is, the user fails the authentication).
|
|
4
|
Accounting-Request
|
Direction: client->server.
The client transmits this message to
the server to request the server to start or end the accounting (whether to
start or to end the accounting is determined by the Acct-Status-Type
attribute in the message).
This message carries almost the same
attributes as those carried in the Access-Request message.
|
|
5
|
Accounting-Response
|
Direction: server->client.
The server transmits this message to
the client to notify the client that it has received the Accounting-Request message
and has correctly recorded the accounting information.
|
2)
The Identifier field (one byte) is used to match
requests and responses. It changes whenever the content of the Attributes field
change, and whenever a valid response has been received for a previous request,
but remains unchanged for message retransmission.
3)
The Length field (two bytes) specifies the total
length of the message (including the Code, Identifier, Length, Authenticator
and Attributes fields). The bytes beyond the length are regarded as padding and
are ignored upon reception. If a received message is shorter than what the
Length field indicates, it is discarded.
4)
The Authenticator field (16 bytes) is used to authenticate
the response from the RADIUS server; and is used in the password hiding
algorithm. There are two kinds of authenticators: Request Authenticator and
Response Authenticator.
5)
The Attributes field contains specific
authentication/authorization/accounting information to provide the
configuration details of a request or response message. This field contains a
list of field triplet (Type, Length and Value):
l
The Type field (one byte) specifies the type of an
attribute. Its value ranges from 1 to 255. Table 1-2 lists the attributes that are commonly used in RADIUS authentication/authorization.
l
The Length field (one byte) specifies the total
length of the attribute in bytes (including the Type, Length and Value fields).
l
The Value field (up to 253 bytes) contains the
information of the attribute. Its format is determined by the Type and Length
fields.
Table 1-2 RADIUS
attributes
|
Type field value
|
Attribute type
|
Type field value
|
Attribute type
|
|
1
|
User-Name
|
23
|
Framed-IPX-Network
|
|
2
|
User-Password
|
24
|
State
|
|
3
|
CHAP-Password
|
25
|
Class
|
|
4
|
NAS-IP-Address
|
26
|
Vendor-Specific
|
|
5
|
NAS-Port
|
27
|
Session-Timeout
|
|
6
|
Service-Type
|
28
|
Idle-Timeout
|
|
7
|
Framed-Protocol
|
29
|
Termination-Action
|
|
8
|
Framed-IP-Address
|
30
|
Called-Station-Id
|
|
9
|
Framed-IP-Netmask
|
31
|
Calling-Station-Id
|
|
10
|
Framed-Routing
|
32
|
NAS-Identifier
|
|
11
|
Filter-ID
|
33
|
Proxy-State
|
|
12
|
Framed-MTU
|
34
|
Login-LAT-Service
|
|
13
|
Framed-Compression
|
35
|
Login-LAT-Node
|
|
14
|
Login-IP-Host
|
36
|
Login-LAT-Group
|
|
15
|
Login-Service
|
37
|
Framed-AppleTalk-Link
|
|
16
|
Login-TCP-Port
|
38
|
Framed-AppleTalk-Network
|
|
17
|
(unassigned)
|
39
|
Framed-AppleTalk-Zone
|
|
18
|
Reply-Message
|
40-59
|
(reserved for accounting)
|
|
19
|
Callback-Number
|
60
|
CHAP-Challenge
|
|
20
|
Callback-ID
|
61
|
NAS-Port-Type
|
|
21
|
(unassigned)
|
62
|
Port-Limit
|
|
22
|
Framed-Route
|
63
|
Login-LAT-Port
|
The RADIUS protocol has good scalability.
Attribute 26 (Vender-Specific) defined in this protocol allows a device vendor
to extend RADIUS to implement functions that are not defined in standard
RADIUS.
Figure 1-4 depicts the format of attribute 26. The Vendor-ID field used to identify a vendor occupies four bytes, where the first byte is 0, and the other three bytes are defined in RFC 1700. Here, the vendor can encapsulate
multiple customized sub-attributes (containing vendor-specific Type, Length and
Value) to implement a RADIUS extension.
Figure 1-4 Vendor-specific attribute
format
I. What is HWTACACS
HWTACACS (Huawei terminal access controller
access control system) is an enhanced security protocol
based on TACACS (RFC 1492). Similar to the RADIUS protocol, it implements AAA
for different types of users (such as PPP, VPDN, and terminal users) through
communicating with TACACS server in client-server mode.
Compared with RADIUS, HWTACACS provides
more reliable transmission and encryption, and therefore is more suitable for
security control. Table 1-3 lists the primary differences between HWTACACS and RADIUS.
Table 1-3 Differences between HWTACACS and RADIUS
|
HWTACACS
|
RADIUS
|
|
Adopts TCP, providing more reliable
network transmission.
|
Adopts UDP.
|
|
Encrypts the entire message except
the HWTACACS header.
|
Encrypts only the password field in
authentication message.
|
|
Separates authentication from
authorization. For example, you can use one TACACS server for authentication
and another TACACS server for authorization.
|
Combines authentication and
authorization.
|
|
Is more suitable for security
control.
|
Is more suitable for accounting.
|
|
Supports configuration command authorization.
|
Does not support.
|
In a typical HWTACACS application (as shown
in Figure 1-5), a dial-up or terminal user needs to log into the switch to perform some operations. As a HWTACACS client, the switch sends the username and password to the TACACS server for authentication. After passing
authentication and being authorized, the user successfully logs into the switch
to perform operations.
Figure 1-5 Network diagram for a typical HWTACACS application
II. Basic message exchange
procedure in HWTACACS
The following text takes telnet user as an
example to describe how HWTACACS implements authentication, authorization, and
accounting for a user. Figure
1-6 illustrates the basic message exchange procedure:
Figure 1-6 AAA implementation procedure for a telnet user
The basic message exchange procedure is as
follows:
1)
A user sends a login request to the switch
acting as a TACACS client, which then sends an authentication start request to the
TACACS.
2)
The TACACS server returns an authentication
response, asking for the username. Upon receiving the response, the TACACS
client requests the user for the username.
3)
After receiving the username from the user, the
TACACS client sends an authentication continuance message carrying the
username.
4)
The TACACS server returns an authentication
response, asking for the password. Upon receiving the response, the TACACS
client requests the user for the login password.
5)
After receiving the password, the TACACS client
sends an authentication continuance message carrying the password to the TACACS
server.
6)
The TACACS server returns an authentication
response, indicating that the user has passed the authentication.
7)
The TACACS client sends a user authorization
request to the TACACS server.
8)
The TACACS server returns an authorization
response, indicating that the user has passed the authorization.
9)
After receiving the response indicating an
authorization success, the TACACS client pushes the configuration interface of
the switch to the user.
10)
The TACACS client sends an accounting start
request to the TACACS server.
11)
The TACACS server returns an accounting response,
indicating that it has received the accounting start request.
12)
The user logs out; the TACACS client sends an
accounting stop request to the TACACS server.
13)
The TACACS server returns an accounting response,
indicating that it has received the accounting stop request.
1.2 Configuration Task
Table 1-4 Configuration tasks
The purpose of AAA configuration is to provide
network access services to legal users and at the same time protect your network
device against unauthorized access. If you need to use ISP domains to implement
AAA management on access users, you should first configure ISP domains.
If you want to adopt remote AAA method, you
must first create a RADIUS or HWTACACS scheme.
l
RADIUS scheme (radius-scheme): You can
reference a configured RADIUS scheme to provide AAA services. For the
configuration of RADIUS scheme, refer to section 1.4 "RADIUS Configuration".
l
HWTACACS scheme (hwtacacs-scheme): You
can reference a configured HWTACACS scheme to implement AAA services. For the
configuration of HWTACACS scheme, refer to section 1.5
"HWTACACS Configuration".
1.3.2 Creating an ISP Domain
Table 1-5 Create an ISP domain
|
Operation
|
Command
|
Description
|
|
Enter
system view
|
system-view
|
—
|
|
Create an ISP domain and enter its
view, enter the view of an existing ISP domain, or set an ISP domain as the
default ISP domain
|
domain
{ isp-name | default { disable | enable
isp-name } }
|
Required
If no ISP domain is set as the
default ISP domain, the ISP domain "system" is used as the default
ISP domain.
|
Table 1-6 Configure the attributes of an
ISP domain
|
Operation
|
Command
|
Description
|
|
Enter system view
|
