Securing TCP/IP and Dial-up Access to Administrative Data


Copyright 1992 CAUSE From _CAUSE/EFFECT_ Volume 15, Number 2, Summer 
1992. Permission to copy or disseminate all or part of this material is 
granted provided that the copies are not made or distributed for 
commercial advantage, the CAUSE copyright and its date appear,and notice 
is given that copying is by permission of CAUSE, the association for 
managing and using information resources in higher education. To 
disseminate otherwise, or to republish, requires written permission.For 
further information, contact CAUSE, 4840 Pearl East Circle, Suite 302E, 
Boulder, CO 80301, 303-449-4430, e-mail info@CAUSE.colorado.edu


          SECURING TCP/IP AND DIAL-UP ACCESS TO ADMINISTRATIVE DATA
                             by L. Dean Conrad

ABSTRACT: Open systems are becoming the rule in most institutions these 
days and it's only natural that administrative systems should 
participate. But the kind of general access available to academic 
systems via TCP/IP can easily expose administrative data to unauthorized 
access or modification. Connection to the Internet substantially 
increases the risks. This article discusses Arizona State University's 
solution to this problem--authentication.

************************************************************************

L. Dean Conrad is Director of Computing and Network Consulting Services
(CNCS) in the information resources management organization at Arizona
State University. The CNCS department provides consulting support to the
faculty, staff, and students. Mr. Conrad is presently actively working
with the ASU community to define and implement distributed computing at
ASU. He has a BS in computer science from Iowa State University and is
presently pursuing a master's in computer science at Arizona State. He
may be contacted by e-mail (icsldc@asuvm.inre.asu.edu) or by phone (602-
965-5620).

************************************************************************


For several years, Academic Affairs at Arizona State University (ASU)[1] 
has sponsored a "microcomputer infusion" funding program, the
consequence of which is that literally every faculty member who desired
a microcomputer has acquired one. The emphasis is now shifting to
networking all this computer power. At present, roughly 50 percent of
the buildings on the main campus and 100 percent of the buildings on the
West campus are connected to the campus backbone network. Our campus
inter-system networking standard is the TCP/IP suite of protocols,
running on Ethernet, with plans to exploit the OSI (Open Systems
Interconnection) standard in the future.

Information Resources Management (IRM) at ASU is responsible for
operating and supporting the University's administrative applications as
well as the campus network. The administrative systems are fairly mature
and run on an IBM 3090-500E running MVS/XA for the traditional set of
applications, e.g., student information system, financial aid, alumni,
purchasing, accounts receivable, accounts payable, general ledger. We
have a significant network connecting administrators and staff (an SNA
network with more than 2,500 connections) in addition to a rapidly
growing Ethernet of more than 1,000 primarily faculty connections.

Historically, there was little pressure for faculty access to
administrative systems; however, that has changed. A new financial
system was installed a few years ago and a new human resources system
was implemented at the beginning of this calendar year. Both require
direct data entry by the using department/principal investigator. In
addition, a new mandatory advising system is available which also
requires faculty/academic department access to the student information
system. We felt this trend towards direct access by faculty and academic
departments to administrative systems would only accelerate, as would
the pressure to provide TCP/IP access to these systems.

What is TCP/IP?

TCP/IP (Transmission Control Protocol/Internet Protocol) is a
fundamentally different way for devices and systems to communicate than
has been available before on IRM systems. In the past, we have
implemented mostly proprietary communications mechanisms (protocols)
such as SNA on the IBM systems and DECNET on the DEC systems. This was
fine as long as customers with one vendor's equipment had no need to
communicate with another vendor's system. This was indeed the case,
because each vendor utilized proprietary protocols that other vendors
would not necessarily support. TCP/IP, on the other hand, is a non-
proprietary protocol--developed by the U.S. Government--that most 
computer and communications equipment vendors do support. Using TCP/IP, 
it is possible to communicate freely between different vendors' systems 
and equipment. This capability provides a tremendous degree of freedom 
and flexibility to the campus community and has allowed us to achieve 
one of our key strategic goals--"any-to-any connectivity," that is, the 
ability to connect between any workstation and any system anywhere on 
campus.

