Chapter 1 AAA Overview
1.1 Introduction to AAA
AAA is the acronym for the three security
functions: authentication, authorization and accounting. It provides a uniform
framework for you to configure these three functions to implement network
security management.
l
Authentication: Defines what users can access the
network,
l
Authorization: Defines what services can be available
to the users who can access the network, and
l
Accounting: Defines how to charge the users who are
using network resources.
Typically, AAA operates in the
client/server model: the client runs on the managed resources side while the
server stores the user information. Thus, AAA is well scalable and can easily implement
centralized management of user information.
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 username, 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. You can use standard or extended RADIUS protocols in conjunction with
such systems as iTELLIN/CAMS for user authentication. Remote authentication allows
convenient centralized management and is feature-rich. However, to implement
remote authentication, a server is needed and must be configured properly.
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.
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.
An Internet service provider (ISP) domain
is a group of users who belong to the same ISP. For a username in the format of
userid@isp-name or userid.isp-name, the isp-name following the "@"
or “.” character is the ISP domain name. The access device uses
userid as the username 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 username 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 service for
AAA is RADIUS.
I. What is RADIUS
Remote Authentication Dial-in User Service
(RADIUS) is a distributed service 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 network access
servers throughout the network.
RADIUS operates in the client/server model.
l
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.
l
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 username, 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 username and password.
2)
The RADIUS client receives the username 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 authorization
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
changes, 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
Huawei Terminal Access Controller Access
Control System (HWTACACS) 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 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 server.
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.
