HP A 5120 Manual

							1 
AAA configuration 
AAA overview 
Authentication, Authorization, and Accounting  (AAA) provides a  uniform  framework  for implementing 
network access management. It provides the following security functions: 
 Authentication—Identifies users and determines whether a user is valid.  
 Authorization—Grants  different  users  different  rights  and  controls  their  access  to  resources  and 
services. For example, a user who has successfully logged in to the device can be granted read and 
print permissions to the files on the device.  
 Accounting—Records  all user network  service  usage  information,  including  the  service  type,  start 
time,  and  traffic.  The  accounting function not  only  provides  the information required  for  charging, 
but also allows for network security surveillance.  
AAA  usually uses a client/server  model. 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.  
Figure 1 Network diagram for AAA 
 
 
When  a  user  tries  to  log  in  to  the  NAS,  use  network  resources,  or  access  other  networks,  the  NAS 
authenticates  the  user.  The  NAS  can  transparently  pass  the  user’s  authentication,  authorization,  and 
accounting information to the servers. The  RADIUS and  HWTACACS protocols define how a NAS and a 
remote server exchange user information between them.  
In  the  network  shown  in Figure  1,  there  is  a  RADIUS  server  and  an HWTACACS  server.  You  can  choose 
different servers  for  different  security  functions.  For  example,  you  can  use  the  HWTACACS  server  for 
authentication and authorization, and the RADIUS server for accounting. 
You can choose the three security functions provided by  AAA as required. For example, if your company 
only  wants  employees  to  be  authenticated  before  they  access  specific  resources, you only  need  to 
configure  an  authentication  server.  If  network  usage  information  is  needed, you must  also  configure  an 
accounting server. 
AAA  can  be  implemented through  multiple protocols. The  device  supports  using RADIUS and 
HWTACACS for AAA. RADIUS is often used in practice. Remote userNASRADIUS server
HWTACACS server
Internet
Network  
						

							2 
RADIUS 
Remote  Authentication  Dial-In  User  Service  (RADIUS)  is  a  distributed  information interaction protocol that 
uses a 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.  
RADIUS  uses  UDP  as  the  transport  protocol.  It  uses  UDP  port 1812 for authentication  and UDP  port 1813 
for accounting.  
RADIUS  was  originally  designed  for  dial-in  user  access.  With  the addition of new access  methods, 
RADIUS  has  been  extended  to  support additional access  methods,  for  example,  Ethernet  and  ADSL. 
RADIUS provides  access  authentication  and  authorization  services,  and  its  accounting  function  collects 
and records network resource usage information. 
Client/server model 
The RADIUS client  runs  on the NASs  located  throughout the  network.  It  passes  user  information  to 
designated  RADIUS  servers  and  acts  on  the  responses  (for  example,  rejects  or  accepts  user  access 
requests). 
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  listens  to  connection  requests,  authenticates 
users,  and  returns  user  access  control  information  (for  example,  rejecting  or  accepting  the  user  access 
request) to the clients. 
In general, the RADIUS server maintains the following databases: Users, Clients, and Dictionary 
Figure 2 RADIUS server components 
 
 
 Users—Stores user information, such as usernames, passwords, applied protocols, and IP addresses. 
 Clients—Stores information about RADIUS clients, such as shared keys and IP addresses. 
 Dictionary—Stores RADIUS protocol attributes and their values. 
Security and authentication mechanisms 
Information  exchanged between a RADIUS  client  and the RADIUS  server is authenticated with a  shared 
key,  which  is  never  transmitted  over  the  network.  This  enhances  information  exchange  security.  In 
addition,  to  prevent  user  passwords  from  being  intercepted  in  non-secure  networks,  RADIUS encrypts 
passwords before transmitting them.  
A RADIUS server  supports  multiple  user  authentication  methods,  such  as the Password  Authentication 
Protocol  (PAP)  and the Challenge  Handshake  Authentication  Protocol  (CHAP).  Moreover, a RADIUS 
server can act as the client of another AAA server to provide authentication proxy services.  
RADIUS basic message exchange process 
Figure 3 illustrates the interactions between the host, the RADIUS client, and the RADIUS server. RADIUS servers
UsersClientsDictionary  
						

							3 