What is the security exposure?

The campus backbone Ethernet is the vehicle for transporting TCP/IP
traffic. When TCP/IP was selected as the protocol standard for inter-
system networking at ASU, we recognized the increased security exposure
inherent in the use of Ethernet, and IRM was urged by a campus task
force to take appropriate steps to ensure adequate security for
administrative data[2]

According to Voydock and Kent, potential security violations can be
divided into three distinct categories: unauthorized release of
information, unauthorized modification of information, and unauthorized
denial of resource use.[3] We felt the potential for unauthorized 
release
or modification of information was of most concern and that the most
likely way this could occur would be by compromising log-on password
security. Once an individual's log-on ID and password have been
obtained, all of his/her access privileges are available. Information
about log-on IDs is generally available on campus, so securing the
passwords became our primary goal.

The following were identified as potential abuses if log-on
password security were compromised:[4]

  *  checks could be illegally "authorized";
  *  grade point averages could be "improved";
  *  salary increases could be illegally "granted";
  *  any receivable could be "forgiven" (parking/library fines, tuition, 
housing, etc.);
  *  academic credits--indeed entire degrees--could be fabricated;
  *  students could be illegally admitted/registered; and
  *  financial aid could be illegally "granted."

These were identified as some of the potential abuses. Although we
recognized that responsible units might have other procedures or
mechanisms in place to audit and catch such violations, thereby reducing
the risks, we felt considerable mischief could be done in the interim
even if these abuses could be detected and recovered from at a later
date.

Voydock and Kent describe two types of attacks that can occur
during log-on and that must be addressed by any proposed solution:
attempting to log-on under a false identity, and playing back a
recording of a previous legitimate log-on sequence[5]

There is nothing inherently more or less secure about the Ethernet
medium or protocols (e.g., TCP/IP, DECNET) compared to the prior
administrative communications environment. However, the fact that
Ethernet is a "bus" architecture as compared to a "star" architecture,
as described by Bowker (see Figure 1), does introduce a new significant
security exposure.[6] In a bus architecture, all information destined 
for workstations sharing the same "bus" (or subnet) are transmitted 
along the same wire as opposed to the point-to-point "star" connections 
where each workstation has a dedicated wire that only carries 
information destined for that workstation.

In Figure 1, data destined for Workstation #3 from Host A will also
pass through Workstations #1, #2, #4 and #5 with a bus (e.g., Ethernet)
connection. Whereas with a star (e.g., SNA) connection, data destined
for Workstation #3 from Host A would not pass through any other
workstation. This is the inherent security exposure of the Ethernet bus
architecture referred to by Kirkpatrick[7]

[FIGURE 1 NOT AVAILABLE IN ASCII TEXT VERSION]

Figure 2 represents the Ethernet wiring configuration at ASU. In
this configuration, we have isolated Ethernet traffic as much as
possible in building "subnets" via a connection we have called an EPOP
(Ethernet Point-Of-Presence), using routers.[8] This improves network
management, maximizes the performance of the network, and helps to
minimize the security exposure. How that exposure is minimized is
illustrated in Figure 2, where the letters A, B, C, and D have been
added. When passing data from A to B, the EPOP keeps that traffic
localized on Building #1's subnet; that is, no workstation outside of
those connected to the Building #1 subnetcan see the traffic. When
passing information from A in Building #1 to C in Building #2, all
workstations in both buildings can see the traffic, but no other
workstation in any other building can see it. When communicating between
A and Host D, only other workstations in Building #1 can see the
traffic. As Voydock and Kent recommend, we ensured that gateways between
subnets--routers in our case--were adequately secured to prevent a 
hacker from reconfiguring our network[9]

[FIGURE 2 NOT AVAILABLE IN ASCII TEXT VERSION]

The above scheme significantly reduces the security exposure. However, 
we were concerned it did not go far enough to provide adequate security 
for administrative data. Protocol analyzer programs have been written--
and are readily available--that can allow someone at an  Ethernet 
workstation to capture information not intended for his/her  
workstation, but which is "available" because of the Ethernet bus 
architecture. No additional hardware or network "taps" are required. All 
that is needed is for that workstation to run a readily available 
program. Many vendors distribute this kind of program as an aid to 
network management[10]

