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
transmits 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
transmits 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
transmits 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
transmits 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
transmits this packet to the client to notify the client that it has received
the Accounting-Request packet and has correctly recorded the accounting
information.
|
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
