Asentria SiteBoss 530 User Manual
81
The remaining subsections discuss details of each part of AAA.
Authentication
The RADIUS feature enables the unit to offload (and centralize) user authentication responsibilities to a RADIUS
server. The unit does this for the following services in Phase 2 implementation:
•
Local (console) command processor
•
Telnet command processor
•
Modem command processor
•
Telnet pass-through
•
Real-time sockets
•
FTP
•
Web UI
Note:
Phase 3 implementation will support PPP while Phase 4 will support SSH. Neither Phase 3 nor Phase 4 are
supported in this version of the S530.
When the unit uses the USER PROFILES security mode, there can be at most 12 users configured, and the unit must
be configured with authentication and accounting details. With RADIUS security mode however, as many users can
log in to a unit as can be supported on the RADIUS server, and a manner completely independent of the User Profiles
configuration on the unit. Additionally, the unit may be just one of many machines that a user would need access to. If
all machines supported AAA, user management can be configured more easily and centrally via the RADIUS server,
instead of at the unit or other machines configured with their own security mechanisms.
PAP vs CHAP
Authentication can happen via PAP (Password Authentication Protocol) or CHAP (Challenge-Handshake
Authentication Protocol). Configured
sec.radius.chap
=ON
for CHAP, or
OFF
for PAP.
PAP is where the user provides a username and password. Both the username and password are transmitted to the
unit from the user in clear text (unless protected by the application layer's security, such as SSL (for the web UI) or
SSH). The username is transmitted to the RADIUS server from the unit in clear text (the password is not).
CHAP is more complex but more secure because the password is not transmitted to the unit from the user (unlike
PAP). Instead, the unit first provides the user with a CHAP challenge. The user provides the username, CHAP ID, and
CHAP response (which is generated from both the challenge and the user's password). The user uses some local
program to generate a CHAP response based on the user's password, CHAP ID, and CHAP challenge. The CHAP ID
is just a number between 0 and 255 that the user chooses and provides to both the unit and the CHAP-response-
generating program. The unit passes the challenge, username, CHAP ID, and CHAP response to the RADIUS server,
which then authenticates the user based on this data.
When logging in to the command processor, pass-through, Web UI, or real-time sockets, the user is prompted for
three things when CHAP is enabled: username, CHAP ID, and CHAP response. When logging in to the FTP server,
the UI is more standardized as "username and password" and hence requires some special attention when using
CHAP. In the case of logging in to the unit via FTP, enter as the FTP password the concatenation of the ASCII-hex
CHAP ID value and CHAP response. For example, if the user chooses CHAP ID 225 and generates CHAP response
DD0F3C51116B74CFFEC4379BA6D03507, then the FTP password is 225 in ASCII-hex (which is "E1") concatenated
with that response: E1DD0F3C51116B74CFFEC4379BA6D03507.
For all login services, the CHAP challenge is presented as a 32-byte ASCII-hex value, representing 16 bytes of the
actual challenge value. This is so the challenge can be a pseudo-random bit sequence of the same size as the
RADIUS frame authenticator, and also cut-and-pastable by the user between their login UI and their CHAP-response-
generating program.
In sum, PAP is as simple as traditional authentication methods. CHAP is more secure but more complex and requires
the user to have a local CHAP-response-generating program. This program is anything that can create a 16-byte MD5
hash of the CHAP ID (as an 8-bit value), user password, and challenge (as a 16-byte value).
Summary of Contents for SiteBoss 530
Page 6: ......