A college or university thrives on diverse opinions, and several
key individuals on our campus expressed a concern that we were
overreacting to the exposure issue. We had a number of debates over just
how easily our standard security could be breached. After one
particularly spirited discussion, one of the computer center staff
members logged on to a new Sun workstation that had just been delivered,
fired up the protocol analyzer program that was delivered along with the
system, and in less than 90 minutes had captured a viable log-on ID and
password from someone else in the department. End of debate!

What could we do?

We identified five potential solutions to handling the risk of the
two types of attacks we were concerned with:

#0 Accept the risk (do nothing different).
#1 Enhance existing security measures.
#2 Place workstations needing access to administrative systems on
separate building subnets from those not needing this access.
#3 Secure some or all administrative data by using encryption.
#4 Use log-on "authentication" devices to secure administrative log-
on passwords.

Options #0 and #1 would do nothing to reduce the exposure, but
would rather rely on the prior set of security measures. Options #2, #3,
and #4 proposed additional measures be taken to reduce the risk. Each of
these options have advantages and disadvantages which are outlined
below. It should be noted that we did not consider a "trusted server" or
Trusted Network Base solution discussed by Ward11 because the TCP/IP
product for MVS did not support it.

#0 Accept the Risk

Choosing this option would mean doing nothing beyond existing security
mechanisms, which included the following:

  *  a terminating employee's manager had to request deletion of
his/her log-on IDs;
  *  90-day enforced password changes;
  *  minimum passwords of six characters;
  *  generic user IDs allowed;
  *  no limit on the number of times a log-on could be attempted with
the same ID;
  *  limited audit trail logging for transactions.

Advantages:
  *  no cost;
  *  no delay in providing TCP/IP access to administrative data;
  *  no additional mainframe or workstation overhead;
  *  no modifications required to mainframe applications;
  *  would not increase the complexity of network management/support.

Disadvantages:
  *  administrative log-on passwords and data would not be secure --
unauthorized access to data and use of log-ons/passwords could occur;
  *  no protection against someone recording and playing back a log-on
sequence.

#1 Enhance Existing Measures

This option would mean tightening present security measures, which could
include:
  *  implement automatic revocation of all of a terminating employee's
log-on IDs;
  *  enforce more frequent password changes--perhaps every 60 instead
of 90 days;
  *  require longer passwords--perhaps eight characters minimum instead
of six;
  *  eliminate generic user IDs;
  *  limit the number of times a log-on can be attempted before
disabling the log-on ID altogether--perhaps five log-on attempts;
  *  full detailed logging of all transactions which would provide a
detailed audit trail.

Advantages:
  *  no cost;
  *  little or no delay in providing TCP/IP access to administrative
data;
  *  no additional mainframe or workstation overhead;
  *  no modifications required to mainframe applications;
  *  would not increase the complexity of network management/support;
  *  would tighten control and management of log-on passwords;
  *  no new measures or expense would be introduced to impede access.

Disadvantages:
  *  administrative log-on passwords and data would not be secure --
unauthorized access to data and use of log-ons/passwords could occur;
  *  some flexibility would be exchanged for improved password
management;
  *  no protection against someone recording and playing back a log-on
sequence;
  *  increased system overhead due to full detailed logging.

#2 Separate Subnets

Our networking implementation isolates each building as a subnet, which
greatly reduces the exposure as explained earlier. A further extension
of this would be to establish separate Ethernet subnets within each
building--one for customers needing access to administrative 
applications and one for those that do not.

Advantages:
  *  would reduce the exposure in that we could separate student
access from staff/faculty access (or further breakdowns as needed);
  *  no additional mainframe or workstation overhead;
  *  no modifications required to mainframe applications;
  *  no delay in providing TCP/IP access to administrative data;
  *  would be a general solution--that is, this approach would provide
improved security with any workstation (IBM PC, Macintosh, Sun/SGI,
etc.) and would also work for "dumb" terminals.

Disadvantages:
  *  would increase the cost of Ethernet building connections by