Figure 3 RADIUS basic message exchange process 
 
 
RADIUS operates in the following manner: 
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, with the user password encrypted by using the Message-
Digest 5 (MD5) algorithm and 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 user’s authorization information. If the 
authentication fails, it returns an Access-Reject message. 
4. The RADIUS client permits or denies the user according to the returned authentication result. If it 
permits 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 user 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 
for the user.  
9. The user stops access to network resources. 
RADIUS packet format 
RADIUS uses UDP to transmit messages. It ensures smooth message exchange between the RADIUS server 
and  the  client through a  series  of  mechanisms,  including  the timer  management mechanism, the 
retransmission mechanism, and the backup server mechanism. Figure 4 shows the RADIUS packet format. RADIUS clientRADIUS server
1) Username and password
           3) Access-Accept/Reject
           2) Access-Request
4) Accounting-Request (start)
            5) Accounting-Response
7) Accounting-Request (stop)
            8) Accounting-Response
9) Notification of access termination
Host
6) The host accesses the resources  
						

							4 
Figure 4 RADIUS packet format 
 
 
Descriptions of the fields are as follows: 
1. The Code field (1 byte long) indicates the type of the RADIUS packet. 
Table 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, the authentication 
succeeds, and 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 authentication fails 
and the server 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 or stop accounting for the 
user. The Acct-Status-Type attribute in the packet indicates 
whether to start or stop accounting. 
5 Accounting-Response 
From the server to the client. The server sends a packet of this 
type to notify the client that it has received the Accounting-
Request and has correctly recorded the accounting 
information.  
 
2. The Identifier field (1 byte long) is used to match request and response packets and to detect 
retransmitted request packets. Request and response packets of the same type have the same 
identifier.  
3. The Length field (2 bytes long) indicates the length of the entire packet, including the Code, 
Identifier, Length, Authenticator, and Attribute fields. Bytes beyond this length are considered 
padding and are neglected upon reception. If the length of a received packet is less than this 
length, the packet is dropped. The value of this field is in the range 20 to 4096.  
4. The Authenticator field (16 bytes long) is used to authenticate replies from the RADIUS server and to 
encrypt user passwords. There are two types of authenticators: request authenticator and response 
authenticator. Code
Attribute
Identifier
0
7Length
Authenticator (16bytes)
71531  
						

							5 
5. The Attribute field, with a variable length, carries the specific authentication, authorization, and 
accounting information that defines the configuration details of the request or response. This field 
contains multiple attributes, and each attribute is represented in triplets of Type, Length, and Value.  
 Type (1 byte  long)—Indicates the  type  of  the  attribute.  It  is  in  the  range  1  to  255. See Table  2 for 
commonly  used  attributes  for  RADIUS  authentication, authorization  and accounting,  which are 
defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868. For more information about commonly 
used standard RADIUS attributes, see ―Commonly used standard RADIUS attributes.― 
 Length (1 byte  long)—Indicates the  length  of  the  attribute in  bytes, including  the  Type,  Length,  and 
Value fields. 
 Value (up  to  253  bytes)—Value  of  the  attribute.  Its  format  and  content  depend  on the Type  and 
Length fields. 
Table 2 RADIUS attributes  
No. Attribute No. Attribute 
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  
						

							6 
No. Attribute No. Attribute 
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 
 
Extended RADIUS 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 5, a sub-attribute that can be encapsulated in Attribute 26 consists of 
the following parts: 
 Vendor-ID (4 bytes long)—Indicates the ID of the vendor. Its most significant byte is 0; the other three 
