2/2/98 CommunicationsWeek 31 (see BOLD)
1998 WL 2380031
InternetWeek
Copyright 1998 CMP Publications Inc.
Monday, February 2, 1998
700
Bandwidth
Technology Primer
Remote Access Authentication Coming Of Age
Salvatore Salamone
The booming growth in telecommuting and the need to support more
remote workers are making life tough for IT managers.
Besides the usual tasks of maintaining remote access server (RAS)
equipment, managers often find their time consumed by administering
access rights and authentication privileges on several geographically
dispersed RASes at the same time.
Enter the Remote Authentication Dial In User Service.
RADIUS is a commonly used authentication system. Most remote access
equipment vendors, including 3Com Corp., Ascend Communications, Bay
Networks, Livingston Enterprises Inc. and Shiva Corp., support RADIUS in
their RASes. Additionally, Microsoft now includes RADIUS support as part
of its Windows NT Routing and Remote Access Server software.
For IT managers, the main attraction of RADIUS is that it lets them
simplify administration of user authentication by keeping a central
database of access rights.
"We used to go crazy trying to keep access rights current on different
pieces of equipment," said Arnold Lafreniere, a network administrator at
Levinton Electronics Corp., an electronics component manufacturer.
"Every time someone changed jobs, left the company, or traveled and
called in from the road, we had to change access rights on two or three
RASes."
RADIUS avoids such problems. IT managers can use a single RADIUS
server to authenticate users dialing into multiple RASes. With RADIUS,
IT managers maintain a single authentication database. All users
dialing into a network are authenticated against this database.
For such centralized authentication to work, RASes must securely
communicate with a RADIUS server and verify that the user meets certain
conditions before allowing the user to gain access to the network.
The process of authentication is transparent to the user dialing in.
When a user places a call into a RAS, a Point-to-Point Protocol (PPP)
session is initiated. The RAS takes authentication information, such as
a user name and password, and passes this information to the RADIUS
server.
If the user is in the database and has access privileges to the
network, the RADIUS server signals the RAS that it is OK to continue the
process.
At the same time, the RADIUS server also sends what is called profile
information about the user to the RAS. The profile can include
information such as the user's IP address, the maximum amount of time
the user can remain connected to the network and the phone number the
user is allowed to dial to access the network.
The RAS takes this information and checks to make sure the call meets
the criteria of the checklist items. If the conditions are met, the PPP
negotiation with the caller is completed and the user is granted access.
If the user does not meet the conditions-say the person called using a
number reserved for other people in the company-the call is terminated.
A single RADIUS server can support all the RASes in a corporation.
This lets a manager set access policies and user access privileges once
and apply them no matter which RAS the user calls in on.
Using The Data
Depending on the level of security an organization wants to maintain,
IT managers have two choices for handling the transaction between the
user and the RAS.
PPP supports both the Password Authentication Protocol (PAP) and the
Challenge Handshake Authentication Protocol (CHAP).
PAP is easier to use but offers lower security. With PAP, users
typically send passwords to the RAS unencrypted in plain text format.
The RAS encrypts the password and sends it to the RADIUS server, which
decrypts the password. The RADIUS server then validates the password
against its database, against a NetWare Bindery or Novell Directory
Service or against a Microsoft NT Domain or Workgroup list.
If a manager does not want to have users sending passwords unencrypted
to the RAS, CHAP is the option. With CHAP, the RAS challenges the user
to prove his or her identity. This is accomplished by the RAS generating
a random number and sending it to the user. The user's PPP client
creates what is called a digest that encrypts the password using the
"challenge." This digest is sent to the RAS, which then passes it to the
RADIUS server. The RADIUS server creates a digest using its copy of the
user's password.
If the two digests match, it means the user is indeed who he or she
claims to be and is authenticated by the RADIUS server. The benefit of
this approach is that a user's password never passes unencrypted over
the dial-up portion of the link.
Regardless of the method used to authenticate the user, the RADIUS
server then returns a profile of the user's attributes to the RAS. An IT
manager creates the attributes by defining a set of requirements for
each user or group of users to access the network. This might include
such things as the time of day a user can access the network or whether
the user is allowed to use an ISDN connection. This set of criteria for
access is passed from the RADIUS server to the RAS, where specific
conditions of each call are checked.
RADIUS' central database of access information is ripe for use in
other ways. But until recently, it was considered too hard to get at to
be of any use.
For instance, while RADIUS servers track a user's logon and logoff
information, it has been hard to correlate that information across
multiple RASes because there has been no simple way to extract and
compare just that portion of a much larger RADIUS accounting database.
IT managers who wanted to use the information for other purposes, like
tracking usage patterns to aid in planning equipment upgrades, needed to
write customized programs.
Management Control
Within the past three months, several RAS companies have taken steps
to change this situation.
In December, Livingston Enterprises introduced the RADIUS
Authentication Billing Manager (ABM), a line of remote access management
servers that take the usage information from a RADIUS database and link
it with business processes such as customer billing and network trend
analysis. Livingston's RADIUS ABM includes a suite of applications such
as Trend Builder and Integrated Billing applications.
Other vendors marry the information in a RADIUS database to security
features in their own products to give a manager more targeted access
control. For instance, Ariel Corp. combines user authentication
information in a RADIUS database with a caller ID feature in its RASCAL
line of RASes to offer a call-blocking feature. Essentially, the RASCAL
determines the phone number from which a user has dialed into the RAS.
If that number does not match the authorized numbers in RADIUS from
which that user is allowed to dial in, the call is automatically
blocked.
Such tools are likely to become more important as companies want to
take more control over their networks.
"There's a wealth of untapped information in RADIUS databases,"
Lafreniere said.
For example, RADIUS includes a number of standard accounting and
reporting features. A RADIUS server, for example, can maintain a history
of all user sessions. This could include a record of the start and stop
time and duration of every session for each user.
A manager might use this information to track total connect time and
peak connection periods to help identify usage patterns. Or, the
information could be used by an IT department to bill back business
units for usage of the network.
Word Count: 1217
2/2/98 COMMWK 31
END OF DOCUMENT |
