Chapter 1 AAA & RADIUS & HWTACACS
Configuration
AAA is shortened from the three security
functions: authentication, authorization and accounting. It provides a uniform
framework for you to configure the three security functions to implement the 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 the users can have access to,
l
How to charge the users who are using network
resources.
Accordingly, AAA provides the following
services:
I. Authentication
AAA supports the following authentication
methods:
l
None authentication: Users are trusted and are
not authenticated. Generally, this method is not recommended.
l
Local authentication: User information
(including user name, password, and attributes) is configured on this device.
Local authentication is fast and requires lower operational cost. But the
information storage capacity is limited by device hardware.
l
Remote authentication: Users are authenticated
remotely through the RADIUS protocol or HWTACACS protocol. This device (for
example, a H3C series switch) acts as the client to communicate with the RADIUS
server or TACACS server. For RADIUS protocol, both standard and extended RADIUS
protocols can be used.
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 the device.
l
RADIUS authorization: Users are authorized after
they pass the RADIUS authentication. The authentication and authorization of
RADIUS protocol are bound together, and you cannot perform RADIUS authorization
alone without RADIUS authentication.
l
HWTACACS authorization: Users are authorized by
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 the remote RADIUS server or TACACS server.
Generally, AAA adopts the 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 compositions
of user name and password, different service types/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 in client/server structure. It
can prevent unauthorized access to the 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 frame format and message transfer mechanism of RADIUS, and define
1812 as the authentication port and 1813 as the accounting port.
l
Server: The RADIUS server runs on a computer or
workstation at the center. It stores and maintains the information on user
authentication and network service access.
l
Client: The RADIUS clients run on the dial-in
access server device. They can be deployed anywhere in the network.
RADIUS is based on client/server model.
Acting as a RADIUS client, the switch passes user information to a designated
RADIUS server, and makes processing (such as connecting/disconnecting users)
depending on the responses returned from the server. The RADIUS server receives
user's connection requests, authenticates users, and returns all required
information to the switch.
Generally, the RADIUS server maintains the
following three databases (as shown in Figure 1-1):
l
Users: This database stores information about
users (such as user name, password, adopted protocol and IP address).
l
Clients: This database stores the information
about RADIUS clients (such as shared keys).
l
Dictionary: This database stores the information
used to interpret the attributes and attribute values of the RADIUS protocol.
Figure 1-1
Databases in RADIUS server
In addition, the RADIUS server can act as
the client of some other AAA server to provide the authentication or accounting
proxy service.
II. Basic message exchange
procedure of RADIUS
The messages exchanged between a RADIUS
client (a switch, for example) and the RADIUS server are verified by using a
shared key. This enhances the security. The RADIUS protocol combines the
authentication and authorization processes together by sending authorization
information in 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 an authentication
response (Access-Accept), which contains the information of user’s rights,
to the RADIUS client. If the authentication fails, it 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 filed set to “start”) to the RADIUS server.
5)
The RADIUS server returns a start-accounting
response (Accounting-Response).
6)
The user starts to access the resources.
7)
The RADIUS client sends a stop-accounting
request (Accounting-Request, with the Status-Type field set to
“stop”) to the RADIUS server.
8)
The RADIUS server returns a stop-accounting response
(Accounting-Response).
9)
The resource access of the user is ended.
III. RADIUS packet structure
RADIUS uses UDP to transmit messages. It
ensures the correct message exchange between RADIUS server and client through
the following mechanisms: timer management, retransmission, and backup server. Figure 1-3 depicts the structure of the RADIUS packets.
Figure 1-3 RADIUS packet structure
1)
The Code field decides the type of the RADIUS
packet, as shown in Table 1-1.
Table 1-1 Description on major values of the Code field
|
Code
|
Packet type
|
Packet description
|
|
1
|
Access-Request
|
Direction: client->server
The client sends this packet to the
server to determine if the user can access the network.
This packet 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 sends this packet to the
client if all the attribute values carried in the Access-Request packet are
acceptable (that is, the user passes the authentication).
|
|
3
|
Access-Reject
|
Direction: server->client
The server sends this packet to the
client if any attribute value carried in the Access-Request packet is
unacceptable (that is, the user fails the authentication).
|
|
4
|
Accounting-Request
|
Direction: client->server
The client sends this packet 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 packet).
This packet carries almost the same
attributes as those carried in the Access-Request packet.
|
|
5
|
Accounting-Response
|
Direction: server->client
The server sends this packet to the
client to notify the client that it has received the Accounting-Request packet
and has correctly recorded the accounting information.
|
|
11
|
Access-Challenge
|
Direction: server->client
The server sends the Access-Challenge
packet to the client if it needs to verify the key of the client.
|
2)
The Identifier field (one byte) identifies the
request and response packets. It is subject to the Attribute field and varies
with the received valid responses, but keeps unchanged during retransmission.
3)
The Length field (two bytes) specifies the total
length of the packet (including the Code, Identifier, Length, Authenticator and
Attribute fields). The bytes beyond the length will be regarded as padding bytes
and are ignored upon receiving the packet. If the received packet is shorter
than the value of this field, it will be discarded.
4)
The Authenticator field (16 bytes) is used to verify
the packet returned from the RADIUS server; it is also used in the password hiding
algorithm. There are two kinds of authenticators: Request and Response.
5)
The Attribute field contains special
authentication, authorization, and accounting information to provide the
configuration details of a request or response packet. This field is
represented by a field triplet (Type, Length and Value):
l
The Type field (one byte) specifies the type of
the attribute. Its value ranges from 1 to 255. Table
1-2 lists the attributes that are commonly used in RADIUS authentication and authorization.
l
The Length field (one byte) specifies the total
length of the Attribute field in bytes (including the Type, Length and Value
fields).
l
The Value field (up to 253 bytes) contains the
information about the attribute. Its content and format are determined by the
Type and Length fields.
Table 1-2 RADIUS attributes
|
Value of the Type field
|
Attribute type
|
Value of the Type field
|
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 takes 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 structure of attribute 26. The Vendor-ID field representing the code of the vendor occupies four bytes. The first byte is 0, and the other three bytes are defined in RFC1700. Here, the vendor can encapsulate
multiple customized sub-attributes (containing Type, Length and Value) to
obtain extended RADIUS implementation.
Figure 1-4 Part of the RADIUS packet containing extended attribute
I. What is HWTACACS
HUAWEI Terminal Access Controller Access
Control System (HWTACACS) is an enhanced security
protocol based on TACACS (RFC1492). Similar to the RADIUS protocol, it
implements AAA for different types of users (such as PPP/VPDN login users and
terminal users) through communications with TACACS servers in the 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 protocols.
Table 1-3 Comparison between HWTACACS
and RADIUS
|
HWTACACS
|
RADIUS
|
|
Adopts TCP, providing more reliable
network transmission.
|
Adopts UDP.
|
|
Encrypts the entire packet except the
HWTACACS header.
|
Encrypts only the password field in
authentication packets.
|
|
Separates authentication from
authorization. For example, you can provide authentication and authorization
on different TACACS servers.
|
Brings together authentication and
authorization.
|
|
Suitable for security control.
|
Suitable for accounting.
|
|
Supports to authorize the use of
configuration commands.
|
Not support.
|
In a typical HWTACACS application, a
dial-up or terminal user needs to log in to the device for operations. As the
client of HWTACACS in this case, the switch sends the username and password to
the TACACS server for authentication. After passing authentication and being
authorized, the user can log in to the switch to perform operations, as shown
in Figure 1-5.
Figure 1-5 Network diagram for a typical
HWTACACS application
II. Basic message exchange
procedure in HWTACACS
For example, use HWTACACS to implement
authentication, authorization, and accounting for a telnet user. Figure 1-6 illustrates the basic message exchange procedure:
Figure 1-6 The AAA implementation
procedure for a telnet user
The basic message exchange procedure is as
follows:
1)
A user requests access to the switch; the TACACS
client sends an authentication start request packet to TACACS server upon
receipt of the request.
2)
The TACACS server sends back an authentication
response requesting for the username; the TACACS client asks the user for the
username upon receipt of the response.
3)
The TACACS client sends an authentication
continuance packet carrying the username after receiving the username from the
user.
4)
The TACACS server sends back an authentication
response, requesting for the password. Upon receipt of the response, the TACACS
client requests the user for the login password.
5)
After receiving the login password, the TACACS
client sends an authentication continuance packet carrying the login password
to the TACACS server.
6)
The TACACS server sends back an authentication
response indicating that the user has passed the authentication.
7)
The TACACS client sends the user authorization
request packet to the TACACS server.
8)
The TACACS server sends back the authorization
response, indicating that the user has passed the authorization.
9)
Upon receipt of 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 packet to the TACACS server.
11)
The TACACS server sends back 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 sends back an accounting stop
packet, indicating that the accounting stop request has been received.
1.2 Configuration Tasks
Table 1-4 Configuration
tasks
|
Operation
|
Description
|
Related section
|
|
AAA
configuration
|
Create
an ISP domain
|
Required
|
Section
1.3.2
|
|
Configure
the attributes of the ISP domain
|
Optional
|
Section
1.3.3
|
|
Configure
an AAA scheme for the ISP domain
|
Required
If
local authentication is adopted, refer to section 1.3.6 “Configuring
the Attributes of a Local User”.
If
RADIUS authentication is adopted, refer to section 1.4 “RADIUS Configuration”.
|
Section
1.3.4
|
|
Configure
dynamic VLAN assignment
|
Optional
|
Section
1.3.5
|
|
Configure the attributes of a local
user
|
Optional
|
Section 1.3.6
|
|
Cut down user connections forcibly
|
Optional
|
Section 1.3.7
|
|
RADIUS
configuration
|
Create
a RADIUS scheme
|
Required
|
Section
1.4.1
|
|
Configure
RADIUS authentication/authorization servers
|
Required
|
Section
1.4.2
|
|
Configure
RADIUS accounting servers
|
Required
|
Section
1.4.3
|
|
Configure
shared keys for RADIUS packets
|
Optional
|
Section
1.4.4
|
|
Configure
the maximum number of transmission attempts of RADIUS requests
|
Optional
|
Section
1.4.5
|
|
Configure
the supported RADIUS server type
|
Optional
|
Section
1.4.6
|
|
Configure the status of RADIUS servers
|
Optional
|
Section 1.4.7
|
|
Configure the attributes for data to
be sent to RADIUS servers
|
Optional
|
Section 1.4.8
|
|
Configure a local RADIUS
authentication server
|
Optional
|
Section 1.4.9
|
|
Configure the timers for RADIUS
servers
|
Optional
|
Section 1.4.10
|
|
Configure whether or not to send trap
message when RADIUS server is down
|
Optional
|
Section 1.4.11
|
|
Configure the user re-authentication
upon device restart function
|
Optional
|
Section 1.4.12
|
|
HWTACACS
configuration
|
Create
a HWTACAS scheme
|
Required
|
Section
1.5.1
|
|
Configure
HWTACACS authentication servers
|
Required
|
Section
1.5.2
|
|
Configure
HWTACACS authorization servers
|
Required
|
Section
1.5.3
|
|
Configure
HWTACACS accounting servers
|
Optional
|
Section
1.5.4
|
|
Configure
shared keys for HWTACACS packets
|
Optional
|
Section
1.5.5
|
|
Configure
the attributes for data to be sent to TACACS servers
|
Optional
|
Section
1.5.6
|
|
Configure the timers of TACACS servers
|
Optional
|
Section 1.5.7
|
The goal of AAA configuration is to protect
network devices against unauthorized access and at the same time provide
network access services to authorized users. If you need to use ISP domains to
implement AAA management on access users, you need to configure the ISP
domains.
If you want to adopt remote AAA method, you
must create a RADIUS or HWTACACS scheme.
l
RADIUS scheme (radius-scheme): You can
reference a configured RADIUS scheme to implement 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 RADIUS scheme to implement AAA services. For the
configuration of RADIUS 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 configure the default ISP
domain
|
domain
{ isp-name | default { disable | enable
isp-name } }
|
Required
The default ISP domain is
"system".
|
Table 1-6 Configure
the attributes of an ISP domain
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Create an ISP domain or enter the view
of an existing ISP domain
|
domain
isp-name
|
Required
|
|
Activate/deactivate the ISP domain
|
state
{ active | block }
|
Optional
By default, once an ISP domain is
created, it is in the active state and all the users in this domain
are allowed to access the network.
|
|
Set the maximum number of access users
that can be contained in the ISP domain
|
access-limit { disable | enable max-user-number }
|
Optional
After an ISP domain is created, the
number of access users it can contain is unlimited by default.
|
|
Set the user idle-cut function
|
idle-cut { disable | enable minute flow }
|