bytes  contains  a  code  that  is  compliant  to  RFC  1700.  For  more information about  the  proprietary 
RADIUS sub-attributes of HP, see ―HP proprietary RADIUS sub-attributes.― 
 Vendor-Type—Indicates the type of the sub-attribute.  
 Vendor-Length—Indicates the length of the sub-attribute.  
 Vendor-Data—Indicates the contents of the sub-attribute.   
						

							7 
Figure 5 Segment of a RADIUS packet containing an extended attribute 
 
 
HWTACACS 
HW Terminal  Access  Controller  Access  Control  System (HWTACACS) is  an  enhanced  security  protocol 
based on TACACS (RFC 1492). Similar to RADIUS, it uses a client/server model for information exchange 
between the NAS and the HWTACACS server.  
HWTACACS  mainly  provides AAA services for  Point-to-Point Protocol (PPP) users, Virtual Private Dial-up 
Network  (VPDN) users,  and terminal users. In  a  typical  HWTACACS  application,  some terminal  users 
need  to  log in to  the NAS for  operations.  Working  as  the  HWTACACS  client,  the  NAS  sends  the 
username  and  password of  a  user  to  the  HWTACACS  sever  for  authentication. After  passing 
authentication  and  being  authorized,  the  user  logs  in  to  the  device  and  performs  operations,  and  the 
HWTACACS server records the operations that the user performs. 
Differences between HWTACACS and RADIUS 
HWTACACS and RADIUS both provide authentication, authorization, and accounting services. They have 
many  features  in  common,  like  using  a  client/server  model,  using  shared  keys  for  user  information 
security, and providing flexibility and extensibility. Table 3 lists their differences. 
Table 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 user 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 the authorization 
process is combined with the authentication process. 
Supports authorization of configuration commands. 
Which commands a user can use depends on both 
the user level and AAA authorization. A user can 
use only commands that are not only of, or lower 
than, the user level but also authorized by the 
HWTACACS server. 
Does not support authorization of configuration 
commands. Which commands a user can use 
depends on the level of the user and a user can use 
all the commands of, or lower than, the user level. 
 
HWTACACS basic message exchange process 
The  following  takes a Telnet  user  as  an  example  to  describe  how  HWTACACS  performs  user 
authentication, authorization, and accounting. TypeLength
0
Vendor-ID
71531
Vendor-ID (continued)Vendor-Type Vendor-Length  
Vendor-Data
(Specified attribute value01020102)
23
01020102  
						

							8 
Figure 6 HWTACACS basic message exchange process for a Telnet user 
 
 
Here is the process: 
1. A Telnet user sends an access request to the HWTACACS client.  
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 to request the username.  
4. Upon receiving the response, the HWTACACS client asks the user for the username. 
5. The user inputs the username. 
6. After receiving the username, the HWTACACS client sends the server a continue-authentication 
packet that carries the username.  
7. The HWTACACS server sends back an authentication response, requesting the login password.  
8. Upon receipt of the response, the HWTACACS client asks the user for the login password.  HostHWTACACS clientHWTACACS server
1) The user logs in
2) Start-authentication packet
3) Authentication response requesting the username
4) Request for username
5) The user inputs the username6) Authentication continuance packet with the username
7) Authentication response requesting the login password
8) Request for password
9) The user inputs the password
11) Authentication response indicating successful authentication
12) User authorization request packet
13) Authorization response indicating successful authorization
14) The user logs in successfully
15) Start-accounting request
16) Accounting response indicating the start of accounting
17) The user logs off
18) Stop-accounting request
19) Stop-accounting response
10) Authentication continuance packet with the login password  
						

							9 