roughly 25 percent and hence increase the Ethernet flat rate charges for
connections;
  *  improved security would be location specific, that is, access
from some workstations would be more secure than others;
  *  administrative log-on passwords and data would still not be
secure--unauthorized access to data and use of log-ons/passwords could
occur;
  *  would make management/support of the network more difficult;
  *  would reduce--but not eliminate--the threat of someone recording
and playing back a log-on sequence.

#3a Hardware Encryption

This option would involve installing data encryption hardware (outboard)
on both the mainframe and workstation ends.

Advantages:
  *  fast--no additional mainframe or workstation overhead;
  *  no modifications required to mainframe applications;
  *  would secure administrative log-on passwords and data;
  *  would be a general solution--that is, this approach would provide
improved security for "dumb" terminals.

Disadvantages:
  *  expense--ballpark cost of $1,000/workstation;
  *  improved security would be location specific, that is access from
encrypted workstations would be more secure than from workstations that
were not encrypted;
  *  delay providing TCP/IP access to administrative data;
  *  would make management/support of the network more difficult;
  *  would do nothing to protect against someone recording and playing
back a log-on sequence; however, little could be accomplished once a
connection was established.

#3b Software Encryption

This option would involve installing data encryption software (inboard)
on both the mainframe and workstation ends.

Advantages:
  *  would secure administrative log-on passwords and data;
  *  would be a general solution, that is, this approach would provide
improved security with any workstation (IBM PC, Macintosh, Sun/SGI,
etc.) but would not work for "dumb" terminals.

Disadvantages:
  *  expense--we found surprisingly few products available on the
market which means costs could exceed those for hardwareencryption;
  *  slow--added overhead on both the mainframe and the workstation,
  
  *  modifications required to the mainframe applications--ongoing
maintenance workload;
  *  delay providing TCP/IP access to administrative data;
  *  would make management/support of the network more difficult;
  *  would be platform specific solutions, for each type of workstation
(IBM PC, Macintosh, Sun/SGI, etc.), requiring additional support--would
not work for "dumb" terminals;
  *  would do nothing to protect against someone recording and playing
back a log-on sequence; however, little could be accomplished once a
connection was established.

#4 Log-on Authentication

Gasser and Voydock and Kent identify authentication as an effective
technique to ensure connections are made only for authorized users.[12] 
We chose to look at a "challenge and response" authentication approach 
as recommended by Voydock and Kent. Log-on password-generating software 
is installed on the mainframe end with a separate "key" for each log-on 
ID. Each administrative MVS customer requesting TCP/IP access is 
equipped with a hand-held "authenticator" device that has the same 
password generating algorithm and key as the mainframe software. Every 
time a TCP/IP customer logs on, he/she is prompted for a new one-time 
password that is simultaneously generated by the mainframe and the 
authenticator card. A different password is generated each time the 
customer logs on. With this approach, even if someone is monitoring 
Ethernet traffic, any log-on passwords they might get would be worthless 
as a different password would be required for a subsequent log-on.

Advantages:
  *  relatively low cost--$30,000 on the mainframe end plus $40/user
ID;
  *  would secure administrative log-on passwords, but not the data;
  *  fast--no additional workstation and very little mainframe
overhead;
  *  improved security would not be location specific--customer could
use authenticator device anywhere;
  *  would be a general solution, that is, this approach would provide
improved security with any workstation (IBM PC, Macintosh, Sun/SGI,
etc.) and would also work for "dumb" terminals;
  *  can be administered at a log-on ID level;
  *  would protect against someone recording and playing back a log-on
sequence.

Disadvantages:
  *  would not secure administrative data, but would secure log-on
passwords;
  *  modifications required to the mainframe applications--ongoing
maintenance workload;
  *  delay in providing TCP/IP access to administrative data;
  *  would make management/support of the network more difficult;
  *  must have authenticator device to gain access;
  *  customers with authenticators would not be able to work on the
system if they inadvertently left the device at home--analogous to
needing your key to get into your office (although we have implemented a
scheme to temporarily allow access in case of hardship).

Selected option

These options were presented to a number of customer advisory
groups, most notably the Administrative Computing Advisory Committee.
Frankly, we were concerned the material might be a little too esoteric
for general consumption, but found our customers were keenly interested
in understanding the exposure issues and in finding a workable solution.