9. The user inputs the password. 
10. After receiving the login password, the HWTACACS client sends the HWTACACS server a 
continue-authentication packet that carries the login password. 
11. The HWTACACS server sends back an authentication response to indicate 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 now 
authorized. 
14. Knowing that the user is now authorized, the HWTACACS client pushes its configuration interface 
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 response, indicating that the stop-accounting 
request has been received. 
Domain-based user management 
A  NAS  manages  users  based  on  Internet  service  provider  (ISP)  domains. On  a  NAS,  each  user  belongs 
to one ISP domain. A NAS determines the ISP domain a user belongs to by the username entered by the 
user at login, as shown in Figure 7. 
Figure 7 Determine the ISP domain of a user by the username 
 
 
The authentication, authorization, and accounting of a user depends on the AAA methods configured for 
the  domain  that  the  user  belongs  to.  If  no  specific  AAA  methods  are  configured  for  the  domain,  the 
default methods are  used.  By  default,  a  domain  uses  local  authentication,  local  authorization,  and  local 
accounting. 
The AAA feature allows you to manage users based on their access types:  
 LAN  users—Users  on  a  LAN  who  must  pass  802.1X authentication or  MAC  address  authentication 
to access the network. 
 Login  users—Users  who  want  to  log  in  to  the  device,  including  SSH  users,  Telnet  users,  FTP  users, 
and terminal service users. 
 Portal users—Users who must pass portal authentication to access the network. Username carries @domain-name?
A user enters the username in the form ofuserid@domain-name or userid
Use domain domain-name to authenticate the user
Use the default domain to authenticate the user
Yes
No
NAS  
						

							10 
For  a  user  who  has  logged  in  to  the  device,  AAA  provides  the  following  services  to  enhance  device 
security: 
 Command authorization—Enables the NAS to defer to the authorization server to determine whether 
a command entered by a login  user  is permitted  for  the  user,  ensuring  that  login  users  execute only 
commands they  are  authorized  to  execute. For  more  information  about  command  authorization,  see 
the Fundamentals Configuration Guide.  
 Command  accounting—Allows  the  accounting  server  to  record  all  commands  executed  on  the 
device  or  all  authorized  commands  successfully  executed. For  more  information  about  command 
accounting, see the Fundamentals Configuration Guide.  
 Level  switching authentication—Allows  the  authentication  server  to  authenticate  users  performing 
privilege  level  switching.  As  long  as  passing  level  switching  authentication,  users can  switch  their 
user privilege levels, without  logging  out and disconnecting  current connections. For  more 
information about user privilege level switching, see the Fundamentals Configuration Guide.  
You can  configure  different authentication,  authorization,  and  accounting  methods  for  different  users  in  a 
domain. See ―Configuring AAA methods for ISP domains.― 
RADIUS server feature of the device 
Generally, the RADIUS  server  runs  on  a  computer  or  workstation,  and the RADIUS  client  runs  on  a  NAS 
device. A network device  that supports the  RADIUS  server feature can also serve  as the RADIUS  server, 
working with  RADIUS  clients  to  implement  user  authentication,  authorization,  and  accounting.  As  shown 
in Figure 8, the RADIUS server and client can reside on the same device or different devices.  
Using  a  network device as  the  RADIUS  server simplifies  networking and reduces deployment costs.  This 
implementation  is  usually deployed on  networks by  using  the  clustering  feature.  In  such  a  scenario, 
configure the RADIUS server feature on a management device at the distribution layer, so that the device 
functions  as  a  RADIUS  server  to  cooperate  with cluster member switches at  the  access  layer  to  provide 
user authentication and authorization services. 
Figure 8 Devices functioning as a RADIUS server 
 
 
A network device serving as the RADIUS server can provide the following functions: 
 User  information  management—Supports  creating,  modifying,  and  deleting  user  information, 
including the username, password, authority, lifetime, and user description.  
 RADIUS client information management—Supports creating, and deleting RADIUS clients, which are 
identified  by  IP  addresses and  configured  with  attributes  such  as a shared  key.  After  being 
configured  with  a  managed  client  range,  the  RADIUS  server  processes  only the RADIUS  packets NAS
RADIUS server
 RADIUS serverNAS/
IP network
IP network