We were questioned closely on the different options and consensus
was reached for Option #4--log-on authentication--as the best compromise
for our environment. This approach secures log-on passwords and ensures
there is no increased exposure to the unauthorized modification of
administrative data. Although it is still possible for someone to
monitor Ethernet traffic with this approach, they will only be able to
see what someone else chooses to look at and then only someone else on
their (building's) subnet. Our community felt this was a very slight
exposure, particularly since much of our data is of public record
anyway. We felt authentication coupled with the subnet per building
aspect of our wiring topology would reduce our exposure to an acceptable
level.

Dial-up

For many years, ASU had been using a call-back system as the mechanism 
for providing secure dial-up access to administrative systems. This is 
the technique where you call the system, enter an identifier, hang up, 
and the system calls you back at the phone number on record with the 
system.[13] This is an effective method; however, it has a  number of 
disadvantages. Chief among them is a lack of flexibility.  Since the 
number used to call you back must be recorded in the system,  this 
approach cannot be used easily while traveling. Secondly, the  process 
is a bit convoluted and hence error-prone. Our customers had  been quite 
vocal in their dislike of this approach.

After we selected log-on authentication as the solution for TCP/IP
security, we realized that the same approach could be used to secure
dial-up access in a much more effective manner than the call-back
approach. It is flexible, since it can be used via a connection from any
location, and it is much simpler to use, thus less error-prone.
Virtually no additional work was required to implement authentication
for dial-up access after the TCP/IP log-on authentication was in place.

Side-effects

There were some further side-effects of our efforts to educate our
customers about the exposures associated with TCP/IP:

(1) We agreed to review and tighten the present security mechanisms in 
addition to implementing authentication--in effect, also implementing 
Option #1.

(2) We agreed on the need to initiate an increased security education 
and awareness program for all administrative MVS customers.

(3) The EPOPs are loaded/managed using Simple Network Mail Protocol 
(SNMP). This process has been secured to avoid someone altering the type 
of traffic allowed into and out of a particular building subnet.

(4) Generic log-on IDs are an additional security exposure in an 
Ethernet-TCP/IP environment given the ability to access our systems from 
the Internet; we need to look at requiring authenticators for all 
generic log-on IDs.

The third item has already been addressed and the other three are on 
hold due to budget cuts.

Current status and summary

A Request For Proposals was done the fall of 1990 and the bid was 
awarded to Enigma Logic. We elected to initially restrict TCP/IP and
dial-up authenticated access to database applications as software
modifications were necessary for each subsystem involved.
(Authentication is part of the log-on process for gaining access to the
database subsystems.) Other access is planned, but not yet implemented.
We are using the IBM MVS TCP/IP software product and have implemented
modifications to ensure all TCP/IP access must be via an authenticated
log-on ID.

We began an authentication pilot the summer of 1991 with full
implementation for TCP/IP and dial-up access in the fall. The
implementation went very smoothly. Existing dial-up users have all been
converted to authentication. We have around 500 authenticated log-on IDs
at this writing.

In the pilot project, we discovered a few basic policies were
needed to make the program work well:

  *  The $40 charge for an authenticator card includes a one-year
extended warranty funded by IRM (the vendor only warrants the cards for
90 days). This extended warranty saved us a lot of grief with our
customers due to some initial quality control problems with the cards.

  *  A $20 refund per card is offered to encourage departments to turn
in authenticators when an employee terminates or if a device just isn't
being used anymore.

  *  When someone inadvertantly leaves her/his card at home, we will
provide non-authenticated access for one day only as a convenience to
the customer.

  *  Authentication is implemented on a log-on ID basis, that is, an
authentication customer must use the the card for all accesses, even
those not via TCP/IP or dial-up (e.g., SNA).


The card looks verysimilar to a credit card sized calculator.
Authentication is selected as an option from our main menu. The
authentication sequence adds about 20 seconds and four steps to the log-
on process:

(1) after the user is prompted for a log-on ID, she/he is given
a "challenge," which is a seven-digit number;

(2) the user keys the challenge into the authenticator card
which then displays a "response," also a seven-digit number;

(3) the user enters the response on the terminal or workstation
keyboard and a restricted sub-menu of only database subsystems is
displayed; and

(4) the customer selects the appropriate subsystem and
continues with the log-on process.

The device is easy to use and has required very little training.
The only real problem experienced so far has been some initial quality
control problems with the cards. Around 10 percent of cards were either
"dead on arrival" or failed in the first few weeks. When the failure
occurred after a card was in the field, the customer was understandably
frustrated. Fortunately, this problem occurred during the pilot and was
addressed with the vendor; they subsequently switched to a different
card supplier which improved the situation.

Authentication slows down the log-on process, is an additional
expense, and requires keeping track of the cards. However, very few
complaints have been registered about the enforced use of
authentication. I believe this is due to the active involvement of our
customer community in understanding the problem and in choosing a
solution.

Authentication alone will not be an adequate solution for
installations whose general security requirements are more stringent
than ours. However, we believe this approach addresses most of the
problem at a reasonable cost without introducing onerous restrictions on
our customers. All in all, we feel authentication is a good choice for
ASU.

Acknowledgements

I would like to express my appreciation to Rita Conrad for her many
helpful suggestions in preparing this material and in supporting my
presentation at CAUSE91, and to Dr. John Wasileski for his review and
comments, and to acknowledge John Babb, Carol Waters, and their staffs
for their work in successfully implementing authentication at ASU.

========================================================================

Footnotes:

1 Arizona State University, the fifth largest single-campus university
in the United States, recently became a multicampus institution with the
addition of the ASU West campus; there are approximately 43,000 students
between the two campuses. The University is blessed with a substantial
communications capacity: three separate cable television (CATV) cables
(only one of which is presently activated), 18,000 twisted pair of
copper wire, and twelve strands of fiber in each campus' tunnel
infrastructure. A broadband-based Ethernet backbone network is run on
the one activated CATV cable.

2 J. Askins, L. Conrad, D. Eschbach, H. Harken, G. Machovec, L. 
Miller, and R. Mohn, The COTI [COmmittee on TCP/IP Implementation] 
Report (Tempe: Arizona State University, 1989), pp. 2-4.

3 Victor L. Voydock and Stephen T. Kent, "Security Mechanisms in High-
Level Network Protocols," Computing Surveys, June 1983, pp. 165-168.

4 It should also be noted that these abuses are just as possible on 
any kind of network if log-on passwords are not properly managed and
protected.

5 Voydock and Kent, pp. 165-168.

6 Richard Bowker, INTERLAN on Inter-operability (Boxborough: INTERLAN,
Inc., 1988), p. 25.

7 Kimberly E. Kirkpatrick, "Why is a LAN a LAN?," in Local Area 
Network Security, LANSEC '89 proceedings, edited by T. A. Benson and T. 
Beth (Berlin: Springer-Verlag, 1989), pp. 3-4.

8 For purposes of this article, a router is an electronic device that
limits traffic to a particular subnet. Only traffic destined for an
address on a particular subnet is allowed in and only traffic destined
for an address outside a particular subnet is allowed out. A subnet is a
portion of a larger network, e.g., a campus-wide Ethernet. Typically it
involves a particular "community of interest," such as an academic
department, whose members communicate heavily with one another.

9 Voydock and Kent, p. 140.

10 L. Kirk Barker, "Network Management and Diagnostics for Secure
LANs," in Local Area Network Security, LANSEC '89 proceedings, op cit.
(footnote 7), p. 145.

11 Richard Ward, "OSI Network Security and the NTCB," in Local Area
Network Security, LANSEC '89 proceedings, op cit. (footnote 7), pp. 67-
74.

12 Morrie Gasser, "Access Control and Authentication in LANs," in 
Local Area Network Security, LANSEC '89 proceedings, op cit. (footnote 
7), pp. 21-24; Voydock and Kent, pp. 165-168.

13 Gerald D. Cole, Computer Science and Technology: Design 
Alternatives for Computer Network Security (Washington: U.S. Government 
Printing Office, 1978), p. 134.

========================================================================