7957 lines
280 KiB
Plaintext
7957 lines
280 KiB
Plaintext
|
||
Founded By: | _ _______
|
||
Guardian Of Time | __ N.I.A. _ ___ ___ Are you on any WAN? are
|
||
Judge Dredd | ____ ___ ___ ___ ___ you on Bitnet, Internet
|
||
------------------+ _____ ___ ___ ___ ___ Compuserve, MCI Mail,
|
||
\ / ___ ___ ___ ___ ___________ Sprintmail, Applelink,
|
||
+---------+ ___ ___ ___ ___ ___________ Easynet, MilNet,
|
||
| 06MAR91 | ___ ______ ___ ___ ___ FidoNet, et al.?
|
||
| File 71 | ___ _____ ___ ___ ___ If so please drop us a
|
||
+---------+ ____ _ __ ___ line at
|
||
/ \ ___ _ ___ elisem@nuchat.sccsi.com
|
||
------------------+ __
|
||
Editors: | _ Network Information Access
|
||
Judge Dredd | Ignorance, There's No Excuse.
|
||
Lord Macduff |
|
||
------------------+ Issue 071 :: Volume 02
|
||
|
||
|
||
"The liberty of the press is not confined to newspapers and periodicals.
|
||
It necessarily embraces pamphlets and leaflets....The press in its
|
||
historical connotation comprehends every sort of publication which
|
||
affords a vehicle of information and opinion."
|
||
-- Lowell v. City of Griffin, 303 U.S. 444, 452 (1938), quoted by Mike
|
||
Godwin in comp.org.eff.talk
|
||
|
||
=============================================================================
|
||
1. Index .......................................................NIA Editors
|
||
2. Analysis of the 4-wire Line - An Explanation ........Donald E. Kimberlin
|
||
3. Using the UK Academic Network PSS Gateway ......Scantronics Publications
|
||
4. DoD Trusted System Evaluation Criteria [02/02] ..............Judge Dredd
|
||
5. List of Texas Internet Sites ...............................Lord Macduff
|
||
6. Steve Jackson Games vs. Secret Service....................EFF Foundation
|
||
7. Editor's Comments ...........................................NIA Editors.
|
||
============================================================================
|
||
|
||
|
||
|
||
|
||
/ /
|
||
/ File 02 / NIA071 /
|
||
/ The Four Line - An Explanation /
|
||
/ Donald E. Kimberlin /
|
||
/ /
|
||
|
||
|
||
|
||
[Editoral Info: Mr. Kimberlin has been a broadcasting engineer since 1957, with
|
||
added time at AT&T in international communications, later
|
||
at ITT preforming the same work with international cables and
|
||
satellites. Then manufacturers of communications equipmnet
|
||
as an export marketer to the government PTT's of 70 countries
|
||
on five continents.]
|
||
|
||
It seems many participants thought such a transmission circuit is
|
||
a rather special form of transmission medium; one infrequently used
|
||
and perhaps of exceedingly high cost. What follows is an attempt to
|
||
describe what is actually a rather common and age-old technique in a
|
||
way that might help readers know how to use it for their own benefit.
|
||
|
||
Most people involved with telephony have only been exposed to
|
||
local use, adn even local subscriber line physical plant, where a
|
||
single pair of wires is used for a dial subscriber line for one over-
|
||
riding reason: The cost of providing service to the majority of users,
|
||
people who simply want dial voice-grade telephone service.
|
||
|
||
Were the local telephone exchanges to use a "four-wire line" to
|
||
each and every subscriber, we could have a far more idealized Public
|
||
Switched Telephone Network (PSTN - the proper CCITT name). We in the
|
||
US often mistitle the PSTN as "DDD," which actually is the Bell
|
||
acronym for Direct Distance Dialing (long-distance subscriber dialing,
|
||
called STD in the UK, or a close equivalent in other nations).
|
||
|
||
Transmission losses could have historically been much less, as there
|
||
would be no echoes to combat. We would transmit in one direction on
|
||
one pair and transmit in the other direction on the other, without
|
||
interaction between the two directions. However, to provide such a
|
||
plant would require double the literally millions of tones of copper
|
||
wire that have been installed worldwide. The economic cost factors
|
||
are obvious. Paying for the local cable plant has been a major cost
|
||
factor for public telephone networks worldwide. (Other alternatives
|
||
such as fiber and coaxial cable used by cable TV companies are making
|
||
some change, but the millions of tons of copper are already there ...
|
||
and ISDN is planned in a way to try to continue to use that imbedded
|
||
investment.
|
||
|
||
So, a local telephone plant uses only one pair per subscriber.
|
||
In engineering terms, it is far from a perfect transmission line. The
|
||
main reason is that no transmission line operates at its normal
|
||
electrical "impedance" until it is a significant portion of an
|
||
electrical wavelength of the signal it carries. Studying a beginning
|
||
physics book will show that one wavelength at 3000 Hertz in a perfect
|
||
line is 61 miles, and at 300 Hertz, it would be 610 miles! (Another
|
||
factor called the "propagation velocity" even stretches this _much_
|
||
more in practical wire.) Obviously, to have even reasonably
|
||
well-matched wire would not be reasonable, and it wasn't at all
|
||
economical in the developmental era of the PSTN. So, this network
|
||
evolved assuming some very large tradeoffs were needed.
|
||
|
||
An electrical transmission line has one interesting
|
||
characteristic just opposite from water pipes or acoustical guides
|
||
(hollow tubes). Instead of an open distant end letting all the energy
|
||
spill out, an open-ended electrical line _reflects_ all its received
|
||
power back toward the source. A shorted line absorbs all the energy
|
||
(as you find out when you short a power line and blow the fuse!).
|
||
What this characteristic means to telephone transmission is that with
|
||
lines as short as they must be in local plant, echoes are reflected
|
||
back toward the speaker, subject only to the losses they incur
|
||
rattling back and forth. They really are pretty high, but we don't
|
||
notice them. The reason: Echoes that return to our ear in less than
|
||
about 10-15 thousandths of a second are heard by us a part of the
|
||
outbound signal ... we just don't hear them. Local connections are
|
||
short enough that for general telephony, echoes can be largely
|
||
discounted, even thought they are there.
|
||
|
||
Very early in the development of longer transmission paths, it
|
||
was learned that transmission losses mount rapidly when one really
|
||
does have miles and miles of wire to talk on. In intercity
|
||
transmission lines, use of electronics to amplify the signal as
|
||
intervals was seen to be mandatory to achieve commercially successful
|
||
"long lines." Thus, as soon as the three-electrode vacuum tube was
|
||
available, the telephone industry had a very real interest in it, and
|
||
pressed to realize its use as soon as possible. (In fact, a Bell Labs
|
||
worker contributed "negative feedback" to the early vacuum-tube
|
||
circuitry, making the "tube" a controllable, useful technology instead
|
||
of a physics lab curio.)
|
||
|
||
But, the vacuum tube (as its descendant, the transistor) has one
|
||
limitation. It can pass a signal in only one direction, a
|
||
characteristic that happens to match that idealized "four-wire"
|
||
transmission line. So, "long lines" very early on (in the 1910-15
|
||
time frame) all became "four-wire lines."
|
||
|
||
They did, however, have to interface to the echo-prone and less
|
||
controllable local "two-wire" (single pair) telephone networks. The
|
||
method devised was the "hybrid," in telephony mostly an arrangement of
|
||
trans- formers that had three windings, one for the local two-wire
|
||
side and one each for the sending and receiving "long lines." Now,
|
||
echoes were a real problem. Not only would echoes from the local
|
||
two-wire line take long enough to return to the distant city to be
|
||
heard, but impedance mismatching of the two-wire local line to the
|
||
transformer could cause received distant signals to reflect right in
|
||
the transformer back down the transmitting channel as well. "Echo
|
||
control" became a major topic in handling "long lines." (The trick is
|
||
to add a fourth winding set to the transformer with an "artificial
|
||
line" that is adjusted to create the match. In telephony, its name is
|
||
a "balancing network."
|
||
|
||
All this sort of work was at first (and for decades) the work of
|
||
the "long lines" people. Very little of it was in the hands of the
|
||
local people. The "long lines" people were AC and electronics people,
|
||
while the local people were DC and electrical people. The oeprational
|
||
reasons for having a "Long Lines Department" are obvious in this
|
||
context.
|
||
|
||
As multichannel "carrier systems" evolved (and early, too,
|
||
beginning around 1915 between Toledo, Ohio and South Bend, Indiana in
|
||
the US), their intrinsic electronic transmission using vacuum tubes
|
||
made a "four-wire" (of virtual wires, certainly) a commonplace in
|
||
intercity transmission. And every "carrier system" since the
|
||
beginning has been made of "four-wire" paths ... set up in pairs of
|
||
channels, one for each direction of transmission, needing that
|
||
"hybrid" function at each end to connect to the local plant.
|
||
|
||
In intercity (and more so international) carrier systems, a
|
||
"line" transiting a junction point can be (and is) connected on a
|
||
"four-wire" basis, either _through_ a "four wire switching machine"
|
||
for PSTN temporary connections, or hard-wired _around_ the switching
|
||
machine if the use is a semi-permanent "special services" circuit,
|
||
like a dedicated data line or indeed, a permanent speech circuit, as
|
||
is CNN's "four-wire line," our subject here. At the end points, one
|
||
local pair is used for each direction of transmission ... at a price
|
||
reflective of using twice the local plant. Local wire pairs ...
|
||
"loops" ... for "special services" are expensive to rent. After all,
|
||
they are no longer available for the local telco to derive PSTN
|
||
revenue on. If reaching the "long lines" point of presence (now
|
||
called a "POP" in American jargon) requires use of local wire
|
||
(nowadays local carrier channels) across a city, these are no longer
|
||
available for "trunk" use between local PSTN exchanges, considerable
|
||
revnue potential is lost, and is going to be paid for. Thus, many
|
||
speech-only "private circuits" do have a hybrid in the "POP" and use
|
||
only one local pair anyway ... but are STILL "four wire channels"
|
||
between cities.
|
||
|
||
The British have some excellent descriptive terminology we
|
||
Americans never developed. They speak of transmission circuits as
|
||
"two wire presented" or "four wire presented" to the end user. These
|
||
terms, of course recognize that long circuits are all "four wire,"
|
||
regardless of how they are 'presented" to the end user.
|
||
|
||
What are the advantages of "four wire presentation?" Avoidance of
|
||
the electrical echo bugaboo. And, part of the "control" of echoes in
|
||
"two-wire presentations" is to deliberately insert transmission loss
|
||
to make the echoes a bit lower, so "four wire presented" channels can
|
||
have less loss and sound louder ... and deliver the received signal
|
||
higher above the noise ... making the signal sound "cleaner." This of
|
||
course is why high-quality dedicated data circuits are four-wire
|
||
presented ... to give the modem signals the most advantage possible.
|
||
|
||
Hopefully, if you have persisted through this longish
|
||
explanation, you now know that the "four wire line" is indeed not rare
|
||
at all. Rather, it is the norm between cities, and especially between
|
||
nations. You know it isn't new. It's just that most people have
|
||
never seen one. Improvements in the local plant (including widespread
|
||
deployment of digital carrier, the "T" carrier so often spoken of
|
||
today) have made extension of the "four-wire line" right into your
|
||
local exchange a reality in most places, so even your PSTN phone
|
||
sounds much louder and cleaner than it did twenty years ago. That's
|
||
what solid-state electronics coupled to digital transmission did for
|
||
us all.
|
||
|
||
Those who really _needed_ the advantages of "four-wire" have used
|
||
it for a long time. Major examples were the FAA's network of
|
||
dedicated lines that had to be interconnected at random (reflected in
|
||
Bell parlance as the "FAA 300-type switching system), and the US
|
||
military's AUTOVON network. While AUTOVON was based on four-wire
|
||
switching machines throughout right to four-wire telephone sets,
|
||
economics even there forced the allowance of two-wire user lines and
|
||
telephones for voice-only stations, and many AUTOVON lines wound up
|
||
being four-wire. But, AUTOVON also has many "four-wire" user stations
|
||
where dedicated-line type "full-duplex' data modems can be used.
|
||
|
||
For those who really want to learn more, I recommend the following books:
|
||
|
||
|
||
1.) "Basic Carrier Telephony" by David Talley, a real chestnut
|
||
of telephone transmission for the non-technical reader who is
|
||
weak on physics. Originally published by Hayden Book Company
|
||
as their stock number 5749 (Library of Congress catalog number
|
||
60-10470 in its second edition, I understand that Wiley in
|
||
New York has republished it and finds several Telcos use it for
|
||
textbook for technicians.
|
||
|
||
2.) "Understanding Communications Systems," by Don L. Cannon and
|
||
Gerald Luecke, originally published and sold by Radio Shack
|
||
stores as part number 62-2018 (ISBN 0-89512-035-6) for $2.95,
|
||
this book has been republished by Howard Sams at Indianapolis
|
||
for about six times the price in hardback. It uses far less
|
||
classic "telephonese" but has excellent ways of showing how
|
||
analog and digital transmission are far more related than most
|
||
non-technical people can understand.
|
||
|
||
I recommend both of these books to the harried educators on here
|
||
who are frustrated in finding short texts for introductory curricula.
|
||
|
||
============================================================================
|
||
|
||
|
||
|
||
/ /
|
||
/ FILE 03 / NIA071 /
|
||
/ Scantronics Publications /
|
||
/ How to Use the U.K. Academic Network /
|
||
/ Packet SwitchStream (PSS) Gateway /
|
||
/ and PSS Address List /
|
||
/ Submitted By: /<ludge /
|
||
/ /
|
||
|
||
_________________
|
||
TABLE OF CONTENTS
|
||
|
||
|
||
1. Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
|
||
|
||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
|
||
2.1 Your contacts . . . . . . . . . . . . . . . . . . . . . . . . . 1
|
||
|
||
3. Summary of Facilities Available Across the Network . . . . . . . . 2
|
||
|
||
4. Permission to Use the Gateway . . . . . . . . . . . . . . . . . . . 2
|
||
4.1 Authentication and Authorisation . . . . . . . . . . . . . . . 2
|
||
4.2 Charging and Accounting . . . . . . . . . . . . . . . . . . . . 3
|
||
|
||
5. How to make Terminal Calls TO the Gateway . . . . . . . . . . . . . 3
|
||
|
||
6. How to make Terminal Calls THROUGH the Gateway . . . . . . . . . . . 4
|
||
6.1 The Transport Service Called Address . . . . . . . . . . . . . 4
|
||
6.2 Making Calls using TS29 Protocol . . . . . . . . . . . . . . . 6
|
||
6.3 The full address . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
6.4 Making Calls Using X29 Protocol . . . . . . . . . . . . . . . . 6
|
||
|
||
7. Facilities Provided by the Gateway Machine . . . . . . . . . . . . . 7
|
||
7.1 HELP Facility . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
7.2 Account Facility and Changing Your Password . . . . . . . . . . 8
|
||
|
||
8. Facilities Available THROUGH the Gateway . . . . . . . . . . . . . . 9
|
||
8.1 Demonstration Facility . . . . . . . . . . . . . . . . . . . . 9
|
||
8.2 Address Mnemonics of Remote Hosts on Networks Connected to
|
||
the Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 9
|
||
|
||
9. Facilities Available on PSS . . . . . . . . . . . . . . . . . . . 10
|
||
9.1 Fast Select . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||
9.2 Reverse Charge Facility . . . . . . . . . . . . . . . . . . . 10
|
||
9.3 Access to IPSS . . . . . . . . . . . . . . . . . . . . . . . 10
|
||
9.4 Calls to Other, Non-Transport Service Networks . . . . . . . 10
|
||
9.5 Adjusting Packet Sizes . . . . . . . . . . . . . . . . . . . 11
|
||
|
||
10. Protocols Available if Supported by Both Local and Remote
|
||
Host Machines . . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||
10.1 Network Independent File Transfer Protocol (FTP) . . . . . . 11
|
||
10.2 JNT MAIL Protocol . . . . . . . . . . . . . . . . . . . . . . 12
|
||
10.3 Job Transfer and Manipulation Protocol (JTMP) . . . . . . . . 12
|
||
|
||
11. Restrictions and Errors . . . . . . . . . . . . . . . . . . . . . 12
|
||
11.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
11.2 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
|
||
|
||
1. Warning
|
||
|
||
BETWEEN 8.00 am and 10.00 am every Tuesday, network development and service
|
||
work is carried out on JANET. This means that if you make a call during
|
||
these hours there is an increased danger of the system going down which may
|
||
result in loss of data.
|
||
|
||
_________________
|
||
2. Introduction
|
||
|
||
The Gateway is a two-way link between the U.K. Academic Network (JANET) and
|
||
PSS. At present there are two Gateways between JANET and PSS, one at
|
||
Rutherford and another at ULCC in <garbled>.
|
||
The Gateway consists of a computer which holds a communications program and
|
||
sits between two networks (JANET and PSS in this case). This allows the
|
||
user to bridge the gap between the networks and access target computers on
|
||
the other network. It is important to realise that there are two ways of
|
||
communicating with the Gateway - you can make calls TO the Gateway computer
|
||
to access its limited user facilities or you can make calls THROUGH it to a
|
||
target computer on the other network.
|
||
|
||
The Gateway operates as a Transport Level Gateway in accordance with the
|
||
'Yellow Book' Transport Service. However the present implementation does
|
||
not have a full Transport Service and therefore, there are some limitations
|
||
in the service provided. For X29 which is incompatible with the Yellow Book
|
||
Transport Service, special facilities are provided for the input of user
|
||
identification and addresses.
|
||
|
||
The Gateway is a protocol transparent link. This means that the Gateway
|
||
cannot be used for protocol conversion; to do this a third party machine
|
||
must be used.
|
||
|
||
__________________
|
||
2.1 Your Contacts
|
||
|
||
If you have any problems, or if you want additional information contact the
|
||
JANET Network Executive. You can reach them at the following address:-
|
||
|
||
* By Post at . . . . . . . Network Executive,
|
||
c/o Rutherford Appleton Laboratory,
|
||
Chilton,
|
||
Didcot,
|
||
OXON.
|
||
OX11 0QX
|
||
|
||
* By Electronic MAIL to . . PSS Gateway Support@RL.GB
|
||
The network address for RL.GB is 00000000210
|
||
5
|
||
|
||
* By Telephone on . . . . . Abingdon (O235) 446748
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
_______________________________________________________
|
||
3. Summary of Facilities Available across the Network
|
||
|
||
The network offers a number of facilities. These are listed below for your
|
||
information.
|
||
|
||
* Facilities Provided by the Gateway Machine
|
||
|
||
- Help Facility
|
||
|
||
- Accounting Facility
|
||
|
||
* Facilities Available on the Way Through the Gateway
|
||
|
||
- Demonstration Facility
|
||
|
||
- Addresses and Mnemonics
|
||
|
||
* Facilities Available on PSS
|
||
|
||
- Fast Select Facility
|
||
|
||
- Reverse Charge Facility
|
||
|
||
- Access to IPSS (International Packet Switch Stream)
|
||
|
||
- Calls to Other, Non-Transport Service Networks
|
||
|
||
* Protocols Available if Supported by Both Local and Remote Host Machine
|
||
s
|
||
|
||
- Network Independent File Transfer Protocol (FTP)
|
||
|
||
- JNT MAIL Protocol
|
||
|
||
- Job Transfer and Manipulation Protocol (JTMP)
|
||
|
||
__________________________________
|
||
4. Permission to Use the Gateway
|
||
|
||
_____________________________________
|
||
4.1 Authentication and Authorisation
|
||
|
||
No unauthenticated use of the Gateway from JANET is allowed regardless of
|
||
whether charges are incurred at the Gateway or not. Therefore to use the
|
||
Gateway you have to obtain authentication (a userid and password) and
|
||
authorisation (a call allocation) from the JANET Network Executive. This
|
||
consists of:
|
||
|
||
a. USERID
|
||
b. PASSWORD
|
||
c. USAGE ALLOCATION
|
||
|
||
Note that the authorisation for PSS and IPSS is managed separately, although
|
||
a single USERID may have authoristation for both.
|
||
|
||
There is no restriction on access from PSS.
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
____________________________
|
||
4.2 Charging and Accounting
|
||
|
||
There are 4 separate charging rates, which are:
|
||
|
||
PSS full rate: PSS (FULL)
|
||
PSS discount rate: PSS (DISC)
|
||
TLXN: Telex access via Interstream 1.
|
||
IPSS full rate: IPSS (FULL)
|
||
|
||
Note that the TELEX access is expensive, as the cost includes the use of
|
||
PSS, Interstream 1 and TELEX. Anyone who is interested in TELEX access
|
||
should first discuss it with the Network Executive.
|
||
|
||
To be able to make chargeable calls you must request a call allocation to
|
||
cover the charging rates you want to use when you ask for your
|
||
authentication. For calls that are free e.g. calls within JANET or normal
|
||
charge calls from PSS you do not need an allocation.
|
||
|
||
The PSS discount rate applies from 1800 to 0800 each night and all day on
|
||
Sundays, Christmas Day and New Year's Day. The PSS full rate applies at ALL
|
||
OTHER times. The IPSS full rate applies at ALL times for international
|
||
calls. For details of the international rates to various countries consult
|
||
Network User Note 2.
|
||
|
||
If your allocation runs out during an active call, then that call will be
|
||
cleared and all further calls at that rate will be refused.
|
||
|
||
______________________________________________
|
||
5. How to Make Terminal Calls to the Gateway
|
||
|
||
It is possible to make calls to the Gateway to access the HELP and ACCOUNT
|
||
facilities.
|
||
|
||
The HELP facility contains the whole of this user guide in its most uptodate
|
||
form. The facility allows random scans of the document and searches for
|
||
text within the document.
|
||
|
||
The Account facility allows the user to inspect the state of his account and
|
||
to change the password for that account.
|
||
|
||
_____________________________________
|
||
How to make contact with the Gateway.
|
||
|
||
If you are calling the RAL Gateway from PSS use the DTE address
|
||
234223519191.
|
||
|
||
If you are calling the RAL Gateway from JANET use the DTE address
|
||
000000000040.
|
||
|
||
If you are calling the London Gateway from PSS use the DTE address
|
||
234219200100.
|
||
|
||
If you are calling the London Gateway from JANET use the DTE address
|
||
000040000040.
|
||
|
||
Make a terminal call to the Gateway.
|
||
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
A title message will appear on the terminal announcing the Gateway, followed
|
||
by the lines:
|
||
|
||
OS4000+Rlix V30 PSS Gateway
|
||
Logging in
|
||
user
|
||
|
||
If nothing appears, keep pressing <CARRIAGE RETURN> until the above message
|
||
appears.
|
||
|
||
It is now possible to log in and use the Help or Account facilities. For
|
||
details of these facilities see section 7 of this document.
|
||
|
||
___________________________________________________
|
||
6. How to Make Terminal Calls Through the Gateway
|
||
|
||
The method used to make a call through the Gateway depends on the type of
|
||
PAD being used. If your PAD supports TS29 the procedure is simplified as
|
||
this protocol allows you to make calls that can cross several networks via
|
||
several Gateways. If your PAD supports X29 then if you wish to cross
|
||
several Gateways you normally have to stop at each one before you can pass
|
||
through it. However a special facility is provided using the Call User Data
|
||
Field to allow X29 calls non-stop through the JANET PSS Gateway.
|
||
|
||
Whichever protocol your PAD supports, you must have some way of generating a
|
||
Transport Service Called Address for onward routing by the Gateway.
|
||
|
||
_________________________________________
|
||
6.1 The Transport Service Called Address
|
||
|
||
To make a call through the Gateway you have to supply the following
|
||
information in the form of a Transport Service Called Address to your local
|
||
PAD.
|
||
|
||
a. Netname: the name of the network you are calling.
|
||
b. Authentication: consisting of Userid and Password in that order.
|
||
This can be omitted for free calls.
|
||
c. Host address: the network address of the remote host.
|
||
|
||
The format of the Transport Service Called Address is as follows:
|
||
|
||
<Netname>(<Authentication>).<Host Address>
|
||
|
||
These are explained below.
|
||
|
||
_______
|
||
Netname
|
||
|
||
This is one of the following:
|
||
|
||
JANET to connect to JANET
|
||
PSS to connect to PSS
|
||
J an alias for JANET.
|
||
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
______________
|
||
Authentication
|
||
|
||
This consists of 3 fields which must be entered in the order shown.
|
||
|
||
a. user id,
|
||
b. password,
|
||
c. A request for the call to be reverse charged.
|
||
|
||
The last field is optional.
|
||
|
||
____
|
||
Note that the whole authentication string must be enclosed in parentheses.
|
||
|
||
_______
|
||
Example
|
||
|
||
(FRED,XYZ,R) Requests a reverse charge call
|
||
(FRED,XYZ) Requests a chargeable call.
|
||
|
||
____________
|
||
Host Address
|
||
|
||
This is the numeric address of the machine being called. However to make
|
||
things easier the numeric address can be replaced with an alphanumeric
|
||
mnemonic if one has been set up on the Gateway.
|
||
|
||
_______
|
||
Example
|
||
|
||
use RLGB instead of 000000002105 to call the Rutherford GEC 'B' machine
|
||
use SALF instead of 234261643210 to call Salford on PSS.
|
||
|
||
For a list of these mnemonics see JANET User Notes 5 and 6.
|
||
|
||
Host addresses can be complex and it is possible to specify several Gateways
|
||
that you must pass through to reach a specific remote host and/or the
|
||
service required. Note that a point (.) must be used to separate the
|
||
numeric addresses or mnemonics from the service names.
|
||
|
||
_______
|
||
Example
|
||
|
||
RLPA - this calls the Rutherford ICF Prime on Janet.
|
||
RLPA.FTP - this calls FTP on the Rutherford ICF Prime on Janet.
|
||
|
||
To connect to some machines, an X25 sub-address is required, which consists
|
||
of a number of extra digits added on to the machine address. This can be
|
||
easily entered on the Gateway by using the delimiter '-' at the end of the
|
||
mnemonic address and then typing the sub-address. When the mnemonic is
|
||
translated the delimiter is ignored and the whole address is converted into
|
||
a continuous string.
|
||
|
||
_______
|
||
Example
|
||
|
||
|
||
Janet-69 is translated to 23422351919169
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
_____________________________________
|
||
6.2 Making Calls Using TS29 Protocol
|
||
|
||
TS29 is the ideal protocol to use through the Gateway, since there should be
|
||
no problem entering the Transport Service Called Address. However, first
|
||
make sure that the machine you are calling will support TS29. When using
|
||
this protocol for network terminal calls the service name of the TS29 server
|
||
should be entered explicitly.
|
||
|
||
_____________________
|
||
6.3 The Full Address
|
||
|
||
Combining all these factors a full address might look like this.
|
||
|
||
J(FRED,XYZ).RLGB.TS29
|
||
|
||
____________________________________
|
||
6.4 Making Calls Using X29 Protocol
|
||
|
||
X29 is incompatible with the 'Yellow Book' Transport Service and some PADS
|
||
are unable to generate the Transport Service Called Address. When making an
|
||
X29 call, the onward Called Address may be entered into the Call User Data
|
||
Field of the Call. Some PADs, e.g. the British Telecom PAD are unable to
|
||
generate a Call User Data Field longer than 12 characters and so there may
|
||
not be enough space to hold all the information required. In this case, a
|
||
Call must be established only as far as the Gateway, and a dialogue held
|
||
with the Gateway to establish the next part of the connection.
|
||
|
||
If your PAD can generate a Call User Data Field, then the first character of
|
||
the text is treated as a delimiter, and should be entered as the character
|
||
'@' followed by the onward Called address.
|
||
|
||
_______
|
||
Example
|
||
|
||
On a CAMTEC PAD one might enter:-
|
||
|
||
CALL 00004000004096 D=@(FRED,XYZ).SOMEWHERE
|
||
|
||
t
|
||
make a call through the London Gateway to SOMEWHERE on PSS.
|
||
|
||
________________________________________
|
||
Overcoming Call User Data Field Problems
|
||
|
||
With X29 PADs the onward Called Address can be supplied interactively at the
|
||
Gateway without having to set up a Call User Data field. To do this the
|
||
Gateway must be called with the correct X25 sub-address. This involves
|
||
adding an extra 2 digits onto the normal 12 digit address of the Gateway.
|
||
The sub-address for JANET is 69 and 96 for PSS. The Gateway will then
|
||
prompt for the onward Called Address.
|
||
|
||
The procedure is as follows: Call the Gateway using the correct
|
||
sub-address:
|
||
|
||
23422351919169 to call JANET from PSS via the RAL Gateway
|
||
00000000004096 (or the mnemonic RL.PSS) to call PSS from JANET
|
||
via the RAL Gateway.
|
||
|
||
23421920010069 to call JANET from PSS via the London Gateway
|
||
00004000004096 (or the mnemonic LON.PSS) to call PSS from
|
||
JANET via the London Gateway.
|
||
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
The response from the Gateway will be the following message:
|
||
|
||
Please enter your authorisation and address required in form:
|
||
(user,password).address
|
||
>
|
||
|
||
Reply with the appropriate response.
|
||
|
||
_______
|
||
Example
|
||
|
||
(FRED,XYZ).SOMEWHERE
|
||
|
||
As the X29 protocol is being used there is no need to include the service
|
||
name X29.
|
||
|
||
Authentication is not required for incoming calls to JANET. In this case
|
||
the string (FRED,XYZ) can be omitted, note however that the address should
|
||
still be preceded with a point.
|
||
|
||
_______
|
||
Example
|
||
|
||
.RLGB
|
||
|
||
There is a timeout of between 3 and 4 minutes for this response after which
|
||
the call will be cleared, however there is no limit to the number of
|
||
attempts which can made within this time limit. If the authorisation or
|
||
adress entered is invalid the Gateway will request it again. To abandon the
|
||
attempt clear the call from the PAD. For further details of how to do this
|
||
see Network User Note 11.
|
||
|
||
You will find that on some PADs a 'call connected' message will appear on
|
||
the terminal as soon as the call has been connected to the Gateway. This
|
||
does not mean that you have made contact with your ultimate destination.
|
||
When you have contacted the remote host the Gateway will show a 'Call
|
||
connected to remote address' message.
|
||
|
||
_______________________________________________
|
||
7. Facilities Provided by the Gateway Machine
|
||
|
||
__________________
|
||
7.1 HELP Facility
|
||
|
||
A HELP Facility is available which contains the whole of this guide in its
|
||
most uptodate form. The utility which is used to view the guide allows the
|
||
text to be searched for strings as well as allowing random movement about
|
||
the document.
|
||
|
||
There is also additional up-to-the-minute information and details of
|
||
forthcoming changes. Use the HELP system from time to time to find out
|
||
about changes which may affect your access to the machine.
|
||
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
To connect to the HELP system, simply make a terminal call to the Gateway as
|
||
described in section 5 above. When the Logging in / User prompt appears
|
||
type HELP. The following message will then be displayed.
|
||
|
||
OS4000+Rlix V30 PSS Gateway
|
||
Logging in
|
||
user HELP
|
||
ID last used Wednesday, 10 December 1986 06:11
|
||
Started - Wed 10 Dec 1986 11:15:55
|
||
Please enter your name and establishment.
|
||
|
||
Enter your name and establishment. You will be then be presented with the
|
||
following message.
|
||
|
||
The following options are available:
|
||
|
||
NOTES GUIDE TITILES ERRORS TARRIF HELP QUIT
|
||
|
||
Which option do you require?
|
||
|
||
The following list describes each command briefly.
|
||
|
||
NOTES replies to user queries and any other useful information.
|
||
GUIDE the complete Gateway user guide.
|
||
TITLES list of JANET and PSS addresses and mnemonics
|
||
ERRORS list of error codes that you may receive.
|
||
TARRIF list of the PSS and IPSS charges.
|
||
HELP is the HELP option.
|
||
QUIT exits from the session.
|
||
|
||
When you exit from the HELP facility by typing QUIT, the following message
|
||
will appear.
|
||
|
||
If you have any comments, please type them now, terminate with E
|
||
on a line on its own. Otherwise just type <cr>
|
||
|
||
CPU used: 1 ieu, Elapsed: 2 mins, IO: 1583 units, Breaks: 14
|
||
Budgets: this period = 10.00 AUs, used = 0.010 AUs, left = 9.51 AUs
|
||
User HELP terminal 2 logged out Wed 10 Dec 1986 09:20:12
|
||
|
||
The above prompt gives the user an opportunity to type in any queries or
|
||
comments that he has about the Gateway. These comments are viewed daily by
|
||
the support staff at RAL.
|
||
|
||
________________________________________________
|
||
7.2 Account Facility and Changing Your Password
|
||
|
||
An account can be inspected and the password changed by using this facility.
|
||
First make a call to the Gateway as described in section 5. When the
|
||
Logging in /User prompt appears type ACNT.
|
||
|
||
After a short delay, there will be a prompt for a Userid. Enter your PSS
|
||
userid, you will then be prompted for your password. Enter your password
|
||
(this is not echoed), three attempts are allowed to enter the correct
|
||
password. The message 'Enter command' will now appear.
|
||
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
_______
|
||
Example
|
||
|
||
OS4000+Rlix V30 PSS Gateway
|
||
Logging in
|
||
user ACNT
|
||
ID last used Wednesday, 10 December 1986 09:14
|
||
Enter userid FRED
|
||
Password
|
||
|
||
Enter command
|
||
|
||
The following commands are available:
|
||
|
||
ACCOUNT Prints the state of your account on the terminal
|
||
|
||
PASSWORD Allows the password to be changed. The new password
|
||
should be typed in twice on the following two
|
||
lines when prompted. It is not echoed
|
||
|
||
END Terminates the session.
|
||
|
||
Note that each command may be abbreviated to a minimum of 2 characters.
|
||
|
||
_____________________________________________
|
||
8. Facilities Available Through the Gateway
|
||
|
||
___________________________
|
||
8.1 Demonstration Facility
|
||
|
||
There is an account available which has a small allocation available for
|
||
users to try out the Gateway. The password will be supplied on request from
|
||
the Network Executive. Note that excessive use of this account will soon
|
||
exhaust its allocation and deprive others of its use.
|
||
|
||
___________________________________________________
|
||
8.2 Address Mnemonics of Remote Hosts on Networks
|
||
________________________
|
||
Connected to the Gateway
|
||
|
||
Many network addresses consist of 12 or even 14 digits which may be
|
||
rm 33; Next>
|
||
|
||
difficult to remember and awkward to enter. To make life easier the Gateway
|
||
has a table which consists of a number of mnemonics and their respective
|
||
network addresses. When these mnemonics are typed within a call through the
|
||
Gateway the mnemonic is translated into the appropriate network address.
|
||
|
||
Therefore if you have a frequently used network address which is not in the
|
||
table, please contact the Network Executive with a request to insert the
|
||
address along with an appropriate mnemonic. Equally if you know of
|
||
mnemonics which are no longer useable contact the Network Executive.
|
||
|
||
It is hoped that the Gateway will support the Network Registration Scheme
|
||
(NRS) in the near future.
|
||
|
||
JANET User Notes 5 and 6 include mnemonics for a number of remote machines
|
||
and networks on both PSS and JANET.
|
||
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
_______________________________
|
||
9. Facilities Available on PSS
|
||
|
||
________________
|
||
9.1 Fast Select
|
||
|
||
This allows calls to have up to 128 bytes in the Call User Data field. You
|
||
can use this to expand address information available for the next hop of the
|
||
call. As a PSS user we have subscribed to this facility; however you
|
||
should note that some remote Hosts on PSS and IPSS cannot accept Fast Select
|
||
calls. If a Fast Select call is made to an address which does not subscribe
|
||
to the Fast Select facility the call will fail with clearing code Hex'29'.
|
||
|
||
When a mnemonic is used, the Gateway will know whether the address can
|
||
support Fast Select or not, and will make the correct call automatically.
|
||
|
||
If the full numeric address is used, then the Gateway has to be told not to
|
||
use Fast Select. This can be done by preceding the address with the string
|
||
'NFS-'. In fact the NFS is a mnemonic which translates to a null string
|
||
with the No Fast Select attribute and the minus is just a delimiter which
|
||
will be ignored.
|
||
|
||
For example, calling TELENET
|
||
|
||
PSS(FRED,XYZ).NFS-311012345678
|
||
|
||
____________________________
|
||
9.2 Reverse Charge Facility
|
||
|
||
If this facility is used the remote Host will accept all the call charges,
|
||
therefore your allocation on the Janet Gateway will not be debited. Note
|
||
that there are not many remote Hosts which will accept 'reverse charging'.
|
||
|
||
Unfortunately the only way to find out if a remote Host will accept reverse
|
||
charging is to experiment. Do this by appending 'R' to the authorisation
|
||
field, for example
|
||
|
||
(FRED,XYZ,R)
|
||
|
||
If this does not work, it could be because the remote host will only accept
|
||
calls from 'known' network addresses and the JANET addresses are 'unknown'
|
||
|
||
___________________
|
||
9.3 Access to IPSS
|
||
|
||
It is possible to access IPSS, the International Packet Switch Stream,
|
||
through PSS. This is done by entering the IPSS address in place of the PSS
|
||
address. IPSS calls are accounted separately from PSS so you will have to
|
||
make a specific request for an IPSS allocation before you make calls on
|
||
IPSS.
|
||
|
||
___________________________________________________
|
||
9.4 Calls to Other, Non-Transport Service Networks
|
||
|
||
Some networks (for example, TYMNET) require a Call User Data Field with a
|
||
different format from the one normally generated by the Gateway. A facility
|
||
has been provided to enable an arbitrary string to be included in the Call
|
||
User Data Field. This is done by terminating the numeric address (or
|
||
mnemonic) with the delimiter '*D' followed by the required string.
|
||
Everything following the '*D' is then copied into the Call User Data Field.
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
_______
|
||
Example
|
||
|
||
PSS(FRED,XYZ).NFS-31060000*DZRRT;IPSSLON
|
||
|
||
This would call a (fictitious) address on TYMMNET.
|
||
|
||
Finally some machines do not expect to receive any user data at all, so you
|
||
will need to enter '*D' on its own for these.
|
||
|
||
_______
|
||
Example
|
||
|
||
PSS(FRED,XYZ).YONDER*D
|
||
|
||
___________________________
|
||
9.5 Adjusting Packet Sizes
|
||
|
||
The Gateway normally tries to establish its calls with a packet size of 256
|
||
bytes, even if the incoming call had only 128 byte packets. This normally
|
||
does not cause problems, but there may be difficulties with some systems.
|
||
If you find your call being cleared even though all the addressing is
|
||
correct, or if it fails as soon as data starts to flow, try calling with the
|
||
additional data, '*P7W2', to force a packet size of 128 bytes.
|
||
|
||
_______
|
||
Example
|
||
|
||
PSS(FRED,XYZ).OVERTHERE*P7W2
|
||
|
||
If you also need to use the *D parameter that must follow the *P/W paramter.
|
||
|
||
_______
|
||
Example
|
||
|
||
PSS(FRED,XYZ).HERE*P7W2*DTOYOU
|
||
|
||
___________________________________________________
|
||
10. Protocols Available if Supported by Both Local
|
||
________________________
|
||
and Remote Host Machines
|
||
|
||
Other sorts of calls, besides terminal calls, may be possible through the
|
||
Gateway. In these cases Transport Service is required. The mechanisms
|
||
required for insertion of authorisation information vary from computer to
|
||
computer, and therefore your local support staff should be consulted for
|
||
information in this area.
|
||
|
||
Care needs to be exercised here, especially when replying to MAIL from PSS
|
||
without considering how the authorisation will be managed. Problems can
|
||
also occur with FTP, which will continue to retry a call until it receives a
|
||
fatal error, causing unnecessary network traffic.
|
||
|
||
_____________________________________________________
|
||
10.1 Network Independent File Transfer Protocol (FTP)
|
||
|
||
This allows files from one computer's file store to be sent to the file
|
||
store of another computer. Although the two computers may have very
|
||
different ways of working internally, FTP will overcome these difficulties
|
||
and arrange for the transfer of the file without the user being aware of the
|
||
special procedures that are being carried out.
|
||
|
||
|
||
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
|
||
|
||
|
||
______________________
|
||
10.2 JNT MAIL Protocol
|
||
|
||
This allows MAIL messages to be sent from one user to another user. The
|
||
users may be using the same machine or may be using machines on different
|
||
networks. In both cases the user types his message into the machine being
|
||
used and the MAIL program then adds a header to the message, so that it can
|
||
be transmitted to the remote Host by FTP. The received message is stored on
|
||
the remote Host and made available to the addressee.
|
||
|
||
__________________________________________________
|
||
10.3 Job Transfer and Manipulation Protocol (JTMP)
|
||
|
||
This protocol lets you:
|
||
|
||
transfer files for storage or execution
|
||
make status enquiries and get reports on these files.
|
||
modify the progress of the above.
|
||
|
||
This protocol requires standard FTP to carry out the transfers.
|
||
|
||
____________________________
|
||
11. Restrictions and Errors
|
||
|
||
_________________
|
||
11.1 Restrictions
|
||
|
||
Due to the present lack of a full Transport Service in the gateway, the
|
||
ADDRESS, DISCONNECT and RESET primitives are not fully supported. However
|
||
this should not present serious problems, since the ADDRESS and RESET
|
||
primitives are not widely used, and the DISCONNECT primitive can be carried
|
||
in a Clear Request packet.
|
||
|
||
The gateway does however support continuation of Transport Service Connect
|
||
messages into the first data packet. This is particularly useful when
|
||
attempting file transfers for which the 12-byte CUDF limitation pertains
|
||
(i.e. NSF- calls).
|
||
|
||
___________
|
||
11.2 Errors
|
||
|
||
When a call fails, there is an error code associated with the failure which
|
||
will normally be displayed on your PAD. A list of the most common codes and
|
||
their meanings is given in Network User Note 15.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
PSS Address List
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
____________
|
||
Introduction
|
||
|
||
This is an address list of all the mnemonics that can be accessed via the
|
||
JANET Packet SwitchStream Gateway.
|
||
|
||
The list is sorted in numerical order using the machine address. The first
|
||
three digits of the address are a code which indicates the country where the
|
||
machine is situated. Headings appear throughout the list giving the country
|
||
name followed by the machines available there.
|
||
|
||
|
||
The list is divided into 3 columns which show:
|
||
|
||
a. The numeric address (DTE address)
|
||
|
||
b. A mnemonic for the address
|
||
|
||
c. A description of where the machine is located.
|
||
|
||
|
||
|
||
____________
|
||
Address List
|
||
|
||
_______ ________ ___________
|
||
ADDRESS MNEMONIC DESCRIPTION
|
||
|
||
Netherlands
|
||
|
||
204 NL Netherlands
|
||
20412900433 SARA National Institute for High Enery
|
||
Physics (NIKHEF) SARA network
|
||
20412900434 NIKHEF National Institute for High Enery
|
||
Physics (NIKHEF) SARA network
|
||
204129004353 NIKHEFH NIKHEF Gould
|
||
20418800110680 CELEX CELEX Lexical Database, Nijmegen
|
||
|
||
Belgium
|
||
|
||
206 B Belgium
|
||
2062210168 BBVA Brussels DEC A (Belgium) - 9600 bps
|
||
2062221006 BBDA Brussels DEC A (Belgium) - 2400 bps
|
||
|
||
|
||
|
||
France
|
||
|
||
208 F France
|
||
2080 TRANSPAC French Transpac
|
||
208031001511 ARGOS Argos service at Toulouse
|
||
208034020258 CNUSC CNUSC Montpelier
|
||
20803802067602 ILLDA ILL DEC-10 at Grenoble
|
||
20806911011912 FRCPN11 HEP Computing Centre, Paris
|
||
208075000394 IRST ESA - Quest
|
||
208075001282 FRCPN11X HEP Computing Centre, Paris
|
||
208075040390*DV6 MINITEL French Prestel
|
||
208075040390*DV2 MINITEL1 French Prestel
|
||
20807802016901 INRIA Institute National de Recherche
|
||
en Infoatique ...
|
||
208091000309*DCISIFMST CISI IBM - TSO
|
||
208091000309*DCISIFMST CISI1 IBM - TSO
|
||
208091000519*DCISIFMST CISI2 IBM - TSO
|
||
208091000270*DCISIFMST CISI3 IBM - TSO
|
||
208091010320 CJRCE
|
||
20809104057310 SIMBAD Stellar data centre CDC system
|
||
2080911101 SACLAY Saclay - France
|
||
|
||
|
||
Spain
|
||
|
||
214 E Spain
|
||
2141 SPAIN Spanish data network
|
||
2145222020109 LAPALMA La Palma Observatory, Canaries
|
||
|
||
Yugoslavia
|
||
|
||
220 Y Yugoslavia
|
||
2201 YUPAK Yugoslav YUPAK
|
||
220161120100 RRC RRC Computer Centre, Ljubljana
|
||
220161140001 LJUBLJANA University of Ljubljana, DEC 10 & 20
|
||
220161140015 STEFAN Institute of Jozef Stefan, Ljubljana
|
||
220162120031 MARIBOR University of Maribor - VAX 8800
|
||
|
||
Italy
|
||
|
||
222 I Italy
|
||
2222260164608 ISPRA Euratom Joint Research Centre
|
||
2222650143 ESA2 ESA - IRS
|
||
|
||
|
||
|
||
Switzerland
|
||
|
||
228 CH Switzerland
|
||
228464110115 DATASTAR2 Data-Star, Switzerland
|
||
22846431007014 DATASTAR Data-Star, no-echo on password
|
||
22848411011014 DATASTAR1 Data-Star, no-echo on password
|
||
2284681140510*DLO CERNLO CERN 300 bps
|
||
2284681140510*DME CERNME CERN 1200 bps
|
||
|
||
Austria
|
||
|
||
232 A Austria
|
||
|
||
UK
|
||
|
||
234 GB United Kingdom
|
||
2341 IPSS IPSS UK network
|
||
23421230012000 DIALOG6 DIALOG2 in US
|
||
23421230012011*D DIALOG2 DIALOG2 in US
|
||
23421230012011*D DIALOG DIALOG2 in US
|
||
23421230012013*D DIALMAIL DIALMAIL in US
|
||
234212300120*D@ DIALNET IGS Leased line to DIALOG in US
|
||
234212300187 TELEMAIL Telemail
|
||
23421230021001 CAMPUS2000 Campus 2000
|
||
23421230021001 TTNS Times Network System 01
|
||
2342123012026 DATASTREAM Datastream Service
|
||
234212300331 LASER LASER
|
||
234213300124 PROFILE Was Datasolve
|
||
234215700117 CONTEXT Context Legal Systems
|
||
234215700147 ORBIT Orbit.
|
||
234216401146 GOULDUK Gould Uk in Surrey
|
||
234216700127 PCR Pfizer Central Research
|
||
234219200101 FINSBURY
|
||
234219200146*D CEGB CEGB, Park Street, London
|
||
23421920014870 EAN EAN Gateway at ULCC
|
||
234219200171 LEXIS LEXIS/NEXIS
|
||
234219200190 INFOLINE Pergamon - Infoline
|
||
234219200203 IPSH IP-SHARP
|
||
234219200300 UCL University College London -
|
||
Computer Science
|
||
234219200394*D AREMOS Sianet
|
||
234219201002 POOLE PCL - Poole C.A.E. Service
|
||
23421920100404 BTGOLD04 BTGOLD service.
|
||
23421920100474 BTGOLD74 BTGOLD service.
|
||
23421920100476 BTGOLD76 BTGOLD service.
|
||
23421920100479 BTGOLD79 BTGOLD service.
|
||
23421920100479 LANET BTGOLD 79 service.
|
||
23421920100481 BTGOLD81 BTGOLD service.
|
||
23421920100482 BTGOLD82 BTGOLD service.
|
||
23421920100483 BTGOLD83 BTGOLD service.
|
||
23421920100484 BTGOLD84 BTGOLD service.
|
||
23421920100487 BTGOLD87 BTGOLD service.
|
||
234219201004 BTGOLD BTGOLD service.
|
||
23421920100513 EUROINFO Euronet Diane Information Service
|
||
23421920100515 HOSTESS Hostess system (BT)
|
||
23421920102517 PRESTEL Prestel
|
||
234219201156 ERS ESA - Quest
|
||
234219201156 ESA ESA - Quest
|
||
23421960116750 HRC GEC - Hirst Research (Mail)
|
||
234219709111 NPL1 NPL - use subaddress 04
|
||
234219709210 NPL2 National Physical Laboratory
|
||
2342212001450 OCLC
|
||
234222339399 CAMB University of Cambridge
|
||
234222715151 KENT University of Kent
|
||
234223519191 JANET Gateway to JANET at Rutherford
|
||
234227900102 BLAISE British Library Information System
|
||
234231354354 ERCC Edinburgh Regional Computer Centre
|
||
234233400101 BEST B.E.S.T. Database, Longman
|
||
Cartermill, St. Andrews
|
||
234212900115 STL STL
|
||
234243800105 IDEC STL IDEC
|
||
23426164336548*P7*W2 ICLB ICL network at Manchester
|
||
23424830012489 SUNCAM SUN Microsystems - Camberley
|
||
234248300124 SUN SUN Microsystems - Camberley - mail
|
||
23425272424111 INFOSEARCH ISTEL Communications Network
|
||
23425330012406 CAMTEC Camtec, Leicester (hard copy printer)
|
||
234253300124 CAMTEC Camtec, Leicester
|
||
23426160013930 NCC National Computing Centre - LEO
|
||
234261600152 UMDAFL University of Manchester Dataflow VAX
|
||
23426164321090 NRS NRS
|
||
234261643210 SALF Salford University
|
||
234261643343 FERRANTI Ferranti Computer Systems
|
||
23423440016782 PRIME Prime - Leeds
|
||
234263259159 NUMAC University of Newcastle
|
||
234274200103*DCODUS CODUS Codus
|
||
234284400108 CULHAM Culham Laboratory
|
||
234284400162 PFDS Pergamon Financial Data Systems
|
||
23428580010801*D LIBTELVT Menzies LIBTEL for VT100 terminals.
|
||
23428580010802*D LIBTELTV Menzies LIBTEL for TV910, etc
|
||
23428580010803*D LIBTELADM Menzies LIBTEL for ADM3 terminals.
|
||
23429084011100*d POLIS SCION
|
||
234293765265 ARTTEL British Library, Boston Spa
|
||
2348 TELEX UK Telex network
|
||
23523592592500 KINGLINE Hull Telephone GOLD system
|
||
|
||
Denmark
|
||
|
||
238 DK Denmark
|
||
238241745600 RECKU Univac in Copenhagen University
|
||
|
||
Sweden
|
||
|
||
240 S Sweden
|
||
2405 SWEDEN Swedish data network
|
||
240200100110 QZDB QZ via reverse pad.
|
||
240200101915 QZCOM80 QZCOM NIFTP80 service.
|
||
240200101928 QZXA UPNOD local network
|
||
2402001027 QZXB Stockholm University Computing
|
||
Centre Gateway.
|
||
240200102701 QZCOM QZ ODEN DEC-10
|
||
|
||
Norway
|
||
|
||
242 N Norway
|
||
2422 NORWAY Norwegian data network
|
||
242211000107 OSLO DEC10 at Oslo University
|
||
242223000151 RBK Cyber 170 at IFE (Energy Research
|
||
Centre), Kjeller
|
||
242245000101 BERGEN Univac at Bergen University
|
||
242253000101 RUNIT Univac at Trondheim University
|
||
242265000101 TROMSOE Cyber at Troms University
|
||
|
||
Finland
|
||
|
||
244 SF Finland
|
||
244203008 HELVA High Energy Physics Vax,
|
||
University of Helsinki
|
||
|
||
Russia
|
||
|
||
2502040300 NCADE NCADE USSR electronic mail, Moscow
|
||
|
||
Germany
|
||
|
||
262 D Germany
|
||
2624 GERMANY German data network
|
||
26245221040006*d DIMDI
|
||
26245221040104*d DIMDI2
|
||
26245228040187 BNVA Bonn VAX
|
||
26245234040194 RUB Cyber 205, Ruhr University - Bochum
|
||
262453000217 HMI Hans Mietner Institute in Berlin
|
||
26245300043042 DFNHELP Help system at DFN in Berlin
|
||
2624540009306 DYVA MARK J VAX at DESY
|
||
26245615144000 ESOC European Space Operations Centre,
|
||
Darmstadt
|
||
2624562213002 EMBL ALKOR VAX
|
||
26245724790114 CASGER2 STN International - 48K link
|
||
26245724720001 CASGER STN International - 64K link
|
||
262457610420*D FREIBURG Freiburg University
|
||
26245772340095 FURTWANGEN Furtwangen, W. Germany
|
||
26245890040220 IPP Max Planck Institute of
|
||
Plasma Physics, Garching
|
||
26245890090218 MPE Max Planck Institute for Extra
|
||
Terrestial Physics
|
||
2624589009301 ESO European Southern Observatory
|
||
in Germany VAX 11/780
|
||
|
||
Portugal
|
||
|
||
268 P Portugal
|
||
|
||
Luxembourg
|
||
|
||
270 L Luxembourg
|
||
270429200*D ODPECC Office for Official Publications,
|
||
European Communities Commision.
|
||
270448112*D ECHO IES - DC
|
||
|
||
Ireland
|
||
|
||
272 IRL Ireland
|
||
272431001992 EUROKOM EEC harmonisation COM system at
|
||
UC, Dublin - inverse PAD
|
||
27243159000630 UCD EEC harmonisation COM system at
|
||
UC, Dublin - local X25 net
|
||
|
||
Canada
|
||
|
||
302 CDN Canada
|
||
3020 DATAPAC Canadian Datapac
|
||
302067200040 UBCVCR Amdahl, Univ British Columbia,
|
||
Vancouver
|
||
302068100058 UVIC Victoria University, British Columbia
|
||
302068100256 UVICVVA Physics VAX, Victoria University,
|
||
British Columbia
|
||
302083200013 TRIUMF The Tri-University Meson Facility,
|
||
Vancouver
|
||
3025 GLOBEDAT Canadian Globedat
|
||
3029 INFOSWITCH Canadian Infoswitch
|
||
3103 ITT USA - ITT
|
||
31033010000542 DIALCOM42 DIALCOM - System 42
|
||
3104 WUI USA - WUI
|
||
3104004759 MCI MCII mail system
|
||
|
||
USA - TYMNET
|
||
|
||
3106 TYMNET USA - Tymnet
|
||
3106*DENSCL ONTYME ONTYME information system
|
||
3106*DINFORMATION TYMNETINFO TYMNET information system
|
||
3106001475 SDC2
|
||
3106001509 SDC1
|
||
310690157800*D BIX Byte Information Exchange
|
||
310600232901*D MFE Magnetic Fusion Energy Centre,
|
||
Lawrence Livermore
|
||
310600455141 UNINET U.N. database.
|
||
310600562200 FNAL Fermilab
|
||
31060061*DSDDC;IPSSLON ORBIT2 SDC Search Service
|
||
3106009211 ORBIT1 SDC Search Service
|
||
3106900803*D DIALOG3 Lockheed DIALOG service
|
||
3106900061*D DIALOG4 Lockheed DIALOG service
|
||
31069 SLAC SLAC via TYMNET
|
||
|
||
USA - TELENET
|
||
|
||
3110 TELENET USA - Telenet
|
||
31102020010900 CIS Chemical Information Systems
|
||
311021200141 JPLM1 Jet Propulsion Laboratory mail 1, USA
|
||
311021200142 JPLM2 Jet Propulsion Laboratory mail 2, USA
|
||
31102130003300*D ORBIT SDC Search Service
|
||
31102130017000*D DIALOG2 Lockheed DIALOG service
|
||
311021300219 CALTECH Caltech VAX 11/780
|
||
31103010002000 NLM National Medical Library
|
||
31103010025442 DIALCOM42 DIALCOM - system 42
|
||
311030100341 UNINET1 U.N. database.
|
||
31103010047 SOURCE Source system in USA
|
||
311030200612 OCEANIC Database on oceans of the world.
|
||
31103150002002*d BRS Biblographic Research Services, NY
|
||
31103210010400 NASAMAIL NASA telemail system.
|
||
31103210016000 SPANSSL Space Science Lab, NASA Marshal Space
|
||
Flight Control and SPAN
|
||
311032107035 NSSDCA National Space Science Data Centre,
|
||
node NSSDCA on the SPAN Network.
|
||
31104150004800*D DIALOG1 Lockheed DIALOG service
|
||
31106070002000 CORNELL0 Cornell University
|
||
31106070002100 CORNELL1 Cornell University
|
||
31106070002200 CORNELL2 Cornell University
|
||
31106070002200 CORNELL Cornell University
|
||
31106070002300 CORNELL3 Cornell University
|
||
31106140002124 CASUSA STN International
|
||
311070300463 NOAANETB NOAAnet system B, Washington DC.
|
||
31108080004010 UKTH UK Telescope in Hawaii
|
||
31108080004010 JACH UK Telescope in Hawaii
|
||
31108080004020 UKIRT UK Infra Red Telescope in Hawaii
|
||
31108080004030 JCMT James Clerk Maxwell Telescope
|
||
in Hawaii
|
||
311090900003 TELEMAIL1 Telemail on Telenet
|
||
311090900406 TELEMAIL2 Telemail on Telenet
|
||
311090900761 TELEMAIL3 Telemail on Telenet
|
||
31109090080000 JPLM3 Jet Propulsion Laboratory mail 2, USA
|
||
|
||
USA - RCA
|
||
|
||
3113 RCA USA - RCA
|
||
|
||
USA
|
||
|
||
312530300007 NCAR National Centre for Atmospheric
|
||
Research, Boulder
|
||
312541500007 DIALOGUNI
|
||
3126 AUTONET USA - Autonet
|
||
31343155859900 CORNELLF Cornell F m/c on ACCUNET
|
||
|
||
340 FA French Antilles
|
||
342 BDS Barbados
|
||
425 IL Israel
|
||
426 BRN Bahrain
|
||
431 DXB United Arab Emirates - Dubai
|
||
|
||
Japan
|
||
|
||
440 J Japan
|
||
4408 VENUSP Japanese data network
|
||
440820015 JOIST Japan Online Information System
|
||
454 HK Hong Kong
|
||
|
||
Australia
|
||
|
||
505 AUS Australia
|
||
505202230003.SPCP UTAS UTAS
|
||
505233430001 DITMELB CSIRO
|
||
50523343000301 MELBOURNE University of Melbourne - VAX X
|
||
505272223015 QUT Queensland University of Technology
|
||
505273720000 UQXA University of Queensland
|
||
ANF-10 gateway
|
||
5052737200001 UQKL10 University of Queensland
|
||
50527372000090 WOMBAT University of Queensland
|
||
50527372000094 UQVAX University of Queensland
|
||
505282720012 FLINDERS EDU.FLINDERS
|
||
50528622004 SAIT EDU.SAIT
|
||
505294320006 MURDOCH Murdoch University
|
||
505320000000 MINERVA MINERVA Mail service
|
||
525 SGP Singapore
|
||
|
||
New Zealand
|
||
|
||
530 NZ New Zealand
|
||
530130000034 CANTERBURY Canterbury University
|
||
530130000047 LINCOLN Lincoln University
|
||
530147000049 VUWCOMP VUW.COMP
|
||
530163000005 MASSEY Massey University Computer Centre
|
||
530171000004 WAIKATO Waikato University
|
||
530197000073 AUCKLAND Auckland University
|
||
|
||
South Africa
|
||
|
||
655 ZA South Africa
|
||
6550 SAPONET_P Saponet
|
||
655010601702 SACSIR CSIR, Pretoria
|
||
6559 SAPONET Saponet_P
|
||
|
||
|
||
=============================================================================
|
||
|
||
|
||
/ /
|
||
/ FILE 04 / NIA071 /
|
||
/ DOD-TCSEC Manual Part 02 of 02 /
|
||
/ Judge Dredd /
|
||
/ /
|
||
|
||
|
||
CSC-STD-001-83
|
||
Library No. S225,711
|
||
|
||
|
||
|
||
|
||
|
||
DEPARTMENT OF DEFENSE
|
||
|
||
TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
15 August 1983
|
||
|
||
|
||
|
||
|
||
|
||
CSC-STD-001-83
|
||
7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA
|
||
|
||
Section 1 presents fundamental computer security requirements and Section 5
|
||
presents the control objectives for Trusted Computer Systems. They are
|
||
general requirements, useful and necessary, for the development of all secure
|
||
systems. However, when designing systems that will be used to process
|
||
classified or other sensitive information, functional requirements for meeting
|
||
the Control Objectives become more specific. There is a large body of policy
|
||
laid down in the form of Regulations, Directives, Presidential Executive
|
||
Orders, and OMB Circulars that form the basis of the procedures for the
|
||
handling and processing of Federal information in general and classified
|
||
information specifically. This section presents pertinent excerpts from these
|
||
policy statements and discusses their relationship to the Control Objectives.
|
||
|
||
|
||
7.1 Established Federal Policies
|
||
|
||
A significant number of computer security policies and associated requirements
|
||
have been promulgated by Federal government elements. The interested reader
|
||
is referred to reference [32] which analyzes the need for trusted systems in
|
||
the civilian agencies of the Federal government, as well as in state and local
|
||
governments and in the private sector. This reference also details a number
|
||
of relevant Federal statutes, policies and requirements not treated further
|
||
below.
|
||
|
||
Security guidance for Federal automated information systems is provided by the
|
||
Office of Management and Budget. Two specifically applicable Circulars have
|
||
been issued. OMB Circular No. A-71, Transmittal Memorandum No. 1, "Security
|
||
of Federal Automated Information Systems,"[26] directs each executive agency
|
||
to establish and maintain a computer security program. It makes the head of
|
||
each executive branch, department and agency responsible "for assuring an
|
||
adequate level of security for all agency data whether processed in-house or
|
||
commercially. This includes responsibility for the establishment of physical,
|
||
administrative and technical safeguards required to adequately protect
|
||
personal, proprietary or other sensitive data not subject to national security
|
||
regulations, as well as national security data."[26, para. 4 p. 2]
|
||
|
||
OMB Circular No. A-123, "Internal Control Systems,"[27] issued to help
|
||
eliminate fraud, waste, and abuse in government programs requires: (a) agency
|
||
heads to issue internal control directives and assign responsibility, (b)
|
||
managers to review programs for vulnerability, and (c) managers to perform
|
||
periodic reviews to evaluate strengths and update controls. Soon after
|
||
promulgation of OMB Circular A-123, the relationship of its internal control
|
||
requirements to building secure computer systems was recognized.[4] While not
|
||
stipulating computer controls specifically, the definition of Internal
|
||
Controls in A-123 makes it clear that computer systems are to be included:
|
||
|
||
"Internal Controls - The plan of organization and all of the methods and
|
||
measures adopted within an agency to safeguard its resources, assure the
|
||
accuracy and reliability of its information, assure adherence to
|
||
applicable laws, regulations and policies, and promote operational
|
||
economy and efficiency."[27, sec. 4.C]
|
||
|
||
The matter of classified national security information processed by ADP
|
||
systems was one of the first areas given serious and extensive concern in
|
||
computer security. The computer security policy documents promulgated as a
|
||
result contain generally more specific and structured requirements than most,
|
||
keyed in turn to an authoritative basis that itself provides a rather clearly
|
||
articulated and structured information security policy. This basis, Executive
|
||
Order 12356, "National Security Information," sets forth requirements for the
|
||
classification, declassification and safeguarding of "national security
|
||
information" per se.[14]
|
||
|
||
7.2 DoD Policies
|
||
|
||
Within the Department of Defense, these broad requirements are implemented and
|
||
further specified primarily through two vehicles: 1) DoD Regulation 5200.1-R
|
||
[7], which applies to all components of the DoD as such, and 2) DoD 5220.22-M,
|
||
"Industrial Security Manual for Safeguarding Classified Information" [11],
|
||
which applies to contractors included within the Defense Industrial Security
|
||
Program. Note that the latter transcends DoD as such, since it applies not
|
||
only to any contractors handling classified information for any DoD component,
|
||
but also to the contractors of eighteen other Federal organizations for whom
|
||
the Secretary of Defense is authorized to act in rendering industrial security
|
||
services.*
|
||
|
||
____________________________________________________________
|
||
* i.e., NASA, Commerce Department, GSA, State Department,
|
||
Small Business Administration, National Science Foundation,
|
||
Treasury Department, Transportation Department, Interior
|
||
Department, Agriculture Department, Health and Human
|
||
Services Department, Labor Department, Environmental
|
||
Protection Agency, Justice Department, U.S. Arms Control and
|
||
Disarmament Agency, Federal Emergency Management Agency,
|
||
Federal Reserve System, and U.S. General Accounting Office.
|
||
____________________________________________________________
|
||
|
||
|
||
For ADP systems, these information security requirements are further amplified
|
||
and specified in: 1) DoD Directive 5200.28 [8] and DoD Manual 5200.28-M [9],
|
||
for DoD components; and 2) Section XIII of DoD 5220.22-M [11] for contractors.
|
||
DoD Directive 5200.28, "Security Requirements for Automatic Data Processing
|
||
(ADP) Systems," stipulates: "Classified material contained in an ADP system
|
||
shall be safeguarded by the continuous employment of protective features in
|
||
the system's hardware and software design and configuration . . . ."[8,
|
||
sec. IV] Furthermore, it is required that ADP systems that "process, store,
|
||
or use classified data and produce classified information will, with
|
||
reasonable dependability, prevent:
|
||
|
||
a. Deliberate or inadvertent access to classified material by
|
||
unauthorized persons, and
|
||
|
||
b. Unauthorized manipulation of the computer and its associated
|
||
peripheral devices."[8, sec. I B.3]
|
||
|
||
Requirements equivalent to these appear within DoD 5200.28-M [9] and in DoD
|
||
5220.22-M [11].
|
||
|
||
>From requirements imposed by these regulations, directives and circulars, the
|
||
three components of the Security Policy Control Objective, i.e., Mandatory and
|
||
Discretionary Security and Marking, as well as the Accountability and
|
||
Assurance Control Objectives, can be functionally defined for DoD
|
||
applications. The following discussion provides further specificity in Policy
|
||
for these Control Objectives.
|
||
|
||
7.3 Criteria Control Objective for Security Policy
|
||
|
||
7.3.1 Marking
|
||
|
||
The control objective for marking is: "Systems that are designed
|
||
to enforce a mandatory security policy must store and preserve the
|
||
integrity of classification or other sensitivity labels for all
|
||
information. Labels exported from the system must be accurate
|
||
representations of the corresonding internal sensitivity labels
|
||
being exported."
|
||
|
||
DoD 5220.22-M, "Industrial Security Manual for Safeguarding
|
||
Classified Information," explains in paragraph 11 the reasons for
|
||
marking information:
|
||
|
||
"Designation by physical marking, notation or other means
|
||
serves to inform and to warn the holder about the
|
||
classification designation of the information which requires
|
||
protection in the interest of national security. The degree
|
||
of protection against unauthorized disclosure which will be
|
||
required for a particular level of classification is directly
|
||
commensurate with the marking designation which is assigned
|
||
to the material."[11]
|
||
|
||
Marking requirements are given in a number of policy statements.
|
||
|
||
Executive Order 12356 (Sections 1.5.a and 1.5.a.1) requires that
|
||
classification markings "shall be shown on the face of all
|
||
classified documents, or clearly associated with other forms of
|
||
classified information in a manner appropriate to the medium
|
||
involved."[14]
|
||
|
||
DoD Regulation 5200.1-R (Section 1-500) requires that: ". . .
|
||
information or material that requires protection against
|
||
unauthorized disclosure in the interest of national security shall
|
||
be classified in one of three designations, namely: 'Top Secret,'
|
||
'Secret' or 'Confidential.'"[7] (By extension, for use in computer
|
||
processing, the unofficial designation "Unclassified" is used to
|
||
indicate information that does not fall under one of the other
|
||
three designations of classified information.)
|
||
|
||
DoD Regulation 5200.1-R (Section 4-304b) requires that: "ADP
|
||
systems and word processing systems employing such media shall
|
||
provide for internal classification marking to assure that
|
||
classified information contained therein that is reproduced or
|
||
generated, will bear applicable classification and associated
|
||
markings." (This regulation provides for the exemption of certain
|
||
existing systems where "internal classification and applicable
|
||
associated markings cannot be implemented without extensive system
|
||
modifications."[7] However, it is clear that future DoD ADP
|
||
systems must be able to provide applicable and accurate labels for
|
||
classified and other sensitive information.)
|
||
|
||
DoD Manual 5200.28-M (Section IV, 4-305d) requires the following:
|
||
"Security Labels - All classified material accessible by or within
|
||
the ADP system shall be identified as to its security
|
||
classification and access or dissemination limitations, and all
|
||
output of the ADP system shall be appropriately marked."[9]
|
||
|
||
7.3.2 Mandatory Security
|
||
|
||
The control objective for mandatory security is: "Security
|
||
policies defined for systems that are used to process classified
|
||
or other specifically categorized sensitive information must
|
||
include provisions for the enforcement of mandatory access control
|
||
rules. That is, they must include a set of rules for controlling
|
||
access based directly on a comparison of the individual's
|
||
clearance or authorization for the information and the
|
||
classification or sensitivity designation of the information being
|
||
sought, and indirectly on considerations of physical and other
|
||
environmental factors of control. The mandatory access control
|
||
rules must accurately reflect the laws, regulations, and general
|
||
policies from which they are derived."
|
||
|
||
There are a number of policy statements that are related to
|
||
mandatory security.
|
||
|
||
Executive Order 12356 (Section 4.1.a) states that "a person is
|
||
eligible for access to classified information provided that a
|
||
determination of trustworthiness has been made by agency heads or
|
||
designated officials and provided that such access is essential
|
||
to the accomplishment of lawful and authorized Government
|
||
purposes."[14]
|
||
|
||
DoD Regulation 5200.1-R (Chapter I, Section 3) defines a Special
|
||
Access Program as "any program imposing 'need-to-know' or access
|
||
controls beyond those normally provided for access to
|
||
Confidential, Secret, or Top Secret information. Such a program
|
||
includes, but is not limited to, special clearance, adjudication,
|
||
or investigative requirements, special designation of officials
|
||
authorized to determine 'need-to-know', or special lists of persons
|
||
determined to have a 'need-to- know.'"[7, para. 1-328] This
|
||
passage distinguishes between a 'discretionary' determination of
|
||
need-to-know and formal need-to-know which is implemented through
|
||
Special Access Programs. DoD Regulation 5200.1-R, paragraph 7-100
|
||
describes general requirements for trustworthiness (clearance) and
|
||
need-to-know, and states that the individual with possession,
|
||
knowledge or control of classified information has final
|
||
responsibility for determining if conditions for access have been
|
||
met. This regulation further stipulates that "no one has a right
|
||
to have access to classified information solely by virtue of rank
|
||
or position." [7, para. 7-100])
|
||
|
||
DoD Manual 5200.28-M (Section II 2-100) states that, "Personnel
|
||
who develop, test (debug), maintain, or use programs which are
|
||
classified or which will be used to access or develop classified
|
||
material shall have a personnel security clearance and an access
|
||
authorization (need-to-know), as appropriate for the highest
|
||
classified and most restrictive category of classified material
|
||
which they will access under system constraints."[9]
|
||
|
||
DoD Manual 5220.22-M (Paragraph 3.a) defines access as "the
|
||
ability and opportunity to obtain knowledge of classified
|
||
information. An individual, in fact, may have access to
|
||
classified information by being in a place where such information
|
||
is kept, if the security measures which are in force do not
|
||
prevent him from gaining knowledge of the classified
|
||
information."[11]
|
||
|
||
The above mentioned Executive Order, Manual, Directives and
|
||
Regulations clearly imply that a trusted computer system must
|
||
assure that the classification labels associated with sensitive
|
||
data cannot be arbitrarily changed, since this could permit
|
||
individuals who lack the appropriate clearance to access
|
||
classified information. Also implied is the requirement that a
|
||
trusted computer system must control the flow of information so
|
||
that data from a higher classification cannot be placed in a
|
||
storage object of lower classification unless its "downgrading"
|
||
has been authorized.
|
||
|
||
7.3.3 Discretionary Security
|
||
|
||
The term discretionary security refers to a computer system's
|
||
ability to control information on an individual basis. It stems
|
||
from the fact that even though an individual has all the formal
|
||
clearances for access to specific classified information, each
|
||
individual's access to information must be based on a demonstrated
|
||
need-to-know. Because of this, it must be made clear that this
|
||
requirement is not discretionary in a "take it or leave it" sense.
|
||
The directives and regulations are explicit in stating that the
|
||
need-to-know test must be satisfied before access can be granted
|
||
to the classified information. The control objective for
|
||
discretionary security is: "Security policies defined for systems
|
||
that are used to process classified or other sensitive information
|
||
must include provisions for the enforcement of discretionary
|
||
access control rules. That is, they must include a consistent set
|
||
of rules for controlling and limiting access based on identified
|
||
individuals who have been determined to have a need-to-know for the
|
||
information."
|
||
|
||
DoD Regulation 5200.1-R (Paragraph 7-100) In addition to excerpts
|
||
already provided that touch on need-to- know, this section of the
|
||
regulation stresses the need- to-know principle when it states "no
|
||
person may have access to classified information unless . . .
|
||
access is necessary for the performance of official duties."[7]
|
||
|
||
Also, DoD Manual 5220.22-M (Section III 20.a) states that "an
|
||
individual shall be permitted to have access to classified
|
||
information only . . . when the contractor determines that access
|
||
is necessary in the performance of tasks or services essential to
|
||
the fulfillment of a contract or program, i.e., the individual has
|
||
a need-to-know."[11]
|
||
|
||
7.4 Criteria Control Objective for Accountability
|
||
|
||
The control objective for accountability is: "Systems that are used to
|
||
process or handle classified or other sensitive information must assure
|
||
individual accountability whenever either a mandatory or discretionary
|
||
security policy is invoked. Furthermore, to assure accountability the
|
||
capability must exist for an authorized and competent agent to access and
|
||
evaluate accountability information by a secure means, within a reasonable
|
||
amount of time, and without undue difficulty."
|
||
|
||
This control objective is supported by the following citations:
|
||
|
||
DoD Directive 5200.28 (VI.A.1) states: "Each user's identity shall be
|
||
positively established, and his access to the system, and his activity in
|
||
the system (including material accessed and actions taken) controlled and
|
||
open to scrutiny."[8]
|
||
|
||
DoD Manual 5200.28-M (Section V 5-100) states: "An audit log or file
|
||
(manual, machine, or a combination of both) shall be maintained as a
|
||
history of the use of the ADP System to permit a regular security review
|
||
of system activity. (e.g., The log should record security related
|
||
transactions, including each access to a classified file and the nature
|
||
of the access, e.g., logins, production of accountable classified
|
||
outputs, and creation of new classified files. Each classified file
|
||
successfully accessed [regardless of the number of individual references]
|
||
during each 'job' or 'interactive session' should also be recorded in the
|
||
audit log. Much of the material in this log may also be required to
|
||
assure that the system preserves information entrusted to it.)"[9]
|
||
|
||
DoD Manual 5200.28-M (Section IV 4-305f) states: "Where needed to assure
|
||
control of access and individual accountability, each user or specific
|
||
group of users shall be identified to the ADP System by appropriate
|
||
administrative or hardware/software measures. Such identification
|
||
measures must be in sufficient detail to enable the ADP System to provide
|
||
the user only that material which he is authorized."[9]
|
||
|
||
DoD Manual 5200.28-M (Section I 1-102b) states:
|
||
|
||
"Component's Designated Approving Authorities, or their designees
|
||
for this purpose . . . will assure:
|
||
|
||
. . . . . . . . . . . . . . . . .
|
||
|
||
(4) Maintenance of documentation on operating systems (O/S)
|
||
and all modifications thereto, and its retention for a
|
||
sufficient period of time to enable tracing of security-
|
||
related defects to their point of origin or inclusion in the
|
||
system.
|
||
|
||
. . . . . . . . . . . . . . . . .
|
||
|
||
(6) Establishment of procedures to discover, recover,
|
||
handle, and dispose of classified material improperly
|
||
disclosed through system malfunction or personnel action.
|
||
|
||
(7) Proper disposition and correction of security
|
||
deficiencies in all approved ADP Systems, and the effective
|
||
use and disposition of system housekeeping or audit records,
|
||
records of security violations or security-related system
|
||
malfunctions, and records of tests of the security features
|
||
of an ADP System."[9]
|
||
|
||
DoD Manual 5220.22-M (Section XIII 111) states: "Audit Trails
|
||
|
||
a. The general security requirement for any ADP system audit
|
||
trail is that it provide a documented history of the use of
|
||
the system. An approved audit trail will permit review of
|
||
classified system activity and will provide a detailed
|
||
activity record to facilitate reconstruction of events to
|
||
determine the magnitude of compromise (if any) should a
|
||
security malfunction occur. To fulfill this basic
|
||
requirement, audit trail systems, manual, automated or a
|
||
combination of both must document significant events
|
||
occurring in the following areas of concern: (i) preparation
|
||
of input data and dissemination of output data (i.e.,
|
||
reportable interactivity between users and system support
|
||
personnel), (ii) activity involved within an ADP environment
|
||
(e.g., ADP support personnel modification of security and
|
||
related controls), and (iii) internal machine activity.
|
||
|
||
b. The audit trail for an ADP system approved to process
|
||
classified information must be based on the above three
|
||
areas and may be stylized to the particular system. All
|
||
systems approved for classified processing should contain
|
||
most if not all of the audit trail records listed below. The
|
||
contractor's SPP documentation must identify and describe
|
||
those applicable:
|
||
|
||
1. Personnel access;
|
||
|
||
2. Unauthorized and surreptitious entry into the
|
||
central computer facility or remote terminal areas;
|
||
|
||
3. Start/stop time of classified processing indicating
|
||
pertinent systems security initiation and termination events
|
||
(e.g., upgrading/downgrading actions pursuant to paragraph
|
||
107);
|
||
|
||
4. All functions initiated by ADP system console
|
||
operators;
|
||
|
||
5. Disconnects of remote terminals and peripheral
|
||
devices (paragraph 107c);
|
||
|
||
6. Log-on and log-off user activity;
|
||
|
||
7. Unauthorized attempts to access files or programs,
|
||
as well as all open, close, create, and file destroy
|
||
actions;
|
||
|
||
8. Program aborts and anomalies including
|
||
identification information (i.e., user/program name, time
|
||
and location of incident, etc.);
|
||
|
||
9. System hardware additions, deletions and maintenance
|
||
actions;
|
||
|
||
10. Generations and modifications affecting the
|
||
security features of the system software.
|
||
|
||
c. The ADP system security supervisor or designee shall
|
||
review the audit trail logs at least weekly to assure that
|
||
all pertinent activity is properly recorded and that
|
||
appropriate action has been taken to correct any anomaly.
|
||
The majority of ADP systems in use today can develop audit
|
||
trail systems in accord with the above; however, special
|
||
systems such as weapons, communications, communications
|
||
security, and tactical data exchange and display systems,
|
||
may not be able to comply with all aspects of the above and
|
||
may require individualized consideration by the cognizant
|
||
security office.
|
||
|
||
d. Audit trail records shall be retained for a period of one
|
||
inspection cycle."[11]
|
||
|
||
7.5 Criteria Control Objective for Assurance
|
||
|
||
The control objective for assurance is: "Systems that are used to process
|
||
or handle classified or other sensitive information must be designed to
|
||
guarantee correct and accurate interpretation of the security policy and
|
||
must not distort the intent of that policy. Assurance must be provided
|
||
that correct implementation and operation of the policy exists throughout
|
||
the system's life-cycle."
|
||
|
||
A basis for this objective can be found in the following sections of DoD
|
||
Directive 5200.28:
|
||
|
||
DoD Directive 5200.28 (IV.B.1) stipulates: "Generally, security of an ADP
|
||
system is most effective and economical if the system is designed
|
||
originally to provide it. Each Department of Defense Component
|
||
undertaking design of an ADP system which is expected to process, store,
|
||
use, or produce classified material shall: From the beginning of the
|
||
design process, consider the security policies, concepts, and measures
|
||
prescribed in this Directive."[8]
|
||
|
||
DoD Directive 5200.28 (IV.C.5.a) states: "Provision may be made to permit
|
||
adjustment of ADP system area controls to the level of protection
|
||
required for the classification category and type(s) of material actually
|
||
being handled by the system, provided change procedures are developed and
|
||
implemented which will prevent both the unauthorized access to classified
|
||
material handled by the system and the unauthorized manipulation of the
|
||
system and its components. Particular attention shall be given to the
|
||
continuous protection of automated system security measures, techniques
|
||
and procedures when the personnel security clearance level of users
|
||
having access to the system changes."[8]
|
||
|
||
DoD Directive 5200.28 (VI.A.2) states: "Environmental Control. The ADP
|
||
System shall be externally protected to minimize the likelihood of
|
||
unauthorized access to system entry points, access to classified
|
||
information in the system, or damage to the system."[8]
|
||
|
||
DoD Manual 5200.28-M (Section I 1-102b) states:
|
||
|
||
"Component's Designated Approving Authorities, or their designees
|
||
for this purpose . . . will assure:
|
||
|
||
. . . . . . . . . . . . . . . . .
|
||
|
||
(5) Supervision, monitoring, and testing, as appropriate, of
|
||
changes in an approved ADP System which could affect the
|
||
security features of the system, so that a secure system is
|
||
maintained.
|
||
|
||
. . . . . . . . . . . . . . . . .
|
||
|
||
(7) Proper disposition and correction of security
|
||
deficiencies in all approved ADP Systems, and the effective
|
||
use and disposition of system housekeeping or audit records,
|
||
records of security violations or security-related system
|
||
malfunctions, and records of tests of the security features
|
||
of an ADP System.
|
||
|
||
(8) Conduct of competent system ST&E, timely review of
|
||
system ST&E reports, and correction of deficiencies needed
|
||
to support conditional or final approval or disapproval of
|
||
an ADP System for the processing of classified information.
|
||
|
||
(9) Establishment, where appropriate, of a central ST&E
|
||
coordination point for the maintenance of records of
|
||
selected techniques, procedures, standards, and tests used
|
||
in the testing and evaluation of security features of ADP
|
||
Systems which may be suitable for validation and use by
|
||
other Department of Defense Components."[9]
|
||
|
||
DoD Manual 5220.22-M (Section XIII 103a) requires: "the initial approval,
|
||
in writing, of the cognizant security office prior to processing any
|
||
classified information in an ADP system. This section requires
|
||
reapproval by the cognizant security office for major system
|
||
modifications made subsequent to initial approval. Reapprovals will be
|
||
required because of (i) major changes in personnel access requirements,
|
||
(ii) relocation or structural modification of the central computer
|
||
facility, (iii) additions, deletions or changes to main frame, storage or
|
||
input/output devices, (iv) system software changes impacting security
|
||
protection features, (v) any change in clearance, declassification, audit
|
||
trail or hardware/software maintenance procedures, and (vi) other system
|
||
changes as determined by the cognizant security office."[11]
|
||
|
||
A major component of assurance, life-cycle assurance, is concerned with
|
||
testing ADP systems both in the development phase as well as during
|
||
operation. DoD Directive 5215.1 (Section F.2.C.(2)) requires
|
||
"evaluations of selected industry and government-developed trusted
|
||
computer systems against these criteria."[10]
|
||
|
||
|
||
|
||
8.0 A GUIDELINE ON COVERT CHANNELS
|
||
|
||
A covert channel is any communication channel that can be exploited by a
|
||
process to transfer information in a manner that violates the system's
|
||
security policy. There are two types of covert channels: storage channels and
|
||
timing channels. Covert storage channels include all vehicles that would
|
||
allow the direct or indirect writing of a storage location by one process and
|
||
the direct or indirect reading of it by another. Covert timing channels
|
||
include all vehicles that would allow one process to signal information to
|
||
another process by modulating its own use of system resources in such a way
|
||
that the change in response time observed by the second process would provide
|
||
information.
|
||
|
||
>From a security perspective, covert channels with low bandwidths represent a
|
||
lower threat than those with high bandwidths. However, for many types of
|
||
covert channels, techniques used to reduce the bandwidth below a certain rate
|
||
(which depends on the specific channel mechanism and the system architecture)
|
||
also have the effect of degrading the performance provided to legitimate
|
||
system users. Hence, a trade-off between system performance and covert
|
||
channel bandwidth must be made. Because of the threat of compromise that
|
||
would be present in any multilevel computer system containing classified or
|
||
sensitive information, such systems should not contain covert channels with
|
||
high bandwidths. This guideline is intended to provide system developers with
|
||
an idea of just how high a "high" covert channel bandwidth is.
|
||
|
||
A covert channel bandwidth that exceeds a rate of one hundred (100) bits per
|
||
second is considered "high" because 100 bits per second is the approximate
|
||
rate at which many computer terminals are run. It does not seem appropriate
|
||
to call a computer system "secure" if information can be compromised at a rate
|
||
equal to the normal output rate of some commonly used device.
|
||
|
||
In any multilevel computer system there are a number of relatively
|
||
low-bandwidth covert channels whose existence is deeply ingrained in the
|
||
system design. Faced with the large potential cost of reducing the bandwidths
|
||
of such covert channels, it is felt that those with maximum bandwidths of less
|
||
than one (1) bit per second are acceptable in most application environments.
|
||
Though maintaining acceptable performance in some systems may make it
|
||
impractical to eliminate all covert channels with bandwidths of 1 or more bits
|
||
per second, it is possible to audit their use without adversely affecting
|
||
system performance. This audit capability provides the system administration
|
||
with a means of detecting -- and procedurally correcting -- significant
|
||
compromise. Therefore, a Trusted Computing Base should provide, wherever
|
||
possible, the capability to audit the use of covert channel mechanisms with
|
||
bandwidths that may exceed a rate of one (1) bit in ten (10) seconds.
|
||
|
||
The covert channel problem has been addressed by a number of authors. The
|
||
interested reader is referred to references [5], [6], [19], [21], [22], [23],
|
||
and [29].
|
||
|
||
|
||
|
||
9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES
|
||
|
||
The Mandatory Access Control requirement includes a capability to support an
|
||
unspecified number of hierarchical classifications and an unspecified number
|
||
of non-hierarchical categories at each hierarchical level. To encourage
|
||
consistency and portability in the design and development of the National
|
||
Security Establishment trusted computer systems, it is desirable for all such
|
||
systems to be able to support a minimum number of levels and categories. The
|
||
following suggestions are provided for this purpose:
|
||
|
||
* The number of hierarchical classifications should be greater than or
|
||
equal to eight (8).
|
||
|
||
* The number of non-hierarchical categories should be greater than or
|
||
equal to twenty-nine (29).
|
||
|
||
|
||
|
||
10.0 A GUIDELINE ON SECURITY TESTING
|
||
|
||
These guidelines are provided to give an indication of the extent and
|
||
sophistication of testing undertaken by the DoD Computer Security Center
|
||
during the Formal Product Evaluation process. Organizations wishing to use
|
||
"Department of Defense Trusted Computer System Evaluation Criteria" for
|
||
performing their own evaluations may find this section useful for planning
|
||
purposes.
|
||
|
||
As in Part I, highlighting is used to indicate changes in the guidelines from
|
||
the next lower division.
|
||
|
||
10.1 Testing for Division C
|
||
|
||
10.1.1 Personnel
|
||
|
||
The security testing team shall consist of at least two
|
||
individuals with bachelor degrees in Computer Science or the
|
||
equivalent. Team members shall be able to follow test plans
|
||
prepared by the system developer and suggest additions, shall
|
||
be familiar with the "flaw hypothesis" or equivalent security
|
||
testing methodology, and shall have assembly level programming
|
||
experience. Before testing begins, the team members shall have
|
||
functional knowledge of, and shall have completed the system
|
||
developer's internals course for, the system being evaluated.
|
||
|
||
10.1.2 Testing
|
||
|
||
The team shall have "hands-on" involvement in an independent run
|
||
of the tests used by the system developer. The team shall
|
||
independently design and implement at least five system-specific
|
||
tests in an attempt to circumvent the security mechanisms of the
|
||
system. The elapsed time devoted to testing shall be at least
|
||
one month and need not exceed three months. There shall be no
|
||
fewer than twenty hands-on hours spent carrying out system
|
||
developer-defined tests and test team-defined tests.
|
||
|
||
10.2 Testing for Division B
|
||
|
||
10.2.1 Personnel
|
||
|
||
The security testing team shall consist of at least two
|
||
individuals with bachelor degrees in Computer Science or the
|
||
equivalent and at least one individual with a master's degree in
|
||
Computer Science or equivalent. Team members shall be able to
|
||
follow test plans prepared by the system developer and suggest
|
||
additions, shall be conversant with the "flaw hypothesis" or
|
||
equivalent security testing methodology, shall be fluent in the
|
||
TCB implementation language(s), and shall have assembly level
|
||
programming experience. Before testing begins, the team members
|
||
shall have functional knowledge of, and shall have completed the
|
||
system developer's internals course for, the system being
|
||
evaluated. At least one team member shall have previously
|
||
completed a security test on another system.
|
||
|
||
10.2.2 Testing
|
||
|
||
The team shall have "hands-on" involvement in an independent run
|
||
of the test package used by the system developer to test
|
||
security-relevant hardware and software. The team shall
|
||
independently design and implement at least fifteen system-
|
||
specific tests in an attempt to circumvent the security
|
||
mechanisms of the system. The elapsed time devoted to testing
|
||
shall be at least two months and need not exceed four months.
|
||
There shall be no fewer than thirty hands-on hours per team
|
||
member spent carrying out system developer-defined tests and
|
||
test team-defined tests.
|
||
|
||
10.3 Testing for Division A
|
||
|
||
10.3.1 Personnel
|
||
|
||
The security testing team shall consist of at least one
|
||
individual with a bachelor's degree in Computer Science or the
|
||
equivalent and at least two individuals with masters' degrees in
|
||
Computer Science or equivalent. Team members shall be able to
|
||
follow test plans prepared by the system developer and suggest
|
||
additions, shall be conversant with the "flaw hypothesis" or
|
||
equivalent security testing methodology, shall be fluent in the
|
||
TCB implementation language(s), and shall have assembly level
|
||
programming experience. Before testing begins, the team members
|
||
shall have functional knowledge of, and shall have completed the
|
||
system developer's internals course for, the system being
|
||
evaluated. At least one team member shall be familiar enough
|
||
with the system hardware to understand the maintenance diagnostic
|
||
programs and supporting hardware documentation. At least two
|
||
team members shall have previously completed a security test on
|
||
another system. At least one team member shall have
|
||
demonstrated system level programming competence on the system
|
||
under test to a level of complexity equivalent to adding a device
|
||
driver to the system.
|
||
|
||
10.3.2 Testing
|
||
|
||
The team shall have "hands-on" involvement in an independent run
|
||
of the test package used by the system developer to test
|
||
security-relevant hardware and software. The team shall
|
||
independently design and implement at least twenty-five system-
|
||
specific tests in an attempt to circumvent the security
|
||
mechanisms of the system. The elapsed time devoted to testing
|
||
shall be at least three months and need not exceed six months.
|
||
There shall be no fewer than fifty hands-on hours per team
|
||
member spent carrying out system developer-defined tests and
|
||
test team-defined tests.
|
||
|
||
|
||
|
||
|
||
APPENDIX A
|
||
|
||
Commercial Product Evaluation Process
|
||
|
||
|
||
"Department of Defense Trusted Computer System Evaluation Criteria" forms the
|
||
basis upon which the Computer Security Center will carry out the commercial
|
||
computer security evaluation process. This process is focused on commercially
|
||
produced and supported general-purpose operating system products that meet the
|
||
needs of government departments and agencies. The formal evaluation is aimed
|
||
at "off-the-shelf" commercially supported products and is completely divorced
|
||
>from any consideration of overall system performance, potential applications,
|
||
or particular processing environments. The evaluation provides a key input to
|
||
a computer system security approval/accreditation. However, it does not
|
||
constitute a complete computer system security evaluation. A complete study
|
||
(e.g., as in reference [18]) must consider additional factors dealing with the
|
||
system in its unique environment, such as it's proposed security mode of
|
||
operation, specific users, applications, data sensitivity, physical and
|
||
personnel security, administrative and procedural security, TEMPEST, and
|
||
communications security.
|
||
|
||
The product evaluation process carried out by the Computer Security Center has
|
||
three distinct elements:
|
||
|
||
* Preliminary Product Evaluation - An informal dialogue between a vendor
|
||
and the Center in which technical information is exchanged to create a
|
||
common understanding of the vendor's product, the criteria, and the
|
||
rating that may be expected to result from a formal product evaluation.
|
||
|
||
* Formal Product Evaluation - A formal evaluation, by the Center, of a
|
||
product that is available to the DoD, and that results in that product
|
||
and its assigned rating being placed on the Evaluated Products List.
|
||
|
||
* Evaluated Products List - A list of products that have been subjected
|
||
to formal product evaluation and their assigned ratings.
|
||
|
||
|
||
PRELIMINARY PRODUCT EVALUATION
|
||
|
||
Since it is generally very difficult to add effective security measures late
|
||
in a product's life cycle, the Center is interested in working with system
|
||
vendors in the early stages of product design. A preliminary product
|
||
evaluation allows the Center to consult with computer vendors on computer
|
||
security issues found in products that have not yet been formally announced.
|
||
|
||
A preliminary evaluation is typically initiated by computer system vendors who
|
||
are planning new computer products that feature security or major
|
||
security-related upgrades to existing products. After an initial meeting
|
||
between the vendor and the Center, appropriate non-disclosure agreements are
|
||
executed that require the Center to maintain the confidentiality of any
|
||
proprietary information disclosed to it. Technical exchange meetings follow
|
||
in which the vendor provides details about the proposed product (particularly
|
||
its internal designs and goals) and the Center provides expert feedback to the
|
||
vendor on potential computer security strengths and weaknesses of the vendor's
|
||
design choices, as well as relevant interpretation of the criteria. The
|
||
preliminary evaluation is typically terminated when the product is completed
|
||
and ready for field release by the vendor. Upon termination, the Center
|
||
prepares a wrap-up report for the vendor and for internal distribution within
|
||
the Center. Those reports containing proprietary information are not
|
||
available to the public.
|
||
|
||
During preliminary evaluation, the vendor is under no obligation to actually
|
||
complete or market the potential product. The Center is, likewise, not
|
||
committed to conduct a formal product evaluation. A preliminary evaluation
|
||
may be terminated by either the Center or the vendor when one notifies the
|
||
other, in writing, that it is no longer advantageous to continue the
|
||
evaluation.
|
||
|
||
|
||
FORMAL PRODUCT EVALUATION
|
||
|
||
The formal product evaluation provides a key input to certification of a
|
||
computer system for use in National Security Establishment applications and is
|
||
the sole basis for a product being placed on the Evaluated Products List.
|
||
|
||
A formal product evaluation begins with a request by a vendor for the Center
|
||
to evaluate a product for which the product itself and accompanying
|
||
documentation needed to meet the requirements defined by this publication are
|
||
complete. Non-disclosure agreements are executed and a formal product
|
||
evaluation team is formed by the Center. An initial meeting is then held with
|
||
the vendor to work out the schedule for the formal evaluation. Since testing
|
||
of the implemented product forms an important part of the evaluation process,
|
||
access by the evaluation team to a working version of the system is negotiated
|
||
with the vendor. Additional support required from the vendor includes
|
||
complete design documentation, source code, and access to vendor personnel who
|
||
can answer detailed questions about specific portions of the product. The
|
||
evaluation team tests the product against each requirement, making any
|
||
necessary interpretations of the criteria with respect to the product being
|
||
evaluated.
|
||
|
||
The evaluation team writes a two-part final report on their findings about the
|
||
system. The first part is publicly available (containing no proprietary
|
||
information) and contains the overall class rating assigned to the system and
|
||
the details of the evaluation team's findings when comparing the product
|
||
against the evaluation criteria. The second part of the evaluation report
|
||
contains vulnerability analyses and other detailed information supporting the
|
||
rating decision. Since this part may contain proprietary or other sensitive
|
||
information it will be distributed only within the U.S. Government on a
|
||
strict need-to-know and non- disclosure basis, and to the vendor. No portion
|
||
of the evaluation results will be withheld from the vendor.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
APPENDIX B
|
||
|
||
Summary of Evaluation Criteria Divisions
|
||
|
||
The divisions of systems recognized under the trusted computer system
|
||
evaluation criteria are as follows. Each division represents a major
|
||
improvement in the overall confidence one can place in the system to protect
|
||
classified and other sensitive information.
|
||
|
||
Division (D): Minimal Protection
|
||
|
||
This division contains only one class. It is reserved for those systems that
|
||
have been evaluated but that fail to meet the requirements for a higher
|
||
evaluation class.
|
||
|
||
Division (C): Discretionary Protection
|
||
|
||
Classes in this division provide for discretionary (need-to-know) protection
|
||
and, through the inclusion of audit capabilities, for accountability of
|
||
subjects and the actions they initiate.
|
||
|
||
Division (B): Mandatory Protection
|
||
|
||
The notion of a TCB that preserves the integrity of sensitivity labels and
|
||
uses them to enforce a set of mandatory access control rules is a major
|
||
requirement in this division. Systems in this division must carry the
|
||
sensitivity labels with major data structures in the system. The system
|
||
developer also provides the security policy model on which the TCB is based
|
||
and furnishes a specification of the TCB. Evidence must be provided to
|
||
demonstrate that the reference monitor concept has been implemented.
|
||
|
||
Division (A): Verified Protection
|
||
|
||
This division is characterized by the use of formal security verification
|
||
methods to assure that the mandatory and discretionary security controls
|
||
employed in the system can effectively protect classified or other sensitive
|
||
information stored or processed by the system. Extensive documentation is
|
||
required to demonstrate that the TCB meets the security requirements in all
|
||
aspects of design, development and implementation.
|
||
|
||
|
||
|
||
|
||
|
||
APPENDIX C
|
||
|
||
Summary of Evaluation Criteria Classes
|
||
|
||
The classes of systems recognized under the trusted computer system evaluation
|
||
criteria are as follows. They are presented in the order of increasing
|
||
desirablity from a computer security point of view.
|
||
|
||
Class (D): Minimal Protection
|
||
|
||
This class is reserved for those systems that have been evaluated but that
|
||
fail to meet the requirements for a higher evaluation class.
|
||
|
||
Class (C1): Discretionary Security Protection
|
||
|
||
The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies
|
||
the discretionary security requirements by providing separation of users and
|
||
data. It incorporates some form of credible controls capable of enforcing
|
||
access limitations on an individual basis, i.e., ostensibly suitable for
|
||
allowing users to be able to protect project or private information and to
|
||
keep other users from accidentally reading or destroying their data. The
|
||
class (C1) environment is expected to be one of cooperating users processing
|
||
data at the same level(s) of sensitivity.
|
||
|
||
Class (C2): Controlled Access Protection
|
||
|
||
Systems in this class enforce a more finely grained discretionary access
|
||
control than (C1) systems, making users individually accountable for their
|
||
actions through login procedures, auditing of security-relevant events, and
|
||
resource isolation.
|
||
|
||
Class (B1): Labeled Security Protection
|
||
|
||
Class (B1) systems require all the features required for class (C2). In
|
||
addition, an informal statement of the security policy model, data labeling,
|
||
and mandatory access control over named subjects and objects must be present.
|
||
The capability must exist for accurately labeling exported information. Any
|
||
flaws identified by testing must be removed.
|
||
|
||
Class (B2): Structured Protection
|
||
|
||
In class (B2) systems, the TCB is based on a clearly defined and documented
|
||
formal security policy model that requires the discretionary and mandatory
|
||
access control enforcement found in class (B1) systems be extended to all
|
||
subjects and objects in the ADP system. In addition, covert channels are
|
||
addressed. The TCB must be carefully structured into protection-critical and
|
||
non- protection-critical elements. The TCB interface is well-defined and the
|
||
TCB design and implementation enable it to be subjected to more thorough
|
||
testing and more complete review. Authentication mechanisms are strengthened,
|
||
trusted facility management is provided in the form of support for system
|
||
administrator and operator functions, and stringent configuration management
|
||
controls are imposed. The system is relatively resistant to penetration.
|
||
|
||
Class (B3): Security Domains
|
||
|
||
The class (B3) TCB must satisfy the reference monitor requirements that it
|
||
mediate all accesses of subjects to objects, be tamperproof, and be small
|
||
enough to be subjected to analysis and tests. To this end, the TCB is
|
||
structured to exclude code not essential to security policy enforcement, with
|
||
significant system engineering during TCB design and implementation directed
|
||
toward minimizing its complexity. A security administrator is supported,
|
||
audit mechanisms are expanded to signal security- relevant events, and system
|
||
recovery procedures are required. The system is highly resistant to
|
||
penetration.
|
||
|
||
Class (A1): Verified Design
|
||
|
||
Systems in class (A1) are functionally equivalent to those in class (B3) in
|
||
that no additional architectural features or policy requirements are added.
|
||
The distinguishing feature of systems in this class is the analysis derived
|
||
>from formal design specification and verification techniques and the resulting
|
||
high degree of assurance that the TCB is correctly implemented. This
|
||
assurance is developmental in nature, starting with a formal model of the
|
||
security policy and a formal top-level specification (FTLS) of the design. In
|
||
keeping with the extensive design and development analysis of the TCB required
|
||
of systems in class (A1), more stringent configuration management is required
|
||
and procedures are established for securely distributing the system to sites.
|
||
A system security administrator is supported.
|
||
|
||
|
||
|
||
|
||
|
||
APPENDIX D
|
||
|
||
Requirement Directory
|
||
|
||
This appendix lists requirements defined in "Department of Defense Trusted
|
||
Computer System Evaluation Criteria" alphabetically rather than by class. It
|
||
is provided to assist in following the evolution of a requirement through the
|
||
classes. For each requirement, three types of criteria may be present. Each
|
||
will be preceded by the word: NEW, CHANGE, or ADD to indicate the following:
|
||
|
||
NEW: Any criteria appearing in a lower class are superseded
|
||
by the criteria that follow.
|
||
|
||
CHANGE: The criteria that follow have appeared in a lower class
|
||
but are changed for this class. Highlighting is used
|
||
to indicate the specific changes to previously stated
|
||
criteria.
|
||
|
||
ADD: The criteria that follow have not been required for any
|
||
lower class, and are added in this class to the
|
||
previously stated criteria for this requirement.
|
||
|
||
Abbreviations are used as follows:
|
||
|
||
NR: (No Requirement) This requirement is not included in
|
||
this class.
|
||
|
||
NAR: (No Additional Requirements) This requirement does not
|
||
change from the previous class.
|
||
|
||
The reader is referred to Part I of this document when placing new criteria
|
||
for a requirement into the complete context for that class.
|
||
|
||
Figure 1 provides a pictorial summary of the evolution of requirements through
|
||
the classes.
|
||
|
||
|
||
Audit
|
||
|
||
C1: NR.
|
||
|
||
C2: NEW: The TCB shall be able to create, maintain, and protect from
|
||
modification or unauthorized access or destruction an audit trail of
|
||
accesses to the objects it protects. The audit data shall be
|
||
protected by the TCB so that read access to it is limited to those
|
||
who are authorized for audit data. The TCB shall be able to record
|
||
the following types of events: use of identification and
|
||
authentication mechanisms, introduction of objects into a user's
|
||
address space (e.g., file open, program initiation), deletion of
|
||
objects, and actions taken by computer operators and system
|
||
administrators and/or system security officers. For each recorded
|
||
event, the audit record shall identify: date and time of the event,
|
||
user, type of event, and success or failure of the event. For
|
||
identification/authentication events the origin of request (e.g.,
|
||
terminal ID) shall be included in the audit record. For events that
|
||
introduce an object into a user's address space and for object
|
||
deletion events the audit record shall include the name of the object.
|
||
The ADP system administrator shall be able to selectively audit the
|
||
actions of any one or more users based on individual identity.
|
||
|
||
B1: CHANGE: For events that introduce an object into a user's address
|
||
space and for object deletion events the audit record shall include
|
||
the name of the object and the object's security level. The ADP
|
||
system administrator shall be able to selectively audit the actions
|
||
of any one or more users based on individual identity and/or object
|
||
security level.
|
||
|
||
ADD: The TCB shall also be able to audit any override of
|
||
human-readable output markings.
|
||
|
||
B2: ADD: The TCB shall be able to audit the identified events that may be
|
||
used in the exploitation of covert storage channels.
|
||
|
||
B3: ADD: The TCB shall contain a mechanism that is able to monitor the
|
||
occurrence or accumulation of security auditable events that may
|
||
indicate an imminent violation of security policy. This mechanism
|
||
shall be able to immediately notify the security administrator when
|
||
thresholds are exceeded.
|
||
|
||
A1: NAR.
|
||
|
||
Configuration Management
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NR.
|
||
|
||
B2: NEW: During development and maintenance of the TCB, a configuration
|
||
management system shall be in place that maintains control of changes
|
||
to the descriptive top-level specification, other design data,
|
||
implementation documentation, source code, the running version of the
|
||
object code, and test fixtures and documentation. The configuration
|
||
management system shall assure a consistent mapping among all
|
||
documentation and code associated with the current version of the TCB.
|
||
Tools shall be provided for generation of a new version of the TCB
|
||
from source code. Also available shall be tools for comparing a
|
||
newly generated version with the previous TCB version in order to
|
||
ascertain that only the intended changes have been made in the code
|
||
that will actually be used as the new version of the TCB.
|
||
|
||
B3: NAR.
|
||
|
||
A1: CHANGE: During the entire life-cycle, i.e., during the design,
|
||
development, and maintenance of the TCB, a configuration management
|
||
system shall be in place for all security-relevant hardware, firmware,
|
||
and software that maintains control of changes to the formal model,
|
||
the descriptive and formal top-level specifications, other design
|
||
data, implementation documentation, source code, the running version
|
||
of the object code, and test fixtures and documentation. Also
|
||
available shall be tools, maintained under strict configuration
|
||
control, for comparing a newly generated version with the previous
|
||
TCB version in order to ascertain that only the intended changes have
|
||
been made in the code that will actually be used as the new version
|
||
of the TCB.
|
||
|
||
ADD: A combination of technical, physical, and procedural safeguards
|
||
shall be used to protect from unauthorized modification or
|
||
destruction the master copy or copies of all material used to
|
||
generate the TCB.
|
||
|
||
Covert Channel Analysis
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NR.
|
||
|
||
B2: NEW: The system developer shall conduct a thorough search for covert
|
||
storage channels and make a determination (either by actual
|
||
measurement or by engineering estimation) of the maximum bandwidth of
|
||
each identified channel. (See the Covert Channels Guideline section.)
|
||
|
||
B3: CHANGE: The system developer shall conduct a thorough search for
|
||
covert channels and make a determination (either by actual
|
||
measurement or by engineering estimation) of the maximum bandwidth
|
||
of each identified channel.
|
||
|
||
A1: ADD: Formal methods shall be used in the analysis.
|
||
|
||
Design Documentation
|
||
|
||
C1: NEW: Documentation shall be available that provides a description of
|
||
the manufacturer's philosophy of protection and an explanation of how
|
||
this philosophy is translated into the TCB. If the TCB is composed
|
||
of distinct modules, the interfaces between these modules shall be
|
||
described.
|
||
|
||
C2: NAR.
|
||
|
||
B1: ADD: An informal or formal description of the security policy model
|
||
enforced by the TCB shall be available and an explanation provided to
|
||
show that it is sufficient to enforce the security policy. The
|
||
specific TCB protection mechanisms shall be identified and an
|
||
explanation given to show that they satisfy the model.
|
||
|
||
B2: CHANGE: The interfaces between the TCB modules shall be described. A
|
||
formal description of the security policy model enforced by the TCB
|
||
shall be available and proven that it is sufficient to enforce the
|
||
security policy.
|
||
|
||
ADD: The descriptive top-level specification (DTLS) shall be shown to
|
||
be an accurate description of the TCB interface. Documentation shall
|
||
describe how the TCB implements the reference monitor concept and
|
||
give an explanation why it is tamperproof, cannot be bypassed, and is
|
||
correctly implemented. Documentation shall describe how the TCB is
|
||
structured to facilitate testing and to enforce least privilege.
|
||
This documentation shall also present the results of the covert
|
||
channel analysis and the tradeoffs involved in restricting the
|
||
channels. All auditable events that may be used in the exploitation
|
||
of known covert storage channels shall be identified. The bandwidths
|
||
of known covert storage channels, the use of which is not detectable
|
||
by the auditing mechanisms, shall be provided. (See the Covert
|
||
Channel Guideline section.)
|
||
|
||
B3: ADD: The TCB implementation (i.e., in hardware, firmware, and
|
||
software) shall be informally shown to be consistent with the DTLS.
|
||
The elements of the DTLS shall be shown, using informal techniques,
|
||
to correspond to the elements of the TCB.
|
||
|
||
A1: CHANGE: The TCB implementation (i.e., in hardware, firmware, and
|
||
software) shall be informally shown to be consistent with the formal
|
||
top-level specification (FTLS). The elements of the FTLS shall be
|
||
shown, using informal techniques, to correspond to the elements of
|
||
the TCB.
|
||
|
||
ADD: Hardware, firmware, and software mechanisms not dealt with in
|
||
the FTLS but strictly internal to the TCB (e.g., mapping registers,
|
||
direct memory access I/O) shall be clearly described.
|
||
|
||
Design Specification and Verification
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NEW: An informal or formal model of the security policy supported by
|
||
the TCB shall be maintained that is shown to be consistent with its
|
||
axioms.
|
||
|
||
B2: CHANGE: A formal model of the security policy supported by the TCB
|
||
shall be maintained that is proven consistent with its axioms.
|
||
|
||
ADD: A descriptive top-level specification (DTLS) of the TCB shall be
|
||
maintained that completely and accurately describes the TCB in terms
|
||
of exceptions, error messages, and effects. It shall be shown to be
|
||
an accurate description of the TCB interface.
|
||
|
||
B3: ADD: A convincing argument shall be given that the DTLS is consistent
|
||
with the model.
|
||
|
||
A1: CHANGE: The FTLS shall be shown to be an accurate description of the
|
||
TCB interface. A convincing argument shall be given that the DTLS is
|
||
consistent with the model and a combination of formal and informal
|
||
techniques shall be used to show that the FTLS is consistent with the
|
||
model.
|
||
|
||
ADD: A formal top-level specification (FTLS) of the TCB shall be
|
||
maintained that accurately describes the TCB in terms of exceptions,
|
||
error messages, and effects. The DTLS and FTLS shall include those
|
||
components of the TCB that are implemented as hardware and/or
|
||
firmware if their properties are visible at the TCB interface. This
|
||
verification evidence shall be consistent with that provided within
|
||
the state-of-the-art of the particular Computer Security Center-
|
||
endorsed formal specification and verification system used. Manual
|
||
or other mapping of the FTLS to the TCB source code shall be
|
||
performed to provide evidence of correct implementation.
|
||
|
||
Device Labels
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NR.
|
||
|
||
B2: NEW: The TCB shall support the assignment of minimum and maximum
|
||
security levels to all attached physical devices. These security
|
||
levels shall be used by the TCB to enforce constraints imposed by
|
||
the physical environments in which the devices are located.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Discretionary Access Control
|
||
|
||
C1: NEW: The TCB shall define and control access between named users and
|
||
named objects (e.g., files and programs) in the ADP system. The
|
||
enforcement mechanism (e.g., self/group/public controls, access
|
||
control lists) shall allow users to specify and control sharing of
|
||
those objects by named individuals or defined groups or both.
|
||
|
||
C2: CHANGE: The enforcement mechanism (e.g., self/group/public controls,
|
||
access control lists) shall allow users to specify and control
|
||
sharing of those objects by named individuals, or defined groups of
|
||
individuals, or by both.
|
||
|
||
ADD: The discretionary access control mechanism shall, either by explicit
|
||
user action or by default, provide that objects are protected from
|
||
unauthorized access. These access controls shall be capable of
|
||
including or excluding access to the granularity of a single user.
|
||
Access permission to an object by users not already possessing access
|
||
permission shall only be assigned by authorized users.
|
||
|
||
B1: NAR.
|
||
|
||
B2: NAR.
|
||
|
||
B3: CHANGE: The enforcement mechanism (e.g., access control lists) shall
|
||
allow users to specify and control sharing of those objects. These
|
||
access controls shall be capable of specifying, for each named
|
||
object, a list of named individuals and a list of groups of named
|
||
individuals with their respective modes of access to that object.
|
||
|
||
ADD: Furthermore, for each such named object, it shall be possible to
|
||
specify a list of named individuals and a list of groups of named
|
||
individuals for which no access to the object is to be given.
|
||
|
||
A1: NAR.
|
||
|
||
Exportation of Labeled Information
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NEW: The TCB shall designate each communication channel and I/O
|
||
device as either single-level or multilevel. Any change in this
|
||
designation shall be done manually and shall be auditable by the
|
||
TCB. The TCB shall maintain and be able to audit any change in the
|
||
current security level associated with a single-level communication
|
||
channel or I/O device.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Exportation to Multilevel Devices
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NEW: When the TCB exports an object to a multilevel I/O device, the
|
||
sensitivity label associated with that object shall also be exported
|
||
and shall reside on the same physical medium as the exported
|
||
information and shall be in the same form (i.e., machine-readable or
|
||
human-readable form). When the TCB exports or imports an object over
|
||
a multilevel communication channel, the protocol used on that channel
|
||
shall provide for the unambiguous pairing between the sensitivity
|
||
labels and the associated information that is sent or received.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Exportation to Single-Level Devices
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NEW: Single-level I/O devices and single-level communication channels
|
||
are not required to maintain the sensitivity labels of the
|
||
information they process. However, the TCB shall include a mechanism
|
||
by which the TCB and an authorized user reliably communicate to
|
||
designate the single security level of information imported or
|
||
exported via single-level communication channels or I/O devices.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Identification and Authentication
|
||
|
||
C1: NEW: The TCB shall require users to identify themselves to it before
|
||
beginning to perform any other actions that the TCB is expected to
|
||
mediate. Furthermore, the TCB shall use a protected mechanism (e.g.,
|
||
passwords) to authenticate the user's identity. The TCB shall
|
||
protect authentication data so that it cannot be accessed by any
|
||
unauthorized user.
|
||
|
||
C2: ADD: The TCB shall be able to enforce individual accountability by
|
||
providing the capability to uniquely identify each individual ADP
|
||
system user. The TCB shall also provide the capability of
|
||
associating this identity with all auditable actions taken by that
|
||
individual.
|
||
|
||
B1: CHANGE: Furthermore, the TCB shall maintain authentication data that
|
||
includes information for verifying the identity of individual users
|
||
(e.g., passwords) as well as information for determining the
|
||
clearance and authorizations of individual users. This data shall be
|
||
used by the TCB to authenticate the user's identity and to determine
|
||
the security level and authorizations of subjects that may be created
|
||
to act on behalf of the individual user.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Label Integrity
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NEW: Sensitivity labels shall accurately represent security levels of
|
||
the specific subjects or objects with which they are associated. When
|
||
exported by the TCB, sensitivity labels shall accurately and
|
||
unambiguously represent the internal labels and shall be associated
|
||
with the information being exported.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Labeling Human-Readable Output
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NEW: The ADP system administrator shall be able to specify the
|
||
printable label names associated with exported sensitivity labels.
|
||
The TCB shall mark the beginning and end of all human-readable,
|
||
paged, hardcopy output (e.g., line printer output) with human-
|
||
readable sensitivity labels that properly* represent the sensitivity
|
||
of the output. The TCB shall, by default, mark the top and bottom of
|
||
each page of human-readable, paged, hardcopy output (e.g., line
|
||
printer output) with human-readable sensitivity labels that
|
||
properly* represent the overall sensitivity of the output or that
|
||
properly* represent the sensitivity of the information on the page.
|
||
The TCB shall, by default and in an appropriate manner, mark other
|
||
forms of human-readable output (e.g., maps, graphics) with human-
|
||
readable sensitivity labels that properly* represent the sensitivity
|
||
of the output. Any override of these marking defaults shall be
|
||
auditable by the TCB.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
____________________________________________________________
|
||
* The hierarchical classification component in human-readable
|
||
sensitivity labels shall be equal to the greatest
|
||
hierarchical classification of any of the information in the
|
||
output that the labels refer to; the non-hierarchical
|
||
category component shall include all of the non-hierarchical
|
||
categories of the information in the output the labels refer
|
||
to, but no other non-hierarchical categories.
|
||
____________________________________________________________
|
||
|
||
|
||
Labels
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NEW: Sensitivity labels associated with each subject and storage
|
||
object under its control (e.g., process, file, segment, device) shall
|
||
be maintained by the TCB. These labels shall be used as the basis
|
||
for mandatory access control decisions. In order to import non-
|
||
labeled data, the TCB shall request and receive from an authorized
|
||
user the security level of the data, and all such actions shall be
|
||
auditable by the TCB.
|
||
|
||
B2: CHANGE: Sensitivity labels associated with each ADP system resource
|
||
(e.g., subject, storage object) that is directly or indirectly
|
||
accessible by subjects external to the TCB shall be maintained by
|
||
the TCB.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Mandatory Access Control
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NEW: The TCB shall enforce a mandatory access control policy over all
|
||
subjects and storage objects under its control (e.g., processes,
|
||
files, segments, devices). These subjects and objects shall be
|
||
assigned sensitivity labels that are a combination of hierarchical
|
||
classification levels and non-hierarchical categories, and the labels
|
||
shall be used as the basis for mandatory access control decisions.
|
||
The TCB shall be able to support two or more such security levels.
|
||
(See the Mandatory Access Control guidelines.) The following
|
||
requirements shall hold for all accesses between subjects and objects
|
||
controlled by the TCB: A subject can read an object only if the
|
||
hierarchical classification in the subject's security level is
|
||
greater than or equal to the hierarchical classification in the
|
||
object's security level and the non-hierarchical categories in the
|
||
subject's security level include all the non-hierarchical categories
|
||
in the object's security level. A subject can write an object only
|
||
if the hierarchical classification in the subject's security level is
|
||
less than or equal to the hierarchical classification in the object's
|
||
security level and all the non-hierarchical categories in the
|
||
subject's security level are included in the non-hierarchical
|
||
categories in the object's security level.
|
||
|
||
B2: CHANGE: The TCB shall enforce a mandatory access control policy over
|
||
all resources (i.e., subjects, storage objects, and I/O devices) that
|
||
are directly or indirectly accessible by subjects external to the TCB.
|
||
The following requirements shall hold for all accesses between all
|
||
subjects external to the TCB and all objects directly or indirectly
|
||
accessible by these subjects:
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Object Reuse
|
||
|
||
C1: NR.
|
||
|
||
C2: NEW: When a storage object is initially assigned, allocated, or
|
||
reallocated to a subject from the TCB's pool of unused storage
|
||
objects, the TCB shall assure that the object contains no data for
|
||
which the subject is not authorized.
|
||
|
||
B1: NAR.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Security Features User's Guide
|
||
|
||
C1: NEW: A single summary, chapter, or manual in user documentation shall
|
||
describe the protection mechanisms provided by the TCB, guidelines on
|
||
their use, and how they interact with one another.
|
||
|
||
C2: NAR.
|
||
|
||
B1: NAR.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Security Testing
|
||
|
||
C1: NEW: The security mechanisms of the ADP system shall be tested and
|
||
found to work as claimed in the system documentation. Testing shall
|
||
be done to assure that there are no obvious ways for an unauthorized
|
||
user to bypass or otherwise defeat the security protection mechanisms
|
||
of the TCB. (See the Security Testing guidelines.)
|
||
|
||
C2: ADD: Testing shall also include a search for obvious flaws that would
|
||
allow violation of resource isolation, or that would permit
|
||
unauthorized access to the audit or authentication data.
|
||
|
||
B1: NEW: The security mechanisms of the ADP system shall be tested and
|
||
found to work as claimed in the system documentation. A team of
|
||
individuals who thoroughly understand the specific implementation of
|
||
the TCB shall subject its design documentation, source code, and
|
||
object code to thorough analysis and testing. Their objectives shall
|
||
be: to uncover all design and implementation flaws that would permit
|
||
a subject external to the TCB to read, change, or delete data
|
||
normally denied under the mandatory or discretionary security policy
|
||
enforced by the TCB; as well as to assure that no subject (without
|
||
authorization to do so) is able to cause the TCB to enter a state
|
||
such that it is unable to respond to communications initiated by
|
||
other users. All discovered flaws shall be removed or neutralized
|
||
and the TCB retested to demonstrate that they have been eliminated
|
||
and that new flaws have not been introduced. (See the Security
|
||
Testing Guidelines.)
|
||
|
||
B2: CHANGE: All discovered flaws shall be corrected and the TCB retested
|
||
to demonstrate that they have been eliminated and that new flaws have
|
||
not been introduced.
|
||
|
||
ADD: The TCB shall be found relatively resistant to penetration.
|
||
Testing shall demonstrate that the TCB implementation is consistent
|
||
with the descriptive top-level specification.
|
||
|
||
B3: CHANGE: The TCB shall be found resistant to penetration.
|
||
|
||
ADD: No design flaws and no more than a few correctable
|
||
implementation flaws may be found during testing and there shall be
|
||
reasonable confidence that few remain.
|
||
|
||
A1: CHANGE: Testing shall demonstrate that the TCB implementation is
|
||
consistent with the formal top-level specification.
|
||
|
||
ADD: Manual or other mapping of the FTLS to the source code may form
|
||
a basis for penetration testing.
|
||
|
||
Subject Sensitivity Labels
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NR.
|
||
|
||
B2: NEW: The TCB shall immediately notify a terminal user of each change
|
||
in the security level associated with that user during an interactive
|
||
session. A terminal user shall be able to query the TCB as desired
|
||
for a display of the subject's complete sensitivity label.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
System Architecture
|
||
|
||
C1: NEW: The TCB shall maintain a domain for its own execution that
|
||
protects it from external interference or tampering (e.g., by
|
||
modification of its code or data structures). Resources controlled
|
||
by the TCB may be a defined subset of the subjects and objects in
|
||
the ADP system.
|
||
|
||
C2: ADD: The TCB shall isolate the resources to be protected so that they
|
||
are subject to the access control and auditing requirements.
|
||
|
||
B1: ADD: The TCB shall maintain process isolation through the provision
|
||
of distinct address spaces under its control.
|
||
|
||
B2: NEW: The TCB shall maintain a domain for its own execution that
|
||
protects it from external interference or tampering (e.g., by
|
||
modification of its code or data structures). The TCB shall maintain
|
||
process isolation through the provision of distinct address spaces
|
||
under its control. The TCB shall be internally structured into well-
|
||
defined largely independent modules. It shall make effective use of
|
||
available hardware to separate those elements that are protection-
|
||
critical from those that are not. The TCB modules shall be designed
|
||
such that the principle of least privilege is enforced. Features in
|
||
hardware, such as segmentation, shall be used to support logically
|
||
distinct storage objects with separate attributes (namely: readable,
|
||
writeable). The user interface to the TCB shall be completely
|
||
defined and all elements of the TCB identified.
|
||
|
||
B3: ADD: The TCB shall be designed and structured to use a complete,
|
||
conceptually simple protection mechanism with precisely defined
|
||
semantics. This mechanism shall play a central role in enforcing the
|
||
internal structuring of the TCB and the system. The TCB shall
|
||
incorporate significant use of layering, abstraction and data hiding.
|
||
Significant system engineering shall be directed toward minimizing
|
||
the complexity of the TCB and excluding from the TCB modules that are
|
||
not protection-critical.
|
||
|
||
A1: NAR.
|
||
|
||
System Integrity
|
||
|
||
C1: NEW: Hardware and/or software features shall be provided that can be
|
||
used to periodically validate the correct operation of the on-site
|
||
hardware and firmware elements of the TCB.
|
||
|
||
C2: NAR.
|
||
|
||
B1: NAR.
|
||
|
||
B2: NAR.
|
||
|
||
B3: NAR.
|
||
|
||
A1: NAR.
|
||
|
||
Test Documentation
|
||
|
||
C1: NEW: The system developer shall provide to the evaluators a document
|
||
that describes the test plan and results of the security mechanisms'
|
||
functional testing.
|
||
|
||
C2: NAR.
|
||
|
||
B1: NAR.
|
||
|
||
B2: ADD: It shall include results of testing the effectiveness of the
|
||
methods used to reduce covert channel bandwidths.
|
||
|
||
B3: NAR.
|
||
|
||
A1: ADD: The results of the mapping between the formal top-level
|
||
specification and the TCB source code shall be given.
|
||
|
||
Trusted Distribution
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NR.
|
||
|
||
B2: NR.
|
||
|
||
B3: NR.
|
||
|
||
A1: NEW: A trusted ADP system control and distribution facility shall be
|
||
provided for maintaining the integrity of the mapping between the
|
||
master data describing the current version of the TCB and the on-site
|
||
master copy of the code for the current version. Procedures (e.g.,
|
||
site security acceptance testing) shall exist for assuring that the
|
||
TCB software, firmware, and hardware updates distributed to a
|
||
customer are exactly as specified by the master copies.
|
||
|
||
Trusted Facility Management
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NR.
|
||
|
||
B2: NEW: The TCB shall support separate operator and administrator
|
||
functions.
|
||
|
||
B3: ADD: The functions performed in the role of a security administrator
|
||
shall be identified. The ADP system administrative personnel shall
|
||
only be able to perform security administrator functions after taking
|
||
a distinct auditable action to assume the security administrator role
|
||
on the ADP system. Non-security functions that can be performed in
|
||
the security administration role shall be limited strictly to those
|
||
essential to performing the security role effectively.
|
||
|
||
A1: NAR.
|
||
|
||
Trusted Facility Manual
|
||
|
||
C1: NEW: A manual addressed to the ADP system administrator shall present
|
||
cautions about functions and privileges that should be controlled
|
||
when running a secure facility.
|
||
|
||
C2: ADD: The procedures for examining and maintaining the audit files as
|
||
well as the detailed audit record structure for each type of audit
|
||
event shall be given.
|
||
|
||
B1: ADD: The manual shall describe the operator and administrator
|
||
functions related to security, to include changing the
|
||
characteristics of a user. It shall provide guidelines on the
|
||
consistent and effective use of the protection features of the
|
||
system, how they interact, how to securely generate a new TCB, and
|
||
facility procedures, warnings, and privileges that need to be
|
||
controlled in order to operate the facility in a secure manner.
|
||
|
||
B2: ADD: The TCB modules that contain the reference validation mechanism
|
||
shall be identified. The procedures for secure generation of a new
|
||
TCB from source after modification of any modules in the TCB shall
|
||
be described.
|
||
|
||
B3: ADD: It shall include the procedures to ensure that the system is
|
||
initially started in a secure manner. Procedures shall also be
|
||
included to resume secure system operation after any lapse in system
|
||
operation.
|
||
|
||
A1: NAR.
|
||
|
||
Trusted Path
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NR.
|
||
|
||
B2: NEW: The TCB shall support a trusted communication path between
|
||
itself and user for initial login and authentication. Communications
|
||
via this path shall be initiated exclusively by a user.
|
||
|
||
B3: CHANGE: The TCB shall support a trusted communication path between
|
||
itself and users for use when a positive TCB-to-user connection is
|
||
required (e.g., login, change subject security level).
|
||
Communications via this trusted path shall be activated exclusively
|
||
by a user or the TCB and shall be logically isolated and unmistakably
|
||
distinguishable from other paths.
|
||
|
||
A1: NAR.
|
||
|
||
Trusted Recovery
|
||
|
||
C1: NR.
|
||
|
||
C2: NR.
|
||
|
||
B1: NR.
|
||
|
||
B2: NR.
|
||
|
||
B3: NEW: Procedures and/or mechanisms shall be provided to assure that,
|
||
after an ADP system failure or other discontinuity, recovery without a
|
||
protection compromise is obtained.
|
||
|
||
A1: NAR.
|
||
|
||
|
||
|
||
|
||
|
||
(this page is reserved for Figure 1)
|
||
|
||
|
||
|
||
|
||
GLOSSARY
|
||
|
||
|
||
Access - A specific type of interaction between a subject and an object
|
||
that results in the flow of information from one to the other.
|
||
|
||
Approval/Accreditation - The official authorization that is
|
||
granted to an ADP system to process sensitive information in
|
||
its operational environment, based upon comprehensive
|
||
security evaluation of the system's hardware, firmware, and
|
||
software security design, configuration, and implementation
|
||
and of the other system procedural, administrative,
|
||
physical, TEMPEST, personnel, and communications security
|
||
controls.
|
||
|
||
Audit Trail - A set of records that collectively provide
|
||
documentary evidence of processing used to aid in tracing
|
||
from original transactions forward to related records and
|
||
reports, and/or backwards from records and reports to their
|
||
component source transactions.
|
||
|
||
Authenticate - To establish the validity of a claimed identity.
|
||
|
||
Automatic Data Processing (ADP) System - An assembly of computer
|
||
hardware, firmware, and software configured for the purpose
|
||
of classifying, sorting, calculating, computing,
|
||
summarizing, transmitting and receiving, storing, and
|
||
retrieving data with a minimum of human intervention.
|
||
|
||
Bandwidth - A characteristic of a communication channel that is
|
||
the amount of information that can be passed through it in a
|
||
given amount of time, usually expressed in bits per second.
|
||
|
||
Bell-LaPadula Model - A formal state transition model of computer
|
||
security policy that describes a set of access control
|
||
rules. In this formal model, the entities in a computer
|
||
system are divided into abstract sets of subjects and
|
||
objects. The notion of a secure state is defined and it is
|
||
proven that each state transition preserves security by
|
||
moving from secure state to secure state; thus, inductively
|
||
proving that the system is secure. A system state is
|
||
defined to be "secure" if the only permitted access modes of
|
||
subjects to objects are in accordance with a specific
|
||
security policy. In order to determine whether or not a
|
||
specific access mode is allowed, the clearance of a subject
|
||
is compared to the classification of the object and a
|
||
determination is made as to whether the subject is
|
||
authorized for the specific access mode. The
|
||
clearance/classification scheme is expressed in terms of a
|
||
lattice. See also: Lattice, Simple Security Property, *-
|
||
Property.
|
||
|
||
Certification - The technical evaluation of a system's security
|
||
features, made as part of and in support of the
|
||
approval/accreditation process, that establishes the extent
|
||
to which a particular computer system's design and
|
||
implementation meet a set of specified security
|
||
requirements.
|
||
|
||
Channel - An information transfer path within a system. May also
|
||
refer to the mechanism by which the path is effected.
|
||
|
||
Covert Channel - A communication channel that allows a process to
|
||
transfer information in a manner that violates the system's
|
||
security policy. See also: Covert Storage Channel, Covert
|
||
Timing Channel.
|
||
|
||
Covert Storage Channel - A covert channel that involves the
|
||
direct or indirect writing of a storage location by one
|
||
process and the direct or indirect reading of the storage
|
||
location by another process. Covert storage channels
|
||
typically involve a finite resource (e.g., sectors on a
|
||
disk) that is shared by two subjects at different security
|
||
levels.
|
||
|
||
Covert Timing Channel - A covert channel in which one process
|
||
signals information to another by modulating its own use of
|
||
system resources (e.g., CPU time) in such a way that this
|
||
manipulation affects the real response time observed by the
|
||
second process.
|
||
|
||
Data - Information with a specific physical representation.
|
||
|
||
Data Integrity - The state that exists when computerized data is
|
||
the same as that in the source documents and has not been
|
||
exposed to accidental or malicious alteration or
|
||
destruction.
|
||
|
||
Descriptive Top-Level Specification (DTLS) - A top-level
|
||
specification that is written in a natural language (e.g.,
|
||
English), an informal program design notation, or a
|
||
combination of the two.
|
||
|
||
Discretionary Access Control - A means of restricting access to
|
||
objects based on the identity of subjects and/or groups to
|
||
which they belong. The controls are discretionary in the
|
||
sense that a subject with a certain access permission is
|
||
capable of passing that permission (perhaps indirectly) on
|
||
to any other subject.
|
||
|
||
Domain - The set of objects that a subject has the ability to
|
||
access.
|
||
|
||
Dominate - Security level S1 is said to dominate security level
|
||
S2 if the hierarchical classification of S1 is greater than
|
||
or equal to that of S2 and the non-hierarchical categories
|
||
of S1 include all those of S2 as a subset.
|
||
|
||
Exploitable Channel - Any channel that is useable or detectable
|
||
by subjects external to the Trusted Computing Base.
|
||
|
||
Flaw Hypothesis Methodology - A system analysis and penetration
|
||
technique where specifications and documentation for the
|
||
system are analyzed and then flaws in the system are
|
||
hypothesized. The list of hypothesized flaws is then
|
||
prioritized on the basis of the estimated probability that a
|
||
flaw actually exists and, assuming a flaw does exist, on the
|
||
ease of exploiting it and on the extent of control or
|
||
compromise it would provide. The prioritized list is used
|
||
to direct the actual testing of the system.
|
||
|
||
Flaw - An error of commission, omission, or oversight in a system
|
||
that allows protection mechanisms to be bypassed.
|
||
|
||
Formal Proof - A complete and convincing mathematical argument,
|
||
presenting the full logical justification for each proof
|
||
step, for the truth of a theorem or set of theorems. The
|
||
formal verification process uses formal proofs to show the
|
||
truth of certain properties of formal specification and for
|
||
showing that computer programs satisfy their specifications.
|
||
|
||
Formal Security Policy Model - A mathematically precise statement
|
||
of a security policy. To be adequately precise, such a
|
||
model must represent the initial state of a system, the way
|
||
in which the system progresses from one state to another,
|
||
and a definition of a "secure" state of the system. To be
|
||
acceptable as a basis for a TCB, the model must be supported
|
||
by a formal proof that if the initial state of the system
|
||
satisfies the definition of a "secure" state and if all
|
||
assumptions required by the model hold, then all future
|
||
states of the system will be secure. Some formal modeling
|
||
techniques include: state transition models, temporal logic
|
||
models, denotational semantics models, algebraic
|
||
specification models. An example is the model described by
|
||
Bell and LaPadula in reference [2]. See also: Bell-
|
||
LaPadula Model, Security Policy Model.
|
||
|
||
Formal Top-Level Specification (FTLS) - A Top-Level Specification
|
||
that is written in a formal mathematical language to allow
|
||
theorems showing the correspondence of the system
|
||
specification to its formal requirements to be hypothesized
|
||
and formally proven.
|
||
|
||
Formal Verification - The process of using formal proofs to
|
||
demonstrate the consistency (design verification) between a
|
||
formal specification of a system and a formal security
|
||
policy model or (implementation verification) between the
|
||
formal specification and its program implementation.
|
||
|
||
Functional Testing - The portion of security testing in which the
|
||
advertised features of a system are tested for correct
|
||
operation.
|
||
|
||
General-Purpose System - A computer system that is designed to
|
||
aid in solving a wide variety of problems.
|
||
|
||
Lattice - A partially ordered set for which every pair of
|
||
elements has a greatest lower bound and a least upper bound.
|
||
|
||
Least Privilege - This principle requires that each subject in a
|
||
system be granted the most restrictive set of privileges (or
|
||
lowest clearance) needed for the performance of authorized
|
||
tasks. The application of this principle limits the damage
|
||
that can result from accident, error, or unauthorized use.
|
||
|
||
Mandatory Access Control - A means of restricting access to
|
||
objects based on the sensitivity (as represented by a label)
|
||
of the information contained in the objects and the formal
|
||
authorization (i.e., clearance) of subjects to access
|
||
information of such sensitivity.
|
||
|
||
Multilevel Device - A device that is used in a manner that
|
||
permits it to simultaneously process data of two or more
|
||
security levels without risk of compromise. To accomplish
|
||
this, sensitivity labels are normally stored on the same
|
||
physical medium and in the same form (i.e., machine-readable
|
||
or human-readable) as the data being processed.
|
||
|
||
Multilevel Secure - A class of system containing information with
|
||
different sensitivities that simultaneously permits access
|
||
by users with different security clearances and needs-to-
|
||
know, but prevents users from obtaining access to
|
||
information for which they lack authorization.
|
||
|
||
Object - A passive entity that contains or receives information.
|
||
Access to an object potentially implies access to the
|
||
information it contains. Examples of objects are: records,
|
||
blocks, pages, segments, files, directories, directory
|
||
trees, and programs, as well as bits, bytes, words, fields,
|
||
processors, video displays, keyboards, clocks, printers,
|
||
network nodes, etc.
|
||
|
||
Object Reuse - The reassignment to some subject of a medium
|
||
(e.g., page frame, disk sector, magnetic tape) that
|
||
contained one or more objects. To be securely reassigned,
|
||
such media must contain no residual data from the previously
|
||
contained object(s).
|
||
|
||
Output - Information that has been exported by a TCB.
|
||
|
||
Password - A private character string that is used to
|
||
authenticate an identity.
|
||
|
||
Penetration Testing - The portion of security testing in which
|
||
the penetrators attempt to circumvent the security features
|
||
of a system. The penetrators may be assumed to use all
|
||
system design and implementation documentation, which may
|
||
include listings of system source code, manuals, and circuit
|
||
diagrams. The penetrators work under no constraints other
|
||
than those that would be applied to ordinary users.
|
||
|
||
Process - A program in execution. It is completely characterized
|
||
by a single current execution point (represented by the
|
||
machine state) and address space.
|
||
|
||
Protection-Critical Portions of the TCB - Those portions of the
|
||
TCB whose normal function is to deal with the control of
|
||
access between subjects and objects.
|
||
|
||
Protection Philosophy - An informal description of the overall
|
||
design of a system that delineates each of the protection
|
||
mechanisms employed. A combination (appropriate to the
|
||
evaluation class) of formal and informal techniques is used
|
||
to show that the mechanisms are adequate to enforce the
|
||
security policy.
|
||
|
||
Read - A fundamental operation that results only in the flow of
|
||
information from an object to a subject.
|
||
|
||
Read Access - Permission to read information.
|
||
|
||
Reference Monitor Concept - An access control concept that refers
|
||
to an abstract machine that mediates all accesses to objects
|
||
by subjects.
|
||
|
||
Resource - Anything used or consumed while performing a function.
|
||
The categories of resources are: time, information, objects
|
||
(information containers), or processors (the ability to use
|
||
information). Specific examples are: CPU time; terminal
|
||
connect time; amount of directly-addressable memory; disk
|
||
space; number of I/O requests per minute, etc.
|
||
|
||
Security Kernel - The hardware, firmware, and software elements
|
||
of a Trusted Computing Base that implement the reference
|
||
monitor concept. It must mediate all accesses, be protected
|
||
from modification, and be verifiable as correct.
|
||
|
||
Security Level - The combination of a hierarchical classification
|
||
and a set of non-hierarchical categories that represents the
|
||
sensitivity of information.
|
||
|
||
Security Policy - The set of laws, rules, and practices that
|
||
regulate how an organization manages, protects, and
|
||
distributes sensitive information.
|
||
|
||
Security Policy Model - An informal presentation of a formal
|
||
security policy model.
|
||
|
||
Security Testing - A process used to determine that the security
|
||
features of a system are implemented as designed and that
|
||
they are adequate for a proposed application environment.
|
||
This process includes hands-on functional testing,
|
||
penetration testing, and verification. See also: Functional
|
||
Testing, Penetration Testing, Verification.
|
||
|
||
Sensitive Information - Information that, as determined by a
|
||
competent authority, must be protected because its
|
||
unauthorized disclosure, alteration, loss, or destruction
|
||
will at least cause perceivable damage to someone or
|
||
something.
|
||
|
||
Sensitivity Label - A piece of information that represents the
|
||
security level of an object and that describes the
|
||
sensitivity (e.g., classification) of the data in the
|
||
object. Sensitivity labels are used by the TCB as the basis
|
||
for mandatory access control decisions.
|
||
|
||
Simple Security Property - A Bell-LaPadula security model rule
|
||
allowing a subject read access to an object only if the
|
||
security level of the subject dominates the security level
|
||
of the object.
|
||
|
||
Single-Level Device - A device that is used to process data of a
|
||
single security level at any one time. Since the device
|
||
need not be trusted to separate data of different security
|
||
levels, sensitivity labels do not have to be stored with the
|
||
data being processed.
|
||
|
||
*-Property (Star Property) - A Bell-LaPadula security model rule
|
||
allowing a subject write access to an object only if the
|
||
security level of the subject is dominated by the security
|
||
level of the object. Also known as the Confinement
|
||
Property.
|
||
|
||
Storage Object - An object that supports both read and write
|
||
accesses.
|
||
|
||
Subject - An active entity, generally in the form of a person,
|
||
process, or device that causes information to flow among
|
||
objects or changes the system state. Technically, a
|
||
process/domain pair.
|
||
|
||
Subject Security Level - A subject's security level is equal to
|
||
the security level of the objects to which it has both read
|
||
and write access. A subject's security level must always be
|
||
dominated by the clearance of the user the subject is
|
||
associated with.
|
||
|
||
TEMPEST - The study and control of spurious electronic signals
|
||
emitted from ADP equipment.
|
||
|
||
Top-Level Specification (TLS) - A non-procedural description of
|
||
system behavior at the most abstract level. Typically a
|
||
functional specification that omits all implementation
|
||
details.
|
||
|
||
Trap Door - A hidden software or hardware mechanism that permits
|
||
system protection mechanisms to be circumvented. It is
|
||
activated in some non-apparent manner (e.g., special
|
||
"random" key sequence at a terminal).
|
||
|
||
Trojan Horse - A computer program with an apparently or actually
|
||
useful function that contains additional (hidden) functions
|
||
that surreptitiously exploit the legitimate authorizations
|
||
of the invoking process to the detriment of security. For
|
||
example, making a "blind copy" of a sensitive file for the
|
||
creator of the Trojan Horse.
|
||
|
||
Trusted Computer System - A system that employs sufficient
|
||
hardware and software integrity measures to allow its use
|
||
for processing simultaneously a range of sensitive or
|
||
classified information.
|
||
|
||
Trusted Computing Base (TCB) - The totality of protection
|
||
mechanisms within a computer system -- including hardware,
|
||
firmware, and software -- the combination of which is
|
||
responsible for enforcing a security policy. It creates a
|
||
basic protection environment and provides additional user
|
||
services required for a trusted computer system. The
|
||
ability of a trusted computing base to correctly enforce a
|
||
security policy depends solely on the mechanisms within the
|
||
TCB and on the correct input by system administrative
|
||
personnel of parameters (e.g., a user's clearance) related
|
||
to the security policy.
|
||
|
||
Trusted Path - A mechanism by which a person at a terminal can
|
||
communicate directly with the Trusted Computing Base. This
|
||
mechanism can only be activated by the person or the Trusted
|
||
Computing Base and cannot be imitated by untrusted software.
|
||
|
||
Trusted Software - The software portion of a Trusted Computing
|
||
Base.
|
||
|
||
User - Any person who interacts directly with a computer system.
|
||
|
||
Verification - The process of comparing two levels of system
|
||
specification for proper correspondence (e.g., security
|
||
policy model with top-level specification, TLS with source
|
||
code, or source code with object code). This process may or
|
||
may not be automated.
|
||
|
||
Write - A fundamental operation that results only in the flow of
|
||
information from a subject to an object.
|
||
|
||
Write Access - Permission to write an object.
|
||
|
||
|
||
|
||
|
||
|
||
REFERENCES
|
||
|
||
|
||
1. Anderson, J. P. Computer Security Technology Planning
|
||
Study, ESD-TR-73-51, vol. I, ESD/AFSC, Hanscom AFB,
|
||
Bedford, Mass., October 1972 (NTIS AD-758 206).
|
||
|
||
2. Bell, D. E. and LaPadula, L. J. Secure Computer Systems:
|
||
Unified Exposition and Multics Interpretation, MTR-2997
|
||
Rev. 1, MITRE Corp., Bedford, Mass., March 1976.
|
||
|
||
3. Brand, S. L. "An Approach to Identification and Audit of
|
||
Vulnerabilities and Control in Application Systems," in
|
||
Audit and Evaluation of Computer Security II: System
|
||
Vulnerabilities and Controls, Z. Ruthberg, ed., NBS
|
||
Special Publication #500-57, MD78733, April 1980.
|
||
|
||
4. Brand, S. L. "Data Processing and A-123," in Proceedings of
|
||
the Computer Performance Evaluation User's Group 18th
|
||
Meeting, C. B. Wilson, ed., NBS Special Publication
|
||
#500-95, October 1982.
|
||
|
||
5. Denning, D. E. "A Lattice Model of Secure Information
|
||
Flow," in Communications of the ACM, vol. 19, no. 5
|
||
(May 1976), pp. 236-243.
|
||
|
||
6. Denning, D. E. Secure Information Flow in Computer Systems,
|
||
Ph.D. dissertation, Purdue Univ., West Lafayette, Ind.,
|
||
May 1975.
|
||
|
||
7. DoD 5200.1-R, Information Security Program Regulation,
|
||
August 1982.
|
||
|
||
8. DoD Directive 5200.28, Security Requirements for Automatic
|
||
Data Processing (ADP) Systems, revised April 1978.
|
||
|
||
9. DoD 5200.28-M, ADP Security Manual -- Techniques and
|
||
Procedures for Implementing, Deactivating, Testing, and
|
||
Evaluating Secure Resource-Sharing ADP Systems, revised
|
||
June 1979.
|
||
|
||
10. DoD Directive 5215.1, Computer Security Evaluation Center,
|
||
25 October 1982.
|
||
|
||
11. DoD 5220.22-M, Industrial Security Manual for Safeguarding
|
||
Classified Information, January 1983.
|
||
|
||
12. DoD 5220.22-R, Industrial Security Regulation, January 1983.
|
||
|
||
13. DoD Directive 5400.11, Department of Defense Privacy
|
||
Program, 9 June 1982.
|
||
|
||
14. Executive Order 12356, National Security Information,
|
||
6 April 1982.
|
||
|
||
15. Faurer, L. D. "Keeping the Secrets Secret," in Government
|
||
Data Systems, November - December 1981, pp. 14-17.
|
||
|
||
16. Federal Information Processing Standards Publication (FIPS
|
||
PUB) 39, Glossary for Computer Systems Security,
|
||
15 February 1976.
|
||
|
||
17. Federal Information Processing Standards Publication (FIPS
|
||
PUB) 73, Guidelines for Security of Computer
|
||
Applications, 30 June 1980.
|
||
|
||
18. Federal Information Processing Standards Publication (FIPS
|
||
PUB) 102, Guideline for Computer Security Certification
|
||
and Accreditation.
|
||
|
||
19. Lampson, B. W. "A Note on the Confinement Problem," in
|
||
Communications of the ACM, vol. 16, no. 10 (October
|
||
1973), pp. 613-615.
|
||
|
||
20. Lee, T. M. P., et al. "Processors, Operating Systems and
|
||
Nearby Peripherals: A Consensus Report," in Audit and
|
||
Evaluation of Computer Security II: System
|
||
Vulnerabilities and Controls, Z. Ruthberg, ed., NBS
|
||
Special Publication #500-57, MD78733, April 1980.
|
||
|
||
21. Lipner, S. B. A Comment on the Confinement Problem, MITRE
|
||
Corp., Bedford, Mass.
|
||
|
||
22. Millen, J. K. "An Example of a Formal Flow Violation," in
|
||
Proceedings of the IEEE Computer Society 2nd
|
||
International Computer Software and Applications
|
||
Conference, November 1978, pp. 204-208.
|
||
|
||
23. Millen, J. K. "Security Kernel Validation in Practice," in
|
||
Communications of the ACM, vol. 19, no. 5 (May 1976),
|
||
pp. 243-250.
|
||
|
||
24. Nibaldi, G. H. Proposed Technical Evaluation Criteria for
|
||
Trusted Computer Systems, MITRE Corp., Bedford, Mass.,
|
||
M79-225, AD-A108-832, 25 October 1979.
|
||
|
||
25. Nibaldi, G. H. Specification of A Trusted Computing Base,
|
||
(TCB), MITRE Corp., Bedford, Mass., M79-228, AD-A108-
|
||
831, 30 November 1979.
|
||
|
||
26. OMB Circular A-71, Transmittal Memorandum No. 1, Security of
|
||
Federal Automated Information Systems, 27 July 1978.
|
||
|
||
27. OMB Circular A-123, Internal Control Systems, 5 November
|
||
1981.
|
||
|
||
28. Ruthberg, Z. and McKenzie, R., eds. Audit and Evaluation of
|
||
Computer Security, in NBS Special Publication #500-19,
|
||
October 1977.
|
||
|
||
29. Schaefer, M., Linde, R. R., et al. "Program Confinement in
|
||
KVM/370," in Proceedings of the ACM National
|
||
Conference, October 1977, Seattle.
|
||
|
||
30. Schell, R. R. "Security Kernels: A Methodical Design of
|
||
System Security," in Technical Papers, USE Inc. Spring
|
||
Conference, 5-9 March 1979, pp. 245-250.
|
||
|
||
31. Trotter, E. T. and Tasker, P. S. Industry Trusted Computer
|
||
Systems Evaluation Process, MITRE Corp., Bedford,
|
||
Mass., MTR-3931, 1 May 1980.
|
||
|
||
32. Turn, R. Trusted Computer Systems: Needs and Incentives for
|
||
Use in government and Private Sector, (AD # A103399),
|
||
Rand Corporation (R-28811-DR&E), June 1981.
|
||
|
||
33. Walker, S. T. "The Advent of Trusted Computer Operating
|
||
Systems," in National Computer Conference Proceedings,
|
||
May 1980, pp. 655-665.
|
||
|
||
34. Ware, W. H., ed., Security Controls for Computer Systems:
|
||
Report of Defense Science Board Task Force on Computer
|
||
Security, AD # A076617/0, Rand Corporation, Santa
|
||
Monica, Calif., February 1970, reissued October 1979.
|
||
|
||
DoD STANDARD 5200.28: SUMMARY OF THE DIFFERENCES
|
||
BETWEEN IT AND CSC-STD-001-83
|
||
|
||
|
||
Note: Text which has been added or changed is indented and preceded by > sign.
|
||
Text which has been deleted is enclosed in slashes (/). "Computer Security
|
||
Center" was changed to "National Computer Security Center" throughout the
|
||
document.
|
||
|
||
The FOREWORD Section was rewritten and signed by Mr. Don Latham on
|
||
26 Dec 85. The ACKNOWLEDGEMENTS Section was updated.
|
||
|
||
The PREFACE was changed as follows:
|
||
|
||
PREFACE
|
||
|
||
|
||
The trusted computer system evaluation criteria defined in this
|
||
document classify systems into four broad hierarchical divisions
|
||
of enhanced security protection. The criteria provide a basis
|
||
for the evaluation of effectiveness of security controls built
|
||
into automatic data processing system products. The criteria
|
||
were developed with three objectives in mind: (a) to provide
|
||
users with a yardstick with which to assess the degree of trust
|
||
that can be placed in computer systems for the secure processing
|
||
of classified or other sensitive information; (b) to provide
|
||
guidance to manufacturers as to what to build into their new,
|
||
widely-available trusted commercial products in order to satisfy
|
||
trust requirements for sensitive applications; and (c) to provide
|
||
a basis for specifying security requirements in acquisition
|
||
specifications. Two types of requirements are delineated for
|
||
secure processing: (a) specific security feature requirements and
|
||
(b) assurance requirements. Some of the latter requirements
|
||
enable evaluation personnel to determine if the required features
|
||
are present and functioning as intended.
|
||
|
||
>The scope of these criteria is to be applied to
|
||
>the set of components comprising a trusted system, and is
|
||
>not necessarily to be applied to each system component
|
||
>individually. Hence, some components of a system may be
|
||
>completely untrusted, while others may be individually
|
||
>evaluated to a lower or higher evaluation class than the
|
||
>trusted product considered as a whole system. In trusted
|
||
>products at the high end of the range, the strength of the
|
||
>reference monitor is such that most of the system
|
||
>components can be completely untrusted.
|
||
|
||
Though the criteria are
|
||
|
||
>intended to be
|
||
|
||
application-independent, /it is recognized that/ the
|
||
specific security feature requirements may have to be
|
||
interpreted when applying the criteria to specific
|
||
|
||
>systems with their own functional requirements,
|
||
>applications or special environments (e.g., communications
|
||
>processors, process control computers, and embedded systems
|
||
>in general).
|
||
|
||
The underlying assurance requirements can be
|
||
applied across the entire spectrum of ADP system or
|
||
application processing environments without special
|
||
interpretation.
|
||
|
||
|
||
The SCOPE Section was changed as follows:
|
||
|
||
Scope
|
||
|
||
The trusted computer system evaluation criteria defined in this
|
||
document apply
|
||
|
||
>primarily
|
||
|
||
to /both/ trusted, commercially available
|
||
automatic data processing (ADP) systems.
|
||
|
||
>They are also applicable, as amplified below, to the
|
||
>evaluation of existing systems and to the specification of
|
||
>security requirements for ADP systems acquisition.
|
||
|
||
==================================================================
|
||
|
||
/ /
|
||
/ File 05 / NIA071 /
|
||
/ List of USENET Texas Nodes /
|
||
/ Lord Macduff /
|
||
/ /
|
||
|
||
|
||
This is a list of all USENET nodes in Texas. They are presented in the
|
||
following format:
|
||
|
||
nodename
|
||
Corporation that owns machine
|
||
System Administrator
|
||
Netmail address
|
||
Phone Number
|
||
Physical Address
|
||
|
||
Have fun, and let me know if you have any luck getting accounts/etc. on
|
||
any of these systems.
|
||
|
||
accu-reg
|
||
Accu-Reg, Inc.
|
||
Brenda Brakebill
|
||
accu-reg!root
|
||
214 934 9533
|
||
4220 Beltwood Parkway #107, Dallas, TX 75244
|
||
|
||
acsi
|
||
Advanced Computing Solutions, Inc.
|
||
Russ Helbig
|
||
acsi!hrh
|
||
713 280 9917
|
||
17049 El Camino Real, Suite 202, Houston, TX 77058
|
||
|
||
actnet
|
||
NEC America, Inc.
|
||
Tom Scurlock
|
||
actnet!root
|
||
214 907 4492
|
||
383 Omni Drive, Richardson, TX 75080
|
||
|
||
acw
|
||
Austin Code Works
|
||
Scott B. Guthery
|
||
acw!guthery
|
||
512 258 0785
|
||
11100 Leafwood Lane, Austin, Texas 78750-3409
|
||
|
||
adaptex
|
||
Adaptec Inc.
|
||
Roy Neese
|
||
adaptex!neese
|
||
817-481-3390
|
||
Adaptec Inc.;1701 W. Northwest Highway;Grapevine, Tx. 76051
|
||
|
||
adaptx1
|
||
Adaptec Inc.
|
||
Roy Neese
|
||
adaptx1!neese
|
||
817-481-3390
|
||
Adaptec Inc.;1701 W. Northwest Highway;Grapevine, Tx. 75051
|
||
|
||
aefvadh
|
||
private system
|
||
Ed Carp
|
||
khijol!erc
|
||
512 832 5884
|
||
2000 Cedar Bend Dr., Austin, TX 78758
|
||
NOTES: aefvadh means "Be welcome" in Rihannsu (or Romulan, if you prefer)
|
||
|
||
aerot
|
||
Aero Tire and Tank Inc.
|
||
David Kirby
|
||
aerot!david
|
||
214 247 2845
|
||
P.O.Box 59889, Dallas, Tx, 75229-1889
|
||
|
||
afbs, afbs.af.mil
|
||
Headquarters Air Force Broadcasting Service
|
||
Durand C. 'Randy' Waters, Chief Information Resources Division
|
||
xoidw@afbs.af.mil
|
||
512 925 8861
|
||
HQ AFBS/XOI, Kelly AFB, TX 78241-5000
|
||
|
||
afnews, afnews.af.mil
|
||
Air Force News Center
|
||
Michael L. Bergman, Chief Communications-Computer Systems
|
||
afnews!bergman
|
||
512 925 8688
|
||
AFNEWS/SCC, Kelly AFB TX 78241-5000
|
||
|
||
agent99
|
||
Dell Computer Corporation
|
||
Ron McDowell
|
||
agent99!postmaster
|
||
512 338 4400
|
||
9505 Arboretum Blvd., Austin, TX 78759-7299
|
||
|
||
airgun, airgun.wg.waii.com
|
||
Western Geophysical - Division of Western Atlas International Inc.
|
||
Mark I. Whetzel, Frank Vance
|
||
postmaster@airgun.wg.waii.com
|
||
713 789 9600 x2446, 713 789 9600 x2426
|
||
10,001 Richmond Avenue, Houston, TX 77042
|
||
|
||
aixserv
|
||
IBM
|
||
Jerome Park
|
||
aixserv!jerome
|
||
512 823 2082
|
||
11400 Burnet Rd., Zip 2900, Austin, TX 78758
|
||
|
||
ajahnv, ajahnv.lonestar.org
|
||
private system
|
||
Alfredo Jahn V
|
||
postmaster@ajahnv.UUCP
|
||
214-855-1316
|
||
3208 Cole Ave., #1303, Dallas, TX 75204
|
||
|
||
akasha
|
||
The Akashic Records
|
||
Ed Carp
|
||
khijol!erc
|
||
512 832 5884
|
||
2000 Cedar Bend Dr., Austin, TX 78758
|
||
|
||
aldoe
|
||
IRS ICS Micro Support
|
||
Kenneth R. Moore
|
||
aldoe!kmoore
|
||
214 308-1752
|
||
4050 Alpha Rd MC 5005 Dallas, Tx. 75244
|
||
|
||
amair
|
||
American Airlines
|
||
Jim Swanson
|
||
amair!jim
|
||
817 963 4310
|
||
MD 4480, P.O.Box 619630, DFW Airport, TX 75261
|
||
|
||
amytree
|
||
Donald A Kassebaum
|
||
Donald A Kassebaum
|
||
amytree!dak
|
||
512 462 9963
|
||
506 Strawberry Cove ; Austin, Tx 78745
|
||
|
||
angel
|
||
Angels Retreat
|
||
Larry Tenbush
|
||
angel!larry
|
||
512 696 0995
|
||
P.O. Box 5659, San Antonio, TX 78201-0659
|
||
DIALUP: 512 696-7708
|
||
NOTES: Public System
|
||
|
||
apcidfw
|
||
Apollo Division, Hewlett-Packard Company
|
||
Keith Cantrell
|
||
apcidfw!keith
|
||
1 214-519-2399
|
||
3301 Royal Lane, Irving, Texas
|
||
|
||
apiary
|
||
Advanced Micro Devices, Inc.
|
||
Terry Bush
|
||
apiary!terry
|
||
512 356 3443
|
||
M.S. 511, 5204 E. Ben White Blvd., Austin, TX 78741
|
||
|
||
aquinas, aquinas.lonestar.org
|
||
Privately Owned System
|
||
Sean McCollister
|
||
aquinas!postmaster
|
||
214 414 0936
|
||
1914 Sage Drive, Garland, TX 75040
|
||
|
||
armcomp
|
||
ASC People Connection
|
||
Byron Armstrong
|
||
armcomp!sysop
|
||
(512) 647-8189
|
||
No Known Address
|
||
NOTES: Public Electronic Message System
|
||
|
||
ataritx
|
||
Atari MicroSystems Corp.
|
||
Dave Hanna
|
||
ataritx!postmaster
|
||
214 713 9111
|
||
4115 Keller Springs Rd, Suite 200, Dallas, TX 75244
|
||
|
||
austex
|
||
JP Price
|
||
JP Price
|
||
austex!jprice
|
||
512 444 8691
|
||
810 W. St. Elmo, Austin TX 78745
|
||
|
||
austsun
|
||
Sun Microsystems, Inc.
|
||
Jim Thompson
|
||
jthomp@Sun.COM
|
||
214 788 1951
|
||
14785 Preston Road, Suite 1050, Dallas, TX 75240-7607
|
||
|
||
avocado
|
||
personal system
|
||
Gary Morris, N5QWC
|
||
avocado!postmaster
|
||
713 283 5195 (daytime)
|
||
P.O. Box 580148, Houston, TX 77258-0148
|
||
|
||
awful
|
||
a.out computer consultants
|
||
Andrew Fullford
|
||
awful!postmaster
|
||
214 386 2941
|
||
14930 Cypress Hills Drive, Dallas, Texas 75248
|
||
|
||
balkan, .tnt.com
|
||
Tools & Techniques, Inc.
|
||
William G. Bunton
|
||
postmaster@balkan.tnt.com, wgb@balkan.tnt.com
|
||
512 482 0824
|
||
1620 W 12th St., Austin, TX 78703
|
||
|
||
baylor
|
||
Baylor College of Medicine
|
||
Stan Barber
|
||
sob@tmc.edu
|
||
713 798 6042
|
||
One Baylor Plaza, Houston, Tx 77030
|
||
|
||
bcm
|
||
Baylor College of Medicine
|
||
Stan Barber
|
||
postmaster@tmc.edu, sob@bcm.tmc.edu
|
||
713 798 6042
|
||
Baylor College of Medicine, One Baylor Plaza, Houston, Texas 77030
|
||
|
||
bearsw
|
||
Bear Software
|
||
K. Finkemeyer
|
||
bearsw!karlf
|
||
817 962 8080
|
||
P.O. Box 729, Colleyville, TX 76034
|
||
|
||
bigboy
|
||
Capital Institutional Services
|
||
Steve Wheeler
|
||
bigboy!root
|
||
214 720 0050
|
||
750 N St. Paul, Suite 2200, Dallas, TX 75201
|
||
|
||
bigtex, .cactus.org
|
||
Institute of Applied Cosmology
|
||
James Van Artsdalen
|
||
postmaster@bigtex.cactus.org
|
||
512 338 8789
|
||
Dell Computer Co, AR3, 9505 Arboretum Blvd., Austin TX 78759
|
||
|
||
biogfx
|
||
Biographics, Inc.
|
||
Wade K. Smith
|
||
biogfx!postmaster
|
||
214 637 4112
|
||
1221 Riverbend Drive Suite 273, Dallas TX 75247
|
||
|
||
blackice
|
||
privately held
|
||
Phil Brownfield
|
||
blackice!postmaster
|
||
512 873 2022
|
||
PO Box 201480, Austin, TX 78720 USA
|
||
|
||
bodedo, bodedo.ucm.org
|
||
Jon Boede Consulting
|
||
Jon Boede
|
||
bodedo.ucm.org!postmaster
|
||
512 346-3142
|
||
7117 Wood Hollow #1013, Austin TX, 78731-2548
|
||
|
||
bonnell
|
||
Mount Bonnell Inc.
|
||
William King
|
||
bonnell!uuadm
|
||
512 478 1122
|
||
1201 West 24th St, Suite 103, Austin, TX 78705
|
||
|
||
botany
|
||
University of Texas at Austin
|
||
Brook G. Milligan
|
||
ut-emx!brook
|
||
512 471 3530
|
||
Department of Botany
|
||
|
||
brain
|
||
BIAP Systems, Mac Software Development
|
||
Chuck Shotton
|
||
brain!chuck
|
||
713 480-9489, 713 282-6444
|
||
1418 New Cedars Dr., Houston, TX 77062
|
||
|
||
buster, buster.stafford.tx.us
|
||
Unix Software Development System
|
||
Buster Irby
|
||
buster!postmaster
|
||
713 499 5735, 713 556 3877
|
||
13019 Naples Lane, Stafford, Texas 77477
|
||
|
||
cadillac
|
||
MCC CAD Program
|
||
John Arisco, David Dow, Johnny Kwan
|
||
arisco@mcc.com, dow@mcc.com, kwan@mcc.com
|
||
512 338 3576, 512 338 3777, 512 338 3483
|
||
3500 West Balcones Center Dr., Austin, TX 78759
|
||
NOTES:Cadillac will only call other sites. No dial in connections allowed.
|
||
|
||
cairns
|
||
Youth With a Mission Mercy Ships
|
||
Lance Lenz
|
||
cairns!root
|
||
903 963 8341
|
||
P.O Box 2020 Lindale Tx. 75771
|
||
|
||
caleb
|
||
Private system
|
||
Jim Pritchett
|
||
caleb!jdp
|
||
817 377 2919
|
||
4605 Ranch View Road, Fort Worth, TX 76109
|
||
|
||
camdev
|
||
Motorola Inc, Communications Sector; Mobile Products Division
|
||
Steve Scott
|
||
camdev!sscott
|
||
817 232 6317
|
||
CAMS 4G; P.O. Box 2931, Ft. Worth, Texas 76113
|
||
NOTES:gateway machine to Motorola Ft. Worth network
|
||
|
||
carpet
|
||
W.L. Kennedy Jr. & Associates
|
||
William L. Kennedy, Jr. (Bill)
|
||
bill@ssbn.WLK.COM
|
||
512 535 4966
|
||
Box 63449 Bandera Falls, Pipe Creek, TX 78063-3449
|
||
ccmaint
|
||
University of Texas, Computation Center
|
||
Frank L. Abernathy [Editor's Note: Any relation to Joe?]
|
||
frank@ccmaint.UUCP
|
||
(512) 471-3241 x291
|
||
Austin, TX 78712
|
||
|
||
cerebell
|
||
Harrington Cancer Center
|
||
Kim Anderson
|
||
cerebell!root
|
||
806 359 4673
|
||
1500 Wallace Blvd, Amarillo, TX 79106
|
||
|
||
charlie
|
||
ALFA Engineering, Inc.
|
||
Donald Ninke
|
||
don@charlie.UUCP
|
||
512 794 8680
|
||
8911 Capitol of Texas Highway North, Suite 3210, Austin, TX 78759
|
||
|
||
chemsh
|
||
ChemShare Corporation
|
||
Douglas L. Acker
|
||
chemsh!postmaster
|
||
713 267 5602
|
||
PO Box 1885, Houston, Texas 77251
|
||
|
||
chinacat, .unicom.com
|
||
Unicom Systems Development
|
||
Chip Rosenthal
|
||
chinacat!postmaster
|
||
512 482 8260
|
||
2813A Rio Grande, Suite 105, Austin, TX 78705
|
||
|
||
chron (chron.com)
|
||
Houston Chronicle
|
||
Matt Cohen
|
||
postmaster@chron.com
|
||
713 220 7023
|
||
P.O. Box 4260, Houston, TX 77210
|
||
|
||
cleo
|
||
Alternative Broadcast Technology
|
||
Todd Nix
|
||
cleo!news
|
||
512 339 2242
|
||
4503 Abelia Drive, Austin, Texas 78727-5866
|
||
|
||
cms2, cms2.lonestar.org
|
||
Christian Medical & Dental Society
|
||
Alan McCain
|
||
cms2!alan
|
||
214 783 8384
|
||
1616 Gateway Blvd., Richardson, TX 75080
|
||
|
||
color48
|
||
Best Printing Co.
|
||
James Howard
|
||
color48!postmaster
|
||
512 477 9733
|
||
3218 Manor Rd. Austin, Tx 78723
|
||
|
||
convex, convex.com, .convex.com
|
||
Convex Computer Corporation
|
||
Coyne Gibson
|
||
coyne@convex.com
|
||
214 497 4842
|
||
3000 Waterview Parkway, Richardson, TX 75083
|
||
|
||
cord
|
||
Arco Oil & Gas
|
||
Gary White
|
||
cord!gwhite
|
||
214 754 6554
|
||
2300 W Plano Pkwy, Plano, TX 75075
|
||
|
||
cortex
|
||
Division of Neuroscience, Baylor College of Medicine
|
||
Mahmud Haque
|
||
postmaster@soma.bcm.tmc.edu, mahmud@soma.bcm.tmc.edu
|
||
713 789 5985
|
||
Division of Neuroscience, Baylor College of Medicine,
|
||
One Baylor Plaza, Houston, Texas 77030
|
||
|
||
cowboy
|
||
Frontier Information Systems
|
||
Kevin Langston
|
||
cowboy!postmaster, frontier!postmaster
|
||
214 315 0942
|
||
2025 Frontier Trail, Lewisville, TX 75067
|
||
|
||
cpqhou
|
||
Compaq Computer Corp.
|
||
Michael Nikolaiev
|
||
cpqhou!root
|
||
713 374 2716
|
||
M-206, PO Box 692660, Houston, TX 77269-2000
|
||
|
||
crick
|
||
Baylor College of Medicine
|
||
Stan Barber
|
||
postmaster@watson.bcm.tmc.edu
|
||
713 798 6042
|
||
Baylor College of Medicine, One Baylor Plaza, Houston, Texas 77030
|
||
|
||
cronus
|
||
Exxon Shipping Co.
|
||
Lee Parsons
|
||
cronus!root
|
||
713 656 5394
|
||
800 Bell, RM 3424, Houston, TX 77002
|
||
|
||
crucible
|
||
PowerTools
|
||
Al Evans
|
||
crucible!al
|
||
512 454 8201
|
||
1206 Karen Avenue, Austin, TX 78757
|
||
|
||
cs.utexas.edu
|
||
University of Texas, Austin, Dept. of Computer Sciences
|
||
Fletcher Mattox, John Chambers
|
||
cs.utexas.edu!postmaster
|
||
+1 512 471 7316
|
||
U. Texas, Dept. of Computer Sciences, Austin, TX 78712
|
||
|
||
csccat, csccat.cs.com, .cs.com
|
||
Computer Support Corporation
|
||
Jack Hudler
|
||
cscdec!jack
|
||
214 661 8960
|
||
15926 Midway Rd., Dallas, Texas 75244
|
||
|
||
csdnet
|
||
CogniSeis Development
|
||
John D. Deans
|
||
csdnet!deans
|
||
713 630 3854
|
||
2401 Portsmouth, Houston, TX. 77098
|
||
|
||
csoftec, .csf.com
|
||
CompSofTech Co.
|
||
Cliff Manis
|
||
csoftec!postmaster
|
||
512 654 9912
|
||
P. O. Box 33937, San Antonio, Texas 78265
|
||
|
||
ctbilbo
|
||
Communications Technology Corporation
|
||
Pete Ritter
|
||
ctbilbo!root
|
||
214 991 8338
|
||
4100 McEwen Drive, Suite 244, Dallas, TX 75244
|
||
|
||
cygnusx1,cygnusx1.haus.com
|
||
Private System
|
||
Darrell Roberts
|
||
cygnusx1!root
|
||
214 495 9105
|
||
2330 Jamaica Place, Garland, Tx 75044
|
||
|
||
dalitc
|
||
DSC Communications, Richardson, Tx.
|
||
Brian Pellerin
|
||
dalitc!brian
|
||
214-234-3340
|
||
630 International Pwky., Richardson, Tx. 75081
|
||
|
||
dallastx
|
||
Individual
|
||
Pete Taliancich
|
||
dallastx!root
|
||
214 416 0022
|
||
7825 McCallum Blvd., #210, Dallas, TX 75252
|
||
|
||
dalnet, dalnet.lonestar.org
|
||
DalNet Unix BBS System
|
||
Victor Turner
|
||
dalnet!victor
|
||
214 484 7547
|
||
14025 Janwood, Farmers Branch, TX, 75234
|
||
|
||
dalsqnt
|
||
Sequent Computer Systems, Inc.
|
||
Chris Erickson
|
||
dalsqnt!chris
|
||
214 770 5915
|
||
14881 Quorum Drive, Dallas, TX 75240
|
||
|
||
damark
|
||
Damark Service Company
|
||
Jon Boede
|
||
damark!postmaster
|
||
512 339-9585
|
||
8006-F Cameron Road, Austin Texas, 78753
|
||
|
||
dcrt,dcrt.dla.mil
|
||
Defense Contract Management Region Dallas
|
||
Carolyn Gramm
|
||
dcrt!postmaster (postmaster@dcrt.dla.mil)
|
||
214 670 9365
|
||
DCMR DAL-Z, 1200 Main Street, Dallas, TX 75202-4399
|
||
NOTES:Component organization of the U. S. Defense Contract Management Command
|
||
|
||
dell, .dell.com
|
||
Dell Computer Corporation
|
||
Dewey Coffman
|
||
dell!usenet
|
||
512 338 4400
|
||
9505 Arboretum Blvd., Austin, TX 78759-7299, AR4
|
||
|
||
deutsch
|
||
The German Connection
|
||
Dieter Belletz
|
||
deutsch!sysop
|
||
512 532-4756
|
||
No physical address listed
|
||
NOTES:Public Electronic Message System
|
||
|
||
digi, digi.lonestar.org
|
||
DSC Communications, Plano Tx.
|
||
Keith Cantrell
|
||
digi!kcantrel
|
||
214-519-2399
|
||
1000 Colt, Plano, Tx 75075
|
||
|
||
dinosaur
|
||
Keith Cantrell
|
||
dinosaur!keith
|
||
214-492-1088
|
||
2100 Sonata Ln. Carrollton TX 75007
|
||
|
||
dkwgate
|
||
DKW Systems Corporation
|
||
JR Jesson
|
||
dkwgate!jr
|
||
214 746 5880
|
||
4050 Infomart, 1950 Stemmons Freeway, Dallas, TX 75207
|
||
|
||
dms3b1
|
||
Infotouch Systems, Inc.
|
||
Dave Hanna
|
||
dms3b1!dave
|
||
817 540-1524
|
||
3900 Cedar Ridge Dr., Suite 100, Bedford, TX 76021
|
||
|
||
dogface
|
||
Bob Izenberg
|
||
dogface!bei
|
||
512 346 7019
|
||
8535 Capitol of Texas Highway North, Austin, TX 78759
|
||
|
||
dogpnd
|
||
Dana Ebersole
|
||
tsci!dana
|
||
817 577 0367
|
||
3902 Butler Ct., Colleyville, TX 76034
|
||
|
||
donbaya
|
||
Private system
|
||
Taijan Wei
|
||
donbaya!postmaster, donbaya!tjw
|
||
817 387 2218
|
||
P.O. Box 22734 TWU, Denton, TX 76204
|
||
|
||
dp7up
|
||
Bill Harris
|
||
Dr. Pepper/Seven-Up Company
|
||
dp7up!bill
|
||
214-360-7000
|
||
8144 Walnut Hill Ln, Dallas Tx 75231
|
||
|
||
dptspd
|
||
Datapoint Corporation, Product Development
|
||
Lee Ziegenhals
|
||
postmaster@sat.datapoint.com
|
||
512 593 7670
|
||
9725 Datapoint Drive, San Antonio, TX 78229-8552
|
||
|
||
drig
|
||
Dallas Remote Imaging Group (Satellite Tracking & Imaging)
|
||
Jeff Wallach, Ph.D.
|
||
drig!jw
|
||
214 394 7325
|
||
4209 Meadowdale Dr., Carrollton, Tx. 75010
|
||
|
||
dungeon, dungeon.lonestar.org
|
||
-[MCP] Systems Inc.
|
||
Chert Pellett
|
||
dungeon!chert
|
||
214 301-9108
|
||
P.O. Box 850132 Richardson, Tx 75085-0132
|
||
|
||
dunsel
|
||
W. L. Kennedy Jr. and Associates
|
||
William (Bill) L. Kennedy Jr.
|
||
bill@ssbn.WLK.COM
|
||
512 535 4966
|
||
Box 63449 Bandera Falls, Pipe Creek, TX 78063-3449
|
||
|
||
dynsim1
|
||
Litwin Process Automation
|
||
Vic Rice
|
||
dynsim1!root
|
||
713 497 6200
|
||
580 Westlake Park Blvd., Houston, TX 77251-1281
|
||
|
||
eca
|
||
Electrocom Automation, Inc.
|
||
Robert Winter
|
||
eca!root
|
||
817 695 5321
|
||
2910 Ave. F, Arlington, TX 76011-5276
|
||
|
||
ecaard
|
||
ElectroCom Automation L.P.
|
||
Rus Duderstadt
|
||
ecaard!rad
|
||
817 695 7524
|
||
2910 Ave. F East, Arlington, TX 76011
|
||
|
||
ecor1
|
||
Home System
|
||
Tod D. Romo
|
||
ecor1!root
|
||
512 824 5121
|
||
318 Jeanette, San Antonio, TX 78216
|
||
|
||
edsr
|
||
EDS Advanced Research
|
||
Jimmy Niemann
|
||
edsr!jcn
|
||
214 661 6052
|
||
7223 Forest Lane, Dallas, TX 75230
|
||
|
||
eec, .austin.eds.com
|
||
Austin Laboratory; EDS Research
|
||
Rob Mayoff
|
||
mayoff@austin.eds.com, postmaster@austin.eds.com
|
||
512 477 1892
|
||
Austin Lab, EDS Research, 1601 Rio Grande Ste. 451, Austin, TX, 78701
|
||
|
||
egsner, egsner.cirr.com, cirr.com
|
||
Central Iowa (Model) Railroad
|
||
Eric Schnoebelen
|
||
egsner!postmaster, egsner!eric
|
||
214 250-6899
|
||
7825 McCallum Blvd, #406, Dallas, Tx 75252
|
||
|
||
elpc
|
||
Cam Fox
|
||
Electro Plate Circuitry
|
||
elpc!cam
|
||
214 466-0818
|
||
1430 Century - Dallas - Tx - 75006
|
||
|
||
els3
|
||
Equipment Listing Service
|
||
Buddy Hilliker
|
||
els3!root
|
||
512 341 4900
|
||
Isom Road, San Antonio, TX 78216
|
||
|
||
engcon
|
||
LTV Aerospace and Defense Company
|
||
Ben Rouse
|
||
engcon!root
|
||
214 266 7268
|
||
P.O.Box 655907, M/S WT-25, Dallas, TX 75265
|
||
|
||
enigma, enigma.haus.com
|
||
Harris Adacom Corporation
|
||
Clay Luther
|
||
cluther@enigma.haus.com
|
||
214 386 2356
|
||
P.O. Box 809022, Dallas, Tx 75380-9022
|
||
|
||
ernest
|
||
Texas Instruments
|
||
Alan Edmonds
|
||
ernest!postmaster
|
||
214 575 6427
|
||
P.O. Box 869305, MS 8513, Plano, TX, 75086
|
||
|
||
execu,execu.execu.com
|
||
Execucom Systems Corp
|
||
Dewey Henize
|
||
usenet@execu.com
|
||
512 327 7070
|
||
Two Wild Basin, 108 Wild Basin Road, Austin, Texas 78746
|
||
NOTES:Execucom Systems is a software company specializing in Decision
|
||
Support Systems and Executive Decision Systems. At any given time
|
||
there are likely to be a relatively wide range of machines at this
|
||
site, including a Sequent, Suns, DECs, HPs, and Primes.
|
||
|
||
exitech
|
||
Exitech
|
||
John J. McGrath
|
||
ext-adm!admin
|
||
409 245 9023
|
||
1904 Stonesthrow Drive, Bay City, TX 77414
|
||
|
||
ext-adm
|
||
Exitech
|
||
John McGrath
|
||
ext-adm!admin
|
||
409 245 9023
|
||
1904 Stonesthrow Drive, Bay City, TX 77414
|
||
|
||
fallout
|
||
DECUS DFW Local User Group
|
||
John Wisniewski
|
||
fallout!system
|
||
214 686 8107
|
||
3308 Rockne, Mesquite, TX 75150
|
||
|
||
fcknfst
|
||
Doug Davis
|
||
Doug Davis <letni!doug>
|
||
letni!doug
|
||
214 270 9226
|
||
4409 Sarazen / Mesquite / Tx / 77150
|
||
|
||
ferus
|
||
Private System
|
||
Alan J. Caldera
|
||
root@ferus.lonestar.org
|
||
817 294 2791
|
||
6062 Copperfield Dr. #842, Ft. Worth, TX 76132
|
||
|
||
ficc.ferranti.com
|
||
Ferranti International Controls Corporation
|
||
Peter da Silva
|
||
ficc!peter
|
||
713 274 5180
|
||
12808 West Airport Blvd./ Sugar Land TX 77487-5012
|
||
|
||
fl2
|
||
Ron McDowell
|
||
fl2!postmaster
|
||
512 655 3655
|
||
4418 Monaco, San Antonio, Texas 78218-4339
|
||
|
||
flatline
|
||
row major
|
||
J. Eric Townsend
|
||
jet@uh.edu
|
||
713 863 9137
|
||
511 Parker #2, Houston, Tx 77007
|
||
|
||
flattop, .progcons.com
|
||
Private Machine
|
||
Ron McDowell
|
||
flattop!postmaster
|
||
512 346 0138
|
||
9500 Jollyville Rd, #127, Austin, Texas 78759
|
||
|
||
foyinc
|
||
Foy Inc
|
||
James H. Foy
|
||
postmaster@foyinc.WLK.COM
|
||
214 782 7282
|
||
100 McKinney Street, Farmersville, Texas 75031
|
||
|
||
fozzy
|
||
Rockwell International
|
||
Dennis W. Fail
|
||
fozzy!fail
|
||
214 996 2471 (VOICE)
|
||
214 996 7768, 214 996 2412 (DIALUP)
|
||
1200 North Alma Road, M/S 448-100, Richardson, TX 75081
|
||
|
||
fquest
|
||
Public access BBS "Future Quest"
|
||
Kevin Basey
|
||
fquest!postmaster, fquest!kevin
|
||
512 834 9877
|
||
2018 West Rundberg #2a Austin, Tx. 78758
|
||
|
||
frontier, frontier.lonestar.org
|
||
Frontier Information Systems
|
||
Kevin Langston
|
||
frontier!postmaster
|
||
214 315 0942
|
||
2025 Frontier Trail, Lewisville, TX 75067
|
||
|
||
fubar
|
||
Private Machine
|
||
Damon Permezel
|
||
fubar!dap
|
||
512 371 3545
|
||
pobox 9068, austin, tx 78766-9068
|
||
|
||
furp, furp.lonestar.org
|
||
Strawberry Furp Suprise
|
||
Kurt Grutzmacher
|
||
furp!grutz
|
||
214 392 7312
|
||
13707 Rolling Hills Dallas, Tx. 75240
|
||
|
||
fuzzy, fuzzy.lonestar.org
|
||
Privately Owned
|
||
John Elliott IV
|
||
iv@fuzzy.lonestar.org
|
||
817 249 2147
|
||
1050 Cottonwood Trail; Benbrook, TX 76126-2734
|
||
|
||
gbdata
|
||
GB Data Systems
|
||
gbdata!root
|
||
713 363 3074
|
||
2427 Falls Church, Houston, Texas, 77067
|
||
|
||
gbm
|
||
General Business Machines
|
||
Cedric Reddick
|
||
gbm!root
|
||
713 984 8561
|
||
9610 Long Point, Suite 314, Houston, TX 77055
|
||
|
||
gdfwc3
|
||
General Dynamics, Fort Worth Division, C3 Systems
|
||
Todd Shutts
|
||
gdfwc3!todd
|
||
817 777 8168
|
||
General Dynamics Blvd., Fort Worth, TX 76108
|
||
|
||
gescorp1
|
||
Golden Era Services, Inc.
|
||
Stuart C. Cater
|
||
gescorp1!root
|
||
713 524 8881
|
||
2727 Allen Parkway, Suite 1900, Houston, TX 77019
|
||
|
||
global
|
||
Global Advantage
|
||
Gary Henderson
|
||
global!ghenderson
|
||
713 356 6043
|
||
1105 Meyer, P.O. Box 434, Seabrook, TX 77586
|
||
|
||
gtmvax
|
||
GTE Telemessager, GTE information services
|
||
Steve Linebarger,Floyd Ferguson
|
||
gtmvax!steve,gtmvax!floydf
|
||
214 929 7943, 214 929 7942
|
||
9150 Royal Lane, Suite 130, Irving, TX 75063
|
||
|
||
hackbox
|
||
Harmonix Incorporated
|
||
Jason Martin Levitt
|
||
hackbox!jason
|
||
512 326-9102
|
||
PO Box 3344, Austin, TX 78764
|
||
|
||
hal6000 hal6000.tandy.com
|
||
Tandy Systems Software
|
||
Frank Durda IV
|
||
hal6000.UUCP!uhclem
|
||
817 390 2865
|
||
1300 Two Tandy Center; Ft. Worth, TX 76102
|
||
|
||
halley
|
||
Tandem Computers
|
||
Brad Benton
|
||
Jack Bell
|
||
halley!postmaster
|
||
512 244 8000
|
||
14231 Tandem Blvd; Austin, Texas 78728
|
||
|
||
harlie
|
||
Private System
|
||
Mitch Mitchell
|
||
harlie!postmaster
|
||
214 248 8149, 214 519 3257
|
||
18330 Gallery Drive #723, Dallas, TX, 75252-5143
|
||
|
||
hdrock
|
||
Western Atlas International - CORE LABORATORIES
|
||
John Charles Welch
|
||
hdrock!john
|
||
214 566 1446
|
||
3230 GE Drive, Tyler, Tx, 75703
|
||
|
||
helps
|
||
Howard Electronics Laboratories, Products & Services
|
||
James Howard
|
||
helps!postmaster
|
||
512 329 8910
|
||
P. O. Box 160184, Austin, TX 78716-0184
|
||
|
||
hiplot
|
||
Houston Instrument, a division of Summagraphics, Inc.
|
||
Gary Powell
|
||
hiplot!postmaster
|
||
512 835 0900
|
||
8500 Cameron Road, Austin, TX 78753
|
||
|
||
hnb08
|
||
Eastman Christensen
|
||
Larry Flournoy
|
||
hnb08!root
|
||
713 985 3870
|
||
15355 Vantage Pkwy.,West, Houston, TX 77032
|
||
|
||
hounix
|
||
Houston Unix Users Group
|
||
Chuck Bentley
|
||
hounix!chuckb
|
||
713 827-8133
|
||
5644 Westheimer #222, Houston, TX 77056
|
||
|
||
hpaustx
|
||
Hewlett Packard - Austin Texas Office
|
||
Stuart Jarriel
|
||
hpaustx!stuart
|
||
512 338 7262
|
||
9050 Capitol of Texas Highway North, Suite 290, Austin TX 78759
|
||
|
||
hrnowl, hrnowl.lonestar.org
|
||
Horned Owl BBS
|
||
Paul Elliott
|
||
anwyn@hrnowl.lonestar.org
|
||
(713)781-4543
|
||
5857 South Gessner #224 Houston, texas 77036
|
||
|
||
hutto
|
||
Private Machine
|
||
Henry Melton
|
||
hutto!henry
|
||
512 846 3241
|
||
Route 1 Box 274E, Hutto Texas 78643-9751
|
||
|
||
ibes
|
||
IBES Corp.
|
||
Tim Anderson
|
||
ibes!ta
|
||
214 907 8475
|
||
1201 Richardson Dr. Richardson, TX 75080
|
||
|
||
ibnet214
|
||
Information Brokerage Network
|
||
David Woods
|
||
ibnet214!root
|
||
214 733 0466
|
||
P.O. Box 796514, Dallas, TX 75379
|
||
|
||
icus, .ICUS.COM
|
||
ICUS Software Systems [Development Center I]
|
||
Leonard B. Tropiano
|
||
icus!lenny, icus!postmaster, postmaster@icus.ICUS.COM
|
||
14300 Tandem Blvd #222, Austin, TX 78728
|
||
|
||
icusdvlp, icusdvlp.ICUS.COM
|
||
ICUS Software Systems [Development Center II]
|
||
Leonard B. Tropiano
|
||
icus!lenny, icus!postmaster, postmaster@icus.ICUS.COM
|
||
14300 Tandem Blvd #222, Austin, TX 78728
|
||
|
||
iex
|
||
IEX Corporation
|
||
Bob Blencowe, Robert Brazile
|
||
iex!postmaster
|
||
214 612-2600
|
||
1400 Preston Road, Suite 350, Plano, Texas 75093
|
||
|
||
ijcr
|
||
Institute Of Judaic-Christian Research
|
||
John R. Hill
|
||
hill@ijcr.merch.tandy.com
|
||
817 346 1247
|
||
P.O. Box 331564 Fort Worth, Texas 76163
|
||
|
||
imsl
|
||
Individual
|
||
Edward B. Herrera
|
||
imsl!herrera
|
||
713 782 6060
|
||
2500 Parkwest Blvd., Houston, TX 77042
|
||
|
||
inebriae
|
||
Tel-Account, Inc.
|
||
Lawrence M. Wesson, C.P.A.
|
||
postmaster@inebriae.WLK.COM
|
||
214 788-2582
|
||
12740 Hillcrest #107 Dallas, TX 75230
|
||
|
||
infohub
|
||
Radio Shack Computer Merchandising
|
||
G. David Butler, II
|
||
root@infohub.TANDY.COM
|
||
817 457 4043
|
||
1500 One Tandy Center, Ft Worth, TX, 76102
|
||
|
||
iphase
|
||
Interphase Corporation
|
||
Larry Hale
|
||
iphase!lsh
|
||
214 919 9204
|
||
13800 Senlac, Dallas, TX 75234
|
||
|
||
iquery
|
||
Programmed Intelligence Corp.
|
||
Matthew C. Reedy
|
||
postmaster@pic.com, iquery!postmaster
|
||
512 490 6684
|
||
400 N Loop 1604 E, Ste 100, San Antonio, TX 78232
|
||
|
||
issi
|
||
International Software Systems, Inc
|
||
Lisa A. Gerlich
|
||
issi!postmaster
|
||
512 338 5724
|
||
9430 Research Blvd, Suite 250, Austin, TX 78759
|
||
|
||
itcdal
|
||
Integral Technology Corporation
|
||
Doug Workings
|
||
itcdal!root
|
||
214 690 2770
|
||
2201 Waterview Parkway, Suite 1703, Richardson, TX 75080
|
||
|
||
jantor
|
||
Microlink Inc.
|
||
Herb Crosby
|
||
jantor!postmaster
|
||
713 338-2010
|
||
403 Nasa Rd. 1 E. Bx 349, Webster, TX 77598
|
||
|
||
jassys
|
||
private system
|
||
Tony Holden
|
||
jassys!news,jassys!tony
|
||
817 280-0282
|
||
729 Briarwood, Hurst, Tx. 76053
|
||
|
||
jcpenne
|
||
JC Penney Company Inc.
|
||
Robert J. Davis
|
||
jcpenne!rjdavis2
|
||
214 387 6156
|
||
12712 Park Central Place, Dallas, TX 75251
|
||
|
||
jkh0
|
||
John Kay Harris and Associates
|
||
John Harris
|
||
jkh0!root
|
||
713 667 1781
|
||
5650 Kirby, Suite 150, Houston, TX 77005
|
||
|
||
jmdst
|
||
Home System
|
||
Joe M. Doss
|
||
jmdst!postmaster
|
||
817 468 8932
|
||
904 Tennis Villa Drive, Arlington, TX, 76017
|
||
|
||
joshua, joshua.lonestar.org
|
||
Contract Programming in FoxBase+
|
||
Bill Harris
|
||
joshua!bill
|
||
214-424-1030 (DIALUP) 214-424-7626 (VOICE)
|
||
3396 Ave P, Plano, Texas 75074
|
||
|
||
k5qwb
|
||
Amatuer Radio Station k5qwb
|
||
Lyn R. Kennedy
|
||
k5qwb!lrk
|
||
214 217 0212
|
||
P. O. Box 5133, Ovilla, TX 75154
|
||
|
||
kawhou
|
||
Kurt A. Welgehausen
|
||
Kurt A. Welgehausen
|
||
kawhou!root
|
||
713 528 7132
|
||
P.O. Box 270835, Houston, TX 77277-0835
|
||
|
||
keys
|
||
Christopher L. Winemiller (personal system)
|
||
Chris Winemiller
|
||
keys!postmaster
|
||
214 393 0850, 214 519 3451
|
||
328 Plantation Drive, Coppell, TX USA 75019-3213
|
||
|
||
kf5iw
|
||
Honda Sport Touring Association
|
||
Jim Blocker
|
||
kf5iw!jim
|
||
214 996 6875
|
||
2524 Sundance Lane, Dallas, TX 75287-5871
|
||
|
||
khijol
|
||
Assault Weapons 'R Us
|
||
Ed Carp
|
||
khijol!erc
|
||
512 445 2044
|
||
1800 E. Stassney #1205, Austin, TX 78744
|
||
NOTES:khijol means "Beam me up!" in Klingon
|
||
|
||
kvue
|
||
KVUE-TV
|
||
Edward Sparks
|
||
sparks@kvue.UUCP
|
||
512 459 6521
|
||
PO Box 9927, Austin, TX 78766
|
||
|
||
laczko, laczko.ti.com
|
||
Private system
|
||
Frank L. Laczko, Sr
|
||
postmaster@laczko.ti.com
|
||
214 997 3988
|
||
P.O. Box 867676 Plano TX 75086
|
||
|
||
lad-shrike
|
||
Lockheed Missles & Space Co., Austin Division
|
||
David Capshaw
|
||
lad-shrike!usenet
|
||
512 448 5757
|
||
O/96-10 B/30E, 6800 Burleson Road, Austin, Texas 78744
|
||
|
||
lark
|
||
Lark Sequencing Technologies, Ltd.
|
||
Charlie Lawrence
|
||
713 798 6226
|
||
chas@mbir.bcm.tmc.edu
|
||
Medical Towers Building, Texas Medical Center, Houston, Tx 77030
|
||
|
||
lcra
|
||
Lower Colorado River Authority
|
||
Mike O'Donnell
|
||
lcra!postmaster
|
||
512 473-4058
|
||
3001 Lake Austin Blvd, #201, Austin, TX 78703
|
||
|
||
learjet
|
||
personal
|
||
Faisal Awada
|
||
learjet!postmaster
|
||
512 339 0961
|
||
3220 Duval Rd #1606, Austin, TX 78759
|
||
|
||
lerami, lerami.lonestar.org, lerami.cirr.com
|
||
Private System
|
||
Larry Rosenman
|
||
lerami!postmaster
|
||
214 399 0210
|
||
900 Lake Isle Circle, Irving, Texas 75060-7709
|
||
|
||
lescsse
|
||
Lockheed Engineering and Sciences Co.
|
||
Gary Morris
|
||
lobster!lescsse!postmaster
|
||
713 283 5195
|
||
1150 Gemini Avenue A-22, Houston, TX 77058
|
||
|
||
letni, letni.lonestar.org, .lonestar.org
|
||
Private System
|
||
Doug Davis
|
||
doug@letni.lonestar.org
|
||
214-908-2522
|
||
4409 Sarazen Mesquite Tx 75150
|
||
|
||
leviathn
|
||
Personal Machine
|
||
Adrian J. Hardesty
|
||
leviathn!adrian
|
||
713 862 1398
|
||
1134 Dorothy, Houston, TX 77008
|
||
|
||
lgc, .lgc.com
|
||
Landmark Graphics
|
||
Chris Martin
|
||
uucp@lgc.com
|
||
713 579 4891
|
||
333 Cypress Run, Suite 100, Houston, TX 77094
|
||
|
||
lib
|
||
The Texas Medical Center
|
||
Stan Barber
|
||
postmaster@tmc.edu, sob@bcm.tmc.edu
|
||
713 798 6042
|
||
Baylor College of Medicine, One Baylor Plaza, Houston, Texas 77030
|
||
NOTES:lib is a mail portal between THEnet and the internet
|
||
|
||
limbic
|
||
Southwest Systems Development Labs (Division of ICUS)
|
||
Gilbert C. Kloepfer, Jr.
|
||
gil@limbic.ssdl.com
|
||
8622 Maplecrest, Houston, TX 77099
|
||
|
||
lobster
|
||
Private System
|
||
Judy Scheltema
|
||
judy@lobster.hou.tx.us
|
||
8622 Maplecrest, Houston, TX 77099
|
||
|
||
lodestar
|
||
Lodestar Systems Inc.
|
||
Clifton M. Bean, Murry E. Page
|
||
lodestar!root
|
||
214 845 8245
|
||
14651 Dallas Parkway Suite 700 Dallas TX 75240
|
||
|
||
longway, .tic.com
|
||
Texas Internet Consulting
|
||
Smoot Carl-Mitchell, John S. Quarterman
|
||
postmaster@longway.tic.com
|
||
512-320-9031
|
||
701 Brazos Suite 500, Austin, TX 78701-3243
|
||
|
||
lotex
|
||
Chuck Bentley
|
||
lotex!chuckb
|
||
713 789 8928
|
||
5644 Westheimer #222, Houston, TX 77056
|
||
|
||
loyola
|
||
Comstock Connections
|
||
Jack L Bell
|
||
loyola!jack
|
||
512 928 8706
|
||
3103 Loyola Lane, Austin, TX 78723
|
||
|
||
lsg
|
||
The LAN Support Group, Inc.
|
||
Eric Pulaski
|
||
lsg!epulaski
|
||
713 621 9166
|
||
520 Post Oak Blvd., Suite 100, Houston, TX 77027
|
||
|
||
lwb
|
||
Univ. of Texas at Arlington, Dept. of Foreign Languages and Linguistics
|
||
Bob Mugele
|
||
lwb!root
|
||
817 273 3695
|
||
Box 19557, UTA, Arlington, Texas 76019
|
||
|
||
martian
|
||
Commodore-AMIGA 2000HD; AmigaDos 1.3.2, Amiga-UUCP V1.05D(0.40W/0.60W)
|
||
Robert J. Zepeda
|
||
Robert J. Zepeda
|
||
martian!rjz
|
||
512 794 8219
|
||
9500 Jollyville Road Apt. 197 ; Austin, Tx 78759
|
||
|
||
mavrick
|
||
Private System
|
||
Luis Basto
|
||
mavrick!luis
|
||
512 255 8350
|
||
12707 Poquoson Dr., Austin, TX 78727
|
||
|
||
maxwell
|
||
Southwest Research Institute
|
||
Keith S. Pickens
|
||
maxwell!postmaster
|
||
512 684 5111
|
||
6220 Culebra Road, San Antonio, Texas 78284
|
||
|
||
mbir
|
||
Molecular Biology Information Resource, Baylor College of Medicine
|
||
Charlie Lawrence
|
||
713 798 6226
|
||
chas@mbir.bcm.tmc.edu
|
||
Department of Cell Biology, Baylor College of Medicine,
|
||
One Baylor Plaza, Houston, Texas 77030
|
||
|
||
mcomp
|
||
Micro-Comp Consulting
|
||
William B. Dow
|
||
mcomp!bill
|
||
214 306 3165 214 306 1596
|
||
3309 Sam Rayburn Run, Carrollton, Tx, 75007
|
||
|
||
mcreate
|
||
MicroCreations
|
||
Darin Arrick
|
||
mcreate!darin
|
||
817 281 0612
|
||
P.O. Box 820054, North Richland Hills, TX, 76182
|
||
|
||
mdaeng,.mdaeng.com
|
||
MDA Engineering Inc.
|
||
Ralph W. Noack
|
||
mdaeng!postmaster
|
||
817 860 6660
|
||
500 E. Border St. Suite 401 Arlington Tx 76013
|
||
|
||
meddle
|
||
Discovery Hall Hands On Science Museum
|
||
Dennis Little
|
||
meddle!root
|
||
512 474 7616
|
||
401 Congress, Austin, TX 78752
|
||
|
||
memqa
|
||
Motorola Mos Memory R&QA
|
||
Henry Melton
|
||
memqa!postmaster
|
||
512 928 6328
|
||
3501 Ed Bluestein Blvd, Austin Texas
|
||
|
||
merch
|
||
Radio Shack Computer Merchandising
|
||
G. David Butler, II
|
||
root@merch.tandy.com
|
||
817 457 4043
|
||
1500 One Tandy Center, Ft Worth, TX, 76102
|
||
|
||
mercy
|
||
Mercy Medical Equipment Company
|
||
Ron McDowell
|
||
fl2!postmaster
|
||
512 655 3716
|
||
8527 Village Dr. #103, San Antonio, Texas 78217
|
||
|
||
mic
|
||
RGL Consulting
|
||
Richman G. Lewin
|
||
gary@mic.lonestar.org
|
||
214 278-4074
|
||
P.O.Box 2010, Dallas, Tx, 75221-2010
|
||
|
||
micrtk
|
||
Microtek Microbiology
|
||
Raymond C. Schafer
|
||
micrtk!postmaster
|
||
512 441 1066
|
||
5004 Emerald Forest Circle, Austin, TX 78745
|
||
|
||
milano
|
||
MCC Software Technology Program
|
||
Charles Sandel,Jim Knutson
|
||
milano!usenet,sandel@mcc.com,knutson@milano.uucp
|
||
512 338 3498, 512 338 3362
|
||
9390 Research Blvd. Austin, TX 78759
|
||
|
||
mitek, mitek.com, sequent.mitek.com, .mitek.com
|
||
Mitek Open Connect Systems
|
||
David M. Lyle
|
||
mitek!postmaster
|
||
214 490 4090
|
||
2033 Chennault Drive; Carrollton, Tx 75006
|
||
|
||
mizarvme
|
||
Mizar, Inc.
|
||
mizarvme!usenet
|
||
214 446 2664
|
||
1419 Dunn Drive, Carrollton, TX 75006
|
||
|
||
montagar
|
||
Privately Owned and Operated
|
||
David L. Cathey
|
||
montagar!system
|
||
214 618-2117
|
||
6400 Independence #601, Plano, TX 75023
|
||
|
||
motaus
|
||
Motorola Inc., Semiconductor Products Sector
|
||
Phil Brownfield
|
||
motaus!postmaster
|
||
512 873 2022
|
||
11120 Metric Blvd., Austin, TX 78758 USA
|
||
|
||
moxie, moxie.hou.tx.us
|
||
Greg Hackney
|
||
hack@moxie.hou.tx.us
|
||
713+351-2125
|
||
P.O. Box 1173, Tomball, Texas 77377-1173
|
||
|
||
mwi
|
||
Mueller & Wilson, Inc.
|
||
Ron C. Wilson
|
||
mwi!ron
|
||
512 824 9461
|
||
P.O. Box 17659, San Antonio, TX 78217
|
||
|
||
mwk
|
||
M. W. Kellogg
|
||
Lee K. Gleason
|
||
mwk!postmaster
|
||
713 753 4455
|
||
601 Jefferson, Houston, TX 77210
|
||
|
||
n5lyt,n5lyt.boerne.tx.us
|
||
Amateur radio station n5lyt
|
||
Lee Ziegenhals
|
||
n5lyt!postmaster
|
||
512 699 5670
|
||
P.O. Box 815, Boerne, TX 78006
|
||
|
||
natinst
|
||
National Instruments Corporation
|
||
Brian H. Powell
|
||
natinst!postmaster
|
||
512 794 5506
|
||
6504 Bridge Point Parkway, Austin, Texas 78730-5039
|
||
|
||
ncmicro, ncmicro.lonestar.org
|
||
NC Microproducts, Inc., Development/Field Support
|
||
Lance Franklin
|
||
postmaster@ncmicro.lonestar.org
|
||
214-234-6655
|
||
2323 N. Central Expressway, Suite 380, Richardson, Tx, 75080
|
||
|
||
necbsd
|
||
NEC America
|
||
Ying-Da Lee
|
||
necbsd!ylee
|
||
214 518 5000
|
||
1525 Walnut Hill Lane, Irving, TX 75038
|
||
|
||
nemesis, nemesis.lonestar.org
|
||
Privately Owned
|
||
Frank Durda IV
|
||
uhclem@nemesis.lonestar.org
|
||
817 292 2270
|
||
5951 Ashford Ct; Fort Worth, TX 76133-3013
|
||
|
||
netdev, .comsys.com
|
||
Communication Systems Research
|
||
Alex Huppenthal
|
||
netdev!alex
|
||
214 250-3807
|
||
6045 Buffridge Trail, Dallas, TX 75252
|
||
|
||
nidhog, nidhog.cactus.org
|
||
CACTUS (Capitol Area Central Texas UNIX Society)
|
||
Henry D. Reynolds(hdr)
|
||
nidhog!hdr
|
||
512 448 3617(VOICE)
|
||
1718 Valeria Austin, TX 78704
|
||
|
||
ninja
|
||
db Systems
|
||
G. David Butler, II
|
||
root@ninja.UUCP
|
||
817 457 4043
|
||
6940 Misty Glen Court, Ft Worth, TX, 76112
|
||
|
||
nominil
|
||
Lonesome Dove Computing Services
|
||
Mark C. Linimon
|
||
usenet@nominil.lonestar.org
|
||
512 218 0805
|
||
14300 Tandem Boulevard #239, Austin, TX 78728
|
||
|
||
nowhere
|
||
Software Solutions
|
||
Steven King
|
||
nowhere!sking
|
||
512 339 8642
|
||
1615 A West Braker Ln, Austin, Tx, 78758
|
||
|
||
npqc
|
||
Tandy National Parts, Quality Control Department
|
||
Keith Ward
|
||
npqc!qcdev!root
|
||
817 870 5650
|
||
900 E. Northside Dr., Fort Worth, TX 76102
|
||
|
||
nthropy
|
||
Nth Graphics, Ltd.
|
||
Andy Lowe
|
||
nthropy!postmaster
|
||
512 832 1944
|
||
1807-C W. Braker Ln., Austin, TX 78758
|
||
|
||
ntpal
|
||
Bell Northern Research, Inc.
|
||
Dana Cavasso
|
||
ntpal!dcavasso, ntpal!postmaster
|
||
214 301-2664
|
||
2435 N. Central Expressway, Richardson, TX 75080
|
||
|
||
nuchat
|
||
South Coast Computing Services, Inc.
|
||
Steve Nuchia
|
||
nuchat!postmaster
|
||
713 964 2462
|
||
POB 270249 Houston, Texas 77277-0249
|
||
|
||
nuke, nuke.conmicro.com
|
||
Private System
|
||
Ron Harter
|
||
postmaster@nuke.conmicro.com
|
||
713 334 2023
|
||
3007 Twinleaf, League City, TX 77573
|
||
|
||
oakhill
|
||
Motorola
|
||
Ed Rupp
|
||
ed@oakhill.sps.mot.com
|
||
512 891-2224
|
||
Motorola Inc., Mail Drop OE37, 6501 William Cannon Dr. West,
|
||
Austin, TX 78735-8598
|
||
|
||
obiwan
|
||
Privately owned
|
||
Bob Willcox
|
||
obiwan!bob
|
||
512 258 4224, 512 331 0865
|
||
11209 Della Torre Drive, Austin, TX 78750
|
||
|
||
ohdoor
|
||
Overhead Door Corp.
|
||
Steven Forrester
|
||
ohdoor!steve
|
||
214 556-2726
|
||
1910 Crown Dr., Farmers Branch, Tx, 75234
|
||
|
||
omnicomp
|
||
Omnicomp Graphics Corporation
|
||
H. H. Parker
|
||
omnicomp!root
|
||
713 464 2990
|
||
1734 West Belt North, Houston, TX 77043
|
||
|
||
osgiliath
|
||
Personal
|
||
Marc St.-Gil
|
||
osgiliath!marc
|
||
214 250 3014
|
||
4912 Haverwood Lane #913, Dallas, Tx 75287
|
||
|
||
ozdaltx
|
||
Robert Scott, XENIX systems Consultant/OZ BBS
|
||
Robert Scott
|
||
ozdaltx!root
|
||
214 247-5609, 214 247-2367
|
||
No physical address known
|
||
|
||
palace
|
||
The Palace BBS
|
||
Barry Dunlap
|
||
palace!root
|
||
713 488 2721 (VOICE) 713 280 9116 (DIALUP)
|
||
15102 Penn Hills, Houston, TX 77062
|
||
|
||
para1
|
||
Paranet
|
||
Richard L. Sonnier III
|
||
para1!root
|
||
713 467 3100
|
||
1743 Stebbins Dr, Houston, TX 77043
|
||
|
||
pcinews
|
||
Publications & Communications, Inc.
|
||
Bill Lifland
|
||
pcinews!wdl
|
||
512 250 9023
|
||
12416 Hymeadow Dr., Austin, Texas 78750-1896
|
||
|
||
pemrac
|
||
Southwest Research Institute
|
||
Richard Murphy
|
||
pemrac!karen, karen@pemrac.space.swri.edu
|
||
512 522 5322
|
||
6220 Culebra Rd., San Antonio, TX 78284
|
||
|
||
pensoft
|
||
Pencom Software Inc.
|
||
David Bryant, Mike Heath, Lorne Wilson
|
||
pensoft!postmaster
|
||
512 343 1111
|
||
9050 Capitol of Texas Hwy North, Austin TX, 78759
|
||
|
||
petro
|
||
G.M. Andreen & Associates, Inc.
|
||
Gilbert B. Andreen
|
||
petro!postmaster
|
||
512 826 1733
|
||
235 Rockhill Dr. San Antonio, Texas 78209
|
||
|
||
peyote
|
||
Capital Area Central Texas Unix Society
|
||
Jim Knutson,Charles Sandel
|
||
peyote!postmaster
|
||
512 338 3362, 512 338 3498
|
||
9390 Research Blvd., Austin, TX 78759
|
||
|
||
pisces, pisces.lonestar.org
|
||
Privately owned system
|
||
David Aldrich
|
||
dga@pisces
|
||
817 267 9587
|
||
13709 West Rim Dr. #807 Euless Texas USA 76040
|
||
|
||
piziali
|
||
Pizialis
|
||
Andrew J. Piziali
|
||
piziali!postmaster
|
||
214 442 7483
|
||
6616 Estados Drive, Parker, Texas 75002-6800
|
||
|
||
pojen
|
||
MicroAge
|
||
Jimmy Ko
|
||
pojen!root
|
||
214 348 1523
|
||
11601 Plano Rd. #108, Dallas, TX 75243
|
||
|
||
ponder
|
||
University of North Texas, Computer Science Department
|
||
Johnny Carroll
|
||
ponder!carroll
|
||
817 565 2279
|
||
PO Box 13886 Denton, Texas 76203
|
||
|
||
procon
|
||
Pro Consultants, Inc.
|
||
Monte Daily, Rick San Soucie
|
||
procon!monte,procon!rick
|
||
214 637 7710
|
||
1230 River Bend Drive #215 Dallas, TX 75247
|
||
|
||
prosoft
|
||
Prosoft, Inc.
|
||
Jim Holmes
|
||
prosoft!postmaster
|
||
512 836 6328
|
||
2011 Rutland Drive, Austin Texas, 78758
|
||
|
||
qcdev
|
||
Tandy National Parts, Quality Control Department
|
||
Keith Ward
|
||
qcdev!root
|
||
817 870 5650
|
||
900 E. Northside Dr., Fort Worth, TX 76102
|
||
|
||
qtdallas
|
||
Quickturn Systems Inc.
|
||
Dasha Estes
|
||
qtdalllas!root
|
||
214 516 3838
|
||
101 E. Park Blvd, Suite 600, Plano, TX 75045
|
||
|
||
radar.aca.mcc.com
|
||
MCC; ACT Program
|
||
Beth Paxton
|
||
postmaster@radar.aca.mcc.com
|
||
512 338 3494
|
||
MCC / ACT Program; 3500 W. Balcones Center Dr.; Austin, Tx 78759
|
||
|
||
rancor
|
||
IBM Advanced Workstations Division (AWD)
|
||
Bob Willcox
|
||
rancor!bob
|
||
512 258 4224, 512 331 0153
|
||
11209 Della Torre Drive, Austin, TX 78750
|
||
|
||
ray
|
||
Raymond Schafer Associates
|
||
Raymond C. Schafer
|
||
ray!postmaster
|
||
512 441 1066
|
||
5004 Emerald Forest Circle, Austin, TX 78745
|
||
|
||
rcc1
|
||
Realistic Computing Company
|
||
Richard C. McIntosh Jr.
|
||
rcc1!rcmjr
|
||
214 528 4071 (Voice)
|
||
4524 McKinney Ave. Suite 104, Dallas, Texas 75205
|
||
|
||
rdsoftwr
|
||
Robert M. Dunaway
|
||
Robert M. Dunaway
|
||
rdsoftwr!bob
|
||
214 252 3745
|
||
3541 Esplendor Avenue, Irving, TX 75062
|
||
|
||
redsim
|
||
Hughes Simulation Systems Inc. (formerly Rediffusion Simulation Inc.)
|
||
Ronald B. Adams
|
||
redsim!postmaster , postmaster@redsim.lonestar.org
|
||
817 695 2270
|
||
2200 Arlington Downs Road, Arlington, TX 76011-6382
|
||
|
||
rei2
|
||
Recognition Equipment, Incorporated
|
||
Mike Grabert
|
||
rei2!mike
|
||
214 579 6171
|
||
P.O. Box 660204, Dallas, Texas 75266-0204
|
||
|
||
rice
|
||
Rice University, Houston, TX
|
||
Evan Wetstone
|
||
postmaster@rice.edu
|
||
713-527-8101
|
||
Neworking & Computer Systems, P.O. Box 1892, Houston, Tx 77251
|
||
|
||
rmc,rmc.liant.com
|
||
Ryan McFarland Corporation
|
||
Tom Grubbs
|
||
rmc!trg
|
||
512 343 1010
|
||
8911 Capital of Texas Highway North, Austin, Texas 78759
|
||
|
||
romp
|
||
IBM Advanced Workstations Division
|
||
Bob Willcox
|
||
romp!bob
|
||
512 838 3585
|
||
4B-76/803, 11400 Burnet RD, Austin, TX 78758
|
||
|
||
ross
|
||
ROSS Technology, Inc.
|
||
Carl Dobbs
|
||
ross!postmaster
|
||
512 448 8968
|
||
7748 Hwy. 290 West, Austin TX 78736
|
||
|
||
rover
|
||
DPI Workplace
|
||
Dennis W. Wimer
|
||
rover!dwimer
|
||
817 281 4562
|
||
6130 Glenview Drive, #110, N. Richland Hills, TX 76180
|
||
|
||
rpp386, rpp386.cactus.org, rpp68k
|
||
D/B/A River Parishes Programming
|
||
John F. Haugh II
|
||
rpp386!jfh
|
||
512-pri-vate
|
||
No Known Address
|
||
|
||
rrbible
|
||
Personal System
|
||
Bryan Bible
|
||
rrbible!btb
|
||
512 255 2258
|
||
313 Rawhide Loop, Round Rock TX 78681
|
||
|
||
rrm
|
||
Martin Computer Services
|
||
Richard R. Martin
|
||
rrm!postmaster
|
||
214 647 4145
|
||
634 Dallas Avenue, Grand Prairie, TX 75050
|
||
|
||
rtc
|
||
Reed Tool Company
|
||
Richard Herdell
|
||
rtc!root
|
||
713 924 5521
|
||
6501 Navigation, Houston, TX 77011
|
||
|
||
rtjpc
|
||
Tom Jacob
|
||
Tom Jacob
|
||
rtjpc!jacob
|
||
214 528 6733
|
||
4306 Emerson Avenue, Dallas, TX 75205
|
||
|
||
rwsys, rwsys.lonestar.org
|
||
R/W Systems - Fine purveyors of custom computation and control
|
||
James X. Wyatt
|
||
rwsys!jim, rwsys!root, rwsys!uucpmgr
|
||
817 595 0571
|
||
3529 Ruth Road, Ste: 2121, Richland Hills, Tx 76118-5849
|
||
|
||
satcom
|
||
Iguana Binary Systems
|
||
David Kuykendall
|
||
satcom!root
|
||
512 558 3826
|
||
4115 Goshen Pass, San Antonio, TX 78230
|
||
|
||
sawdust, .n382.z1.fidonet.org
|
||
June Parchman
|
||
sawdust!jip
|
||
1401 E. Rundberg Ln. #50, Austin, TX 78753
|
||
|
||
scisoft
|
||
Scientific Software Intercomp
|
||
Doug Scogman
|
||
scisoft!root
|
||
713 953 8702
|
||
10333 Richmond Ave., Suite 1000 Houston, TX 77042
|
||
|
||
scorpio
|
||
Micro Engineering Co.
|
||
Donald A. Ninke, P.E.
|
||
!scorpio!ninke
|
||
512 926 7520
|
||
2307 Lehigh Drive, Austin, TX 78723
|
||
|
||
sctc-1
|
||
Air Force Advanced Systems SC (SMSCRC Users Group coordinator)
|
||
Milton J. Turner Jr., Unix Systems Analyst (512) 652-UNIX (8649)
|
||
sctc-1!milt
|
||
512 652 3098
|
||
San Antonio, Texas Metropolitan Area
|
||
|
||
sentinel
|
||
W. L. Kennedy Jr. and Associates
|
||
William (Bill) L. Kennedy Jr.
|
||
bill@ssbn.WLK.COM
|
||
512 535 4966
|
||
Box 63449 Bandera Falls, Pipe Creek, TX 78063-3449
|
||
|
||
sequoia,sequoia.execu.com
|
||
Execucom Systems Corp
|
||
Dewey Henize
|
||
usenet@execu.com
|
||
512 327 7070
|
||
Two Wild Basin, 108 Wild Basin Road, Austin, Texas 78746
|
||
|
||
sessun
|
||
SES, Inc.
|
||
John Osborn
|
||
sessun!root
|
||
512 474 4526
|
||
1301 W. 25th St., Austin, TX 78705
|
||
|
||
shared
|
||
Shared Financial Systems
|
||
D.H. Close
|
||
shared!davec
|
||
214 233 8356
|
||
15301 Dallas Parkway, #600, Dallas, TX 75248
|
||
|
||
shell,.shell.com
|
||
Shell Oil Co.
|
||
Susan Dang, Barry Myers
|
||
postmaster@shell.com
|
||
713 795 3208, 713 795 3287
|
||
Shell Information Center, 1500 OST, Houston, TX 77054
|
||
|
||
shibaya
|
||
Private system
|
||
Augustine Cano
|
||
shibaya!postmaster, shibaya!afc
|
||
817 382 0211
|
||
P.O. Box 2382, Denton, TX 76202
|
||
|
||
siswat
|
||
Photon Graphics, Inc.
|
||
A. Lester Buck
|
||
siswat!usenet
|
||
713 665 2258
|
||
3618 Glen Haven, Houston, TX 77025
|
||
|
||
skeeter
|
||
Privately Owned
|
||
Robert Wallace
|
||
tnessd!mechrw
|
||
214 464 6552
|
||
Dallas, Texas
|
||
|
||
smu
|
||
Southern Methodist University, Dept of Computer Science and Engineering
|
||
Bob Mazanec
|
||
smu!manager
|
||
214 692-2859, 214 692-3080
|
||
Department of Computer Science and Engineering, Dallas, TX 75275
|
||
|
||
smubic
|
||
Southern Methodist University
|
||
R. Allen Gwinn, Jr.
|
||
sulaco!allen
|
||
|
||
smunews
|
||
Department of Electical Engineering; S.M.U.
|
||
Dr. James George Dunham
|
||
smunews!jgd
|
||
214 692-2812
|
||
Dallas, TX 75275
|
||
|
||
smx
|
||
Individual
|
||
Steve Musacchia
|
||
smx!root
|
||
713 984 9600
|
||
1640 Sul Ross Houston, TX 77006
|
||
|
||
sneaky
|
||
Gordon L. Burditt
|
||
Gordon L. Burditt
|
||
gordon@sneaky.lonestar.org
|
||
817 249 4898 (Voice: evenings only!)
|
||
1206 Duane, #2121, Benbrook, TX 76126
|
||
|
||
snoc
|
||
Hackercorp
|
||
Karl Lehenbauer
|
||
sugar!karl, sugar!usenet
|
||
713 438 4964
|
||
3918 Panorama, Missouri City, TX 77099
|
||
|
||
solo, solo.csci.unt.edu
|
||
University of North Texas, Computer Science Department
|
||
Johnny Carroll
|
||
solo!root
|
||
817 565 2279
|
||
PO Box 13886 Denton, Texas 76203
|
||
|
||
soma
|
||
Division of Neuroscience, Baylor College of Medicine
|
||
Mahmud Haque
|
||
postmaster@soma.bcm.tmc.edu, mahmud@soma.bcm.tmc.edu
|
||
713 789 5985
|
||
Division of Neuroscience, Baylor College of Medicine,
|
||
One Baylor Plaza, Houston, Texas 77030
|
||
|
||
sooner
|
||
Dewey Coffman
|
||
sooner!dewey
|
||
512 452 7354
|
||
5907 Cary Dr, Austin, Texas 78759-3109
|
||
|
||
spdyne, spdyne.lonestar.org
|
||
Spectradyne, Inc.
|
||
Chert Pellett
|
||
spdyne!chert
|
||
214 301-9108
|
||
1501 Plano Road, Richardson, Tx. 75085
|
||
|
||
splut, .conmicro.com
|
||
Confederate Microsystems
|
||
Jay Maynard
|
||
postmaster@splut.conmicro.com
|
||
+1 713 332 3376
|
||
6027 Leafwood Circle, League City, TX 77573
|
||
|
||
ssbn, .wlk.com
|
||
W.L. Kennedy Jr. & Associates
|
||
William L. Kennedy, Jr. (Bill)
|
||
bill@ssbn.WLK.COM
|
||
512 535 4966
|
||
Box 63449 Bandera Falls, Pipe Creek, TX 78063-3449
|
||
|
||
ssi600
|
||
Seay Systems, Inc.
|
||
Vernon E. Hurdle
|
||
vernon@ssi600.lonestar.org
|
||
214 522-2324
|
||
5327 N. Central Expressway, Suite 320, Dallas, TX 75205
|
||
|
||
starlite
|
||
Personal
|
||
Eric C. Rosen
|
||
starlite!postmaster, uunet!cs.utexas.edu!rosen
|
||
512 346 6543
|
||
No Physcal address known
|
||
|
||
starsoft
|
||
The Starbound Software Group, a part of Starbound Enterprises
|
||
David W. Lowrey
|
||
postmaster@starsoft
|
||
713 894 7447
|
||
12519 Lusterleaf Dr., Cypress, TX. 77429
|
||
|
||
starweb
|
||
EarthScan Systems
|
||
Jose A. Sancho
|
||
starweb!jas
|
||
214 242 2997
|
||
1000 Summit Circle, Carrollton, TX 75006
|
||
|
||
statham
|
||
Private System
|
||
Perry L. Statham
|
||
statham!perry
|
||
512 335 3881
|
||
7920 San Felipe #616, Austin, TX 78729
|
||
|
||
steel
|
||
Chaparral Steel Company
|
||
Shans Basiti
|
||
steel!shans
|
||
214 775 8241
|
||
300 Ward Road, Midlothian, TX 76065
|
||
|
||
strirc
|
||
James A. Tower
|
||
James A. Tower
|
||
strirc!jim
|
||
214 871 3311
|
||
c/o Huitt-Zollars 3131 McKinney Ave. STE 600, Dallas, TX 75204
|
||
|
||
sugar, .hackercorp.com
|
||
Hackercorp
|
||
Karl Lehenbauer
|
||
sugar!karl, sugar!usenet
|
||
713 438 4964
|
||
3918 Panorama, Missouri City, TX 77459
|
||
|
||
sulaco, .sigma.com
|
||
Southern Methodist University
|
||
R. Allen Gwinn, Jr.
|
||
sulaco!allen
|
||
214 692 3186 (VOICE)
|
||
Rm 150 Mc Guire Bldg., S.M.U., Dallas, TX 75275 (USMail)
|
||
|
||
sunanes, sunanes.hscsa.utexas.edu
|
||
Univ. of Texas Health Science Ctr. San Antonio, Dept of Anesthesiology
|
||
Buddy Hilliker
|
||
sunanes!buddy
|
||
512 567 4528
|
||
7703 Floyd Curl Drive #328F, San Antonio, TX 78284-7838
|
||
|
||
sunriv
|
||
SunRiver Corp.
|
||
John Crittenden
|
||
sunriv!root
|
||
512 835 8001
|
||
1150 Metric Blvd., Suite 150, Austin, TX 78758
|
||
|
||
supernet, supernet.haus.com, .haus.com, .dallas.haus.com
|
||
Harris Adacom Corporation
|
||
Clay Luther
|
||
cluther@supernet.haus.com
|
||
214 386 2356
|
||
P.O. Box 809022, Dallas, Tx 75380-9022
|
||
|
||
swrinde
|
||
Southwest Research Institute
|
||
Keith S. Pickens
|
||
swrinde!postmaster
|
||
512 684 5111
|
||
6220 Culebra Road, San Antonio, Texas 78284
|
||
|
||
tadusa
|
||
Tadpole Technology
|
||
Tonya Butcher
|
||
tadusa!butcher
|
||
512 338 4221
|
||
8310 Capitol of Texas Hwy. N, Suite 375, Austin, TX 78759
|
||
|
||
taliesin
|
||
Personal
|
||
Roger Florkowski
|
||
taliesin!postmaster
|
||
512 255 9003
|
||
14300 Tandem Blvd #251, Austin TX 78728
|
||
|
||
taronga, taronga.hackercorp.com
|
||
Individual
|
||
Peter da Silva
|
||
peter@taronga.hackercorp.com
|
||
713 274 5180
|
||
No physical address known
|
||
|
||
tcsoft
|
||
Third Coast Software, Inc.
|
||
Haran Boral
|
||
tcsoft!o2
|
||
512 343 8294
|
||
8716 N. MoPac, Suite 200, Austin, Texas 78759
|
||
|
||
teamcom
|
||
Team Air Express
|
||
David Swank
|
||
teamcom!david
|
||
214 342 3692
|
||
639 W Broadway, Winnsboro, TX 75494
|
||
|
||
techsup
|
||
Tandy/Radio Shack Technical Support # 0220
|
||
Gary Kueck
|
||
root@techsup.UUCP
|
||
817 390 2911
|
||
400 Atrium, One Tandy Center, Ft. Worth, TX 76102
|
||
|
||
tedpc
|
||
Private system
|
||
William Ted Mahavier
|
||
tedpc!postmaster, tedpc!ted
|
||
817 382 7036
|
||
400 Congress, Denton, TX 76201
|
||
|
||
teuton
|
||
Personal System
|
||
Bob Mugele
|
||
teuton!root
|
||
214 780-8844
|
||
602 Madison Ct. Duncanville, TX 75137
|
||
|
||
texbell, texbell.sbc.com, sbc.com
|
||
Southwestern Bell Corporation
|
||
Howard Cox
|
||
uocshc@swuts.sbc.com
|
||
214 464 8371
|
||
Two Bell Plaza, Room 340, Dallas, Texas 75202
|
||
NOTES:Internet gateway for Southwestern Bell Corporation
|
||
|
||
texhrc
|
||
TEXACO Houston Research Center
|
||
Lyle Meier, Susan Willis
|
||
texhrc!ldm,texhrc!sew
|
||
713-954-6000
|
||
3901 Briarpark, Houston, Tx 77072
|
||
|
||
texsun, central.sun.com, .central.sun.com
|
||
Sun Microsystems, Inc.
|
||
William Reeder
|
||
william.reeder@Central.Sun.COM texsun!william.reeder
|
||
214 788 3176
|
||
14785 Preston Road Suite 1050, Dallas, TX 75240-7607
|
||
|
||
thnkpos
|
||
EPH Information Systems
|
||
Buddy Hilliker
|
||
thnkpos!buddy
|
||
512 366 4785
|
||
2389 N.W. Military, #514, San Antonio, TX 78231
|
||
|
||
thot1
|
||
THOT Corporation
|
||
Jim Fiegenschue
|
||
thot1!jim
|
||
214 539 9281
|
||
120 Oak Grove Circle; Double Oak, TX 75067-8461
|
||
|
||
ti-csl
|
||
Texas Instruments
|
||
Joe Ramey
|
||
ti-csl!postmaster
|
||
214 995 5728
|
||
P.O. Box 655474, MS 238, Dallas, TX, 75265
|
||
|
||
tigon
|
||
TIGON
|
||
Phil Meyer
|
||
mages!phil
|
||
214 733 8625
|
||
17080 Dallas Parkway, Dallas, TX 75248
|
||
|
||
tmcvax
|
||
Houston Academy of Medicine/Texas Medical Center Library
|
||
Stan Barber/Susan Bateman
|
||
sob@bcm.tmc.edu,susan_bateman@library.tmc.edu
|
||
713 798 6042
|
||
HAM/TMC Library, Texas Medical Center, Houston, Tx 77030
|
||
|
||
toyshop
|
||
Private system
|
||
Eric Lipscomb
|
||
toyshop!postmaster, toyshop!root
|
||
817 387 6200
|
||
1608 McCormick Denton TX 76205
|
||
|
||
tqc, .n382.z1.FIDONET.ORG
|
||
Personal "The Q Continuum"
|
||
Eric Rouse
|
||
tqc!postmaster, tqc!eric
|
||
512 266 3867
|
||
2100 Red Fox Rd, Austin, Tx. 78734-2927
|
||
|
||
track29
|
||
ECP technical consulting
|
||
Charles Forsythe
|
||
track29!postmaster
|
||
214 739 3276
|
||
8215 Meadow Rd. #1005,Dallas, TX 75231
|
||
|
||
tramark
|
||
TraMark Software, Inc.
|
||
Mark McCollom
|
||
tramark!usenet
|
||
214 369 1777
|
||
10210 N. Central Expy., Suite 320, Dallas, TX 75231
|
||
|
||
trashy
|
||
Individual
|
||
Steve Talmage
|
||
steve@trashy.hou.tx.us
|
||
713 556 5830
|
||
12630 Ashford Point Drive, Apt. 419, Houston, TX 77082
|
||
|
||
trillium
|
||
University of Texas at Austin
|
||
Brook G. Milligan
|
||
ut-emx!brook
|
||
512 471 3530
|
||
Department of Botany
|
||
|
||
trimara
|
||
Trimarand, Inc.
|
||
Jeff Collins
|
||
trimara!root
|
||
713 358 2764
|
||
600 Rockmead, Suite 200, Kingwood, TX 77339
|
||
|
||
trsvax trsvax.tandy.com
|
||
Tandy Electronics, Research and Development
|
||
Frank Durda IV
|
||
uhclem@trsvax.tandy.com
|
||
817 390 2865
|
||
1300 Two Tandy Center, Ft. Worth, TX 76102
|
||
|
||
tsci, tsci.lonestar.org
|
||
System Center, Inc
|
||
David R. Wood
|
||
tsci!wood
|
||
214 550 0318 x132
|
||
2477 Gateway Drive, Suite 101, Irving, TX 75063-2728
|
||
|
||
tssnet
|
||
Thursday Software Systems, Inc.
|
||
Paul Nelson
|
||
tssnet!nelson
|
||
817 478 5070
|
||
5840 W. Interstate 20, Suite 115, Arlington, TX 76017
|
||
|
||
tusol
|
||
Trinity University CS Department
|
||
Aaron Konstam
|
||
tusol!akonstam
|
||
512 736-7484
|
||
715 Stadium Dr., San Antonio, TX 78284
|
||
|
||
txsil
|
||
Summer Institute of Linguistics
|
||
Dan Lord, Steve McConnel
|
||
txsil!postmaster
|
||
214 709 3319
|
||
7500 W Camp Wisdom Road, Dallas Texas 75236
|
||
|
||
ucmsa
|
||
ALAMO Matchmaker
|
||
Buddy Hilliker
|
||
ucmsa!news
|
||
512 366 4785 (VOICE) 512 366 4752 (DIALUP)
|
||
2389 N.W. Military, #514, San Antonio, TX 78231
|
||
|
||
uhc
|
||
UHC
|
||
Steve Talmage
|
||
uhc!steve, uhc!root, uhc!postmaster
|
||
713 782 2700
|
||
3600 South Gessner, Suite 110, Houston, TX 77063
|
||
|
||
uhnix1
|
||
University of Houston, Academic Computing Services
|
||
Alan Pfeiffer-Traum
|
||
postmaster@uh.edu
|
||
713 749 1490
|
||
4800 Calhoun, Houston, TX 77204-1961
|
||
|
||
uhura1
|
||
Mark Weber
|
||
uhura1!root
|
||
713 626 9568
|
||
5177 Richmond Avenue, Suite 1075, Houston, TX 77056
|
||
|
||
uller
|
||
ATL inc...
|
||
Michael F. Angelo
|
||
uller!postmaster
|
||
713 586 7761
|
||
No physical address known
|
||
|
||
unidos
|
||
UniDos, Inc.
|
||
Bill Van Zandt
|
||
unidos!bvz
|
||
713 785 4709
|
||
7660 Woodway, Suite 580, Houston, TX 77063
|
||
|
||
unisql
|
||
UniSQL, Inc.
|
||
Alfred Correira
|
||
unisql!usenet
|
||
512 343 7297
|
||
9390 Research Blvd, Kaleido II, Suite 220, Austin, Texas 78759
|
||
|
||
urchin, .n106.z1.fidonet.org
|
||
Two Wheelers FidoNet BBS
|
||
Howard Gerber
|
||
urchin!postmaster
|
||
713 682 4759
|
||
1031 West 43rd Street, Houston, TX 77018-4301
|
||
|
||
usdalmkt, usdalmkt.haus.com, usdalmkt.dallas.haus.com
|
||
Harris Adacom Corporation, Dallas Marketing
|
||
Tony Druery
|
||
usdalmkt!tony
|
||
214 386 1229
|
||
P.O. Box 809022, Dallas, Tx 75380-9022
|
||
|
||
ut-botany
|
||
University of Texas at Austin
|
||
Brook G. Milligan
|
||
ut-emx!brook
|
||
512 471 3530
|
||
Department of Botany
|
||
|
||
ut-emx
|
||
The University of Texas at Austin, Computation Center
|
||
Vance Strickland
|
||
ut-emx!uucp
|
||
(512) 471-3241
|
||
Austin, TX 78712
|
||
|
||
utacfd, utacfd.arl.utexas.edu
|
||
Univ. of Tx at Arlington; Aerospace Eng. Dept.
|
||
Ralph W. Noack
|
||
utacfd!postmaster
|
||
817 273 2860
|
||
UTA Box 19018, Arlingtion, Tx 76019
|
||
|
||
utanes
|
||
Univ. of Texas Health Science Ctr. San Antonio, Dept of Anesthesiology
|
||
Buddy Hilliker
|
||
utanes!eph
|
||
512 567 4528
|
||
7703 Floyd Curl Drive #328F, San Antonio, TX 78284-7838
|
||
|
||
utastro
|
||
University of Texas, Astronomy/McDonald Observatory
|
||
David Way
|
||
postmaster@utastro.UUCP
|
||
512 471 7439
|
||
Univ of Texas, Dept of Astronomy, Austin TX 78712
|
||
|
||
utep-vaxa
|
||
University of Texas at El Paso, EE and CS Dept.
|
||
Edgar Gandara
|
||
utep-vaxa!sys_man
|
||
915 747 5470
|
||
El Paso, Texas 79968-0523
|
||
|
||
uudell, .dell.com
|
||
Dell Computer Corporation
|
||
James Van Artsdalen
|
||
postmaster@uudell.dell.com
|
||
512 338 8789
|
||
Dell Computer Corporation, AR3, 9505 Arboretum Blvd., Austin TX 78759
|
||
|
||
val, .val.com
|
||
Video Associates Labs, Inc.
|
||
Ben Thornton
|
||
val!ben
|
||
512 346 5781
|
||
4926 Spicewood Springs Rd., Austin, TX 78759
|
||
|
||
vector, vector.dallas.tx.us
|
||
Dallas Semiconductor
|
||
Ed Higgins
|
||
vector!edso
|
||
214 450 5391
|
||
4401 South Beltwood Parkway, Dallas, TX 75244-3292
|
||
|
||
virago
|
||
Private System
|
||
Mitch Mitchell
|
||
virago!postmaster
|
||
214 519 3257, 214 248 8149
|
||
18330 Gallery Drive #723, Dallas, TX, 75252-5143
|
||
|
||
vitec
|
||
Visual Information Technologies - VITec
|
||
Jay Thompson
|
||
vitec!jay
|
||
214 596 5600
|
||
3460 Lotus Dr, Plano, TX 75075
|
||
|
||
vitsun
|
||
Visual Information Technologies (VITec)
|
||
Jay Thompson
|
||
vitsun!jthompson
|
||
214 596 5600
|
||
3460 Lotus Dr, Plano, TX 75075
|
||
|
||
void, void.lonestar.org
|
||
Cam Fox
|
||
cam@void.lonestar.org
|
||
214-306-0148
|
||
18175 Midway, #253 - Dallas - Tx - 75287
|
||
|
||
vortech
|
||
Vortech Data, Inc.
|
||
Peter Stephens
|
||
postmaster@vortech.UUCP
|
||
214 669 3448
|
||
2929 North Central Exprwy, Suite 240, Richardson, TX 75080
|
||
|
||
w5veo,w5veo.boerne.tx.us
|
||
Amateur radio station w5veo
|
||
Larry Becker
|
||
w5veo!w5veo
|
||
512 249 3168
|
||
Rt 2 Box 2741, Boerne, TX 78006
|
||
|
||
walrus
|
||
ACECO
|
||
Dave Minor
|
||
walrus!root
|
||
512 661 4111
|
||
5355 Dietrich Rd, San Antonio, TX 78219
|
||
|
||
warble
|
||
Private system
|
||
Wayne Ross
|
||
wayne@warble.UUCP
|
||
214 987 1478
|
||
3415 Westminster Suite 201 Dallas Texas USA 75205
|
||
|
||
watson, bcm.tmc.edu
|
||
Baylor College of Medicine
|
||
Stan Barber
|
||
postmaster@bcm.tmc.edu
|
||
713 798 6042
|
||
Baylor College of Medicine, One Baylor Plaza, Houston, Texas 77030
|
||
|
||
wb9rxw
|
||
American Airlines - STIN
|
||
Gary Partain
|
||
wb9rxw!gary
|
||
817 963 3311
|
||
2748 Timber Ct., Grand Prairie, TX 75052-4443
|
||
|
||
wcscnet
|
||
Willies Computer Software Co.
|
||
Egberto Willies
|
||
wcscnet!root
|
||
713 498 4832
|
||
10507 Swan Glen, Houston, TX 77099
|
||
|
||
westech
|
||
Western Atlas/Integrated Technologies
|
||
David Waddell
|
||
westech!root
|
||
713 972 4618
|
||
10205 Westheimer, Room 774, Houston, TX 77042
|
||
|
||
whitwiz, whitwiz.lonestar.org
|
||
Private System
|
||
Danny White
|
||
whitwiz!postmaster
|
||
214-422-7131
|
||
1429 Glacier, Plano, Tx 75023
|
||
|
||
witte
|
||
Private System
|
||
Ken Witte
|
||
witte!witte
|
||
512 990 2529
|
||
14302 Jennave Ln., Austin, Texas 78728
|
||
|
||
wixer
|
||
Wixer Industries
|
||
Douglas Barnes
|
||
wixer!dorf
|
||
512 454 8134
|
||
504 W. 24th St #30, Austin, TX 78705
|
||
|
||
wizlair
|
||
Wizard's Lair Private BBS
|
||
Robert D. Greene
|
||
rgreene@bnr.ca
|
||
214-pri-vate
|
||
9150 Fair Oaks #915, Dallas, Texas 75231
|
||
|
||
wnss
|
||
We'll Never Stop Searching
|
||
Lance Spangler
|
||
spangler@wnss.UUCP
|
||
512 454-2038
|
||
PO Box 9927, Austin, TX 78766
|
||
|
||
woodwrk, woodwrk.lonestar.org
|
||
Kingswood Software Associates
|
||
Richard H. Wood
|
||
woodwrk!postmaster
|
||
214 530 2595, 214 519 3559
|
||
246 Bancroft Drive East, Garland, Tx 75040
|
||
|
||
wotan, wotan.compaq.com, compaq.com
|
||
Compaq Computer Corporation
|
||
Greg Hackney
|
||
hackney@compaq.com
|
||
713+378-8427
|
||
20555 SH 249, M-050701, Houston, Texas, 77070-2698
|
||
|
||
woton
|
||
Shriners Burns Institute
|
||
R.J. Nichols III
|
||
woton!postmaster
|
||
409 761 4701
|
||
SBI, Computer Department, 610 Texas Ave., Galveston, TX 77550 USA
|
||
|
||
wrangler
|
||
W.L. Kennedy Jr. & Associates
|
||
William L. Kennedy, Jr. (Bill)
|
||
bill@ssbn.WLK.COM
|
||
512 535 4966
|
||
Box 63449 Bandera Falls, Pipe Creek, TX 78063-3449
|
||
|
||
wroach, wroach.cactus.org
|
||
personal
|
||
Walter Butler
|
||
postmaster@wroach.cactus.org
|
||
512 326 2421
|
||
905 E. Oltorf, Austin, TX 78704
|
||
|
||
wylie
|
||
CIM Systems
|
||
Steve Hickman
|
||
wylie!root
|
||
214 437 5171
|
||
2425 N. Central Expressway Suite 432 Richardson, TX 75080
|
||
|
||
ywamtxs
|
||
Youth With A Mission
|
||
Robert G. Smith
|
||
ywamtxs!robert
|
||
214 882 5591
|
||
PO Box 4600, Tyler, TX 75712-4600
|
||
|
||
zippee
|
||
TPC Services
|
||
Tim Dawson
|
||
zippee!root
|
||
214 221 7385
|
||
1502 Live Oak, Lewisville, TX 75067
|
||
|
||
zitt
|
||
Syntax Performance Group
|
||
Joe Zitt
|
||
zitt!postmaster
|
||
512 450 1916
|
||
2819 Foster Lane, Apt F112, Austin TX 78757
|
||
|
||
zycorus
|
||
Zycor, Inc.
|
||
Bill Curtis
|
||
zycorus!root
|
||
512 282 6699
|
||
220 Foremost Austin, TX 78745
|
||
|
||
===================================================================
|
||
|
||
|
||
/ /
|
||
/ File 06 / NIA071 /
|
||
/ Electronic Frontier Foundation /
|
||
/ Mike Godwin (mnemonic@eff.org) /
|
||
/ /
|
||
|
||
[Editors Note: The following release was Faxcast to 1500+ media organizations
|
||
and interested parties where it was followed up released in EFFector (Ref: EFF
|
||
Newsletter, Editor: Mike Godwin). This is a case I feel that is _very_
|
||
important to our community and so therefore will be covered by NIA as
|
||
developements continue.]
|
||
|
||
|
||
EXTENDING THE CONSTITUTION TO AMERICAN CYBERSPACE:
|
||
|
||
|
||
TO ESTABLISH CONSTITUTIONAL PROTECTION FOR ELECTRONIC MEDIA AND TO
|
||
OBTAIN REDRESS FOR AN UNLAWFUL SEARCH, SEIZURE, AND PRIOR RESTRAINT
|
||
ON PUBLICATION, STEVE JACKSON GAMES AND THE ELECTRONIC FRONTIER
|
||
FOUNDATION TODAY FILED A CIVIL SUIT AGAINST THE UNITED STATES SECRET
|
||
SERVICE AND OTHERS.
|
||
|
||
|
||
On March 1, 1990, the United States Secret Service nearly
|
||
destroyed Steve Jackson Games (SJG), an award-winning publishing
|
||
business in Austin, Texas.
|
||
In an early morning raid with an unlawful and
|
||
unconstitutional warrant, agents of the Secret Service conducted a
|
||
search of the SJG office. When they left they took a manuscript
|
||
being prepared for publication, private electronic mail, and several
|
||
computers, including the hardware and software of the SJG Computer
|
||
Bulletin Board System. Yet Jackson and his business were not only
|
||
innocent of any crime, but never suspects in the first place. The
|
||
raid had been staged on the unfounded suspicion that somewhere in
|
||
Jackson's office there "might be" a document compromising the
|
||
security of the 911 telephone system.
|
||
In the months that followed,
|
||
Jackson saw the business he had built up over many years dragged to
|
||
the edge of bankruptcy. SJG was a successful and prestigious
|
||
publisher of books and other materials used in adventure role-playing
|
||
games. Jackson also operated a computer bulletin board system (BBS)
|
||
to communicate with his customers and writers and obtain feedback and
|
||
suggestions on new gaming ideas. The bulletin board was also the
|
||
repository of private electronic mail belonging to several of its
|
||
users. This private mail was seized in the raid. Despite repeated
|
||
requests for the return of his manuscripts and equipment, the Secret
|
||
Service has refused to comply fully.
|
||
Today, more than a year after that raid, The Electronic
|
||
Frontier Foundation, acting with SJG owner Steve Jackson, has filed
|
||
a precedent setting civil suit against the
|
||
United States Secret Service, Secret Service Agents Timothy Foley and
|
||
Barbara Golden, Assistant United States Attorney William Cook, and
|
||
Henry Kluepfel.
|
||
"This is the most important case brought to date,"
|
||
said EFF general counsel Mike Godwin, "to vindicate the
|
||
Constitutional rights of the users of computer-based communications
|
||
technology. It will establish the Constitutional dimension of
|
||
electronic expression. It also will be one of the first cases that
|
||
invokes the Electronic Communications and Privacy Act as a shield and
|
||
not as a sword -- an act that guarantees users of this digital
|
||
medium the same privacy protections enjoyed by those who use the
|
||
telephone and the U.S. Mail."
|
||
Commenting on the overall role of the Electronic
|
||
Frontier Foundation in this case and other matters, EFFs
|
||
president Mitch Kapor said, "We have been acting as an organization
|
||
interested in defending the wrongly accused. But the Electronic
|
||
Frontier Foundation is also going to be active in establishing
|
||
broader principles. We begin with this case, where the issues are
|
||
clear. But behind this specific action, the EFF also believes that
|
||
it is vital that government, private entities, and individuals who
|
||
have violated the Constitutional rights of individuals be held
|
||
accountable for their actions. We also hope this case will help
|
||
demystify the world of computer users to the general public and
|
||
inform them about the potential of computer communities."
|
||
|
||
Representing Steve Jackson and The Electronic Frontier
|
||
Foundation in this suit is James George,Jr. of Graves, Dougherty,
|
||
Hearon & Moody of Austin, Rabinowitz, Boudin, Standard, Krinsky &
|
||
Liberman of New York,and Harvey A. Silverglate and Sharon L. Beckman
|
||
of Silverglate & Good of Boston .
|
||
Copies of the complaint, the unlawful search warrant,
|
||
statements by Steve Jackson and the Electronic Frontier Foundation, a
|
||
legal fact sheet and other pertinent materials are available by
|
||
request from the EFF.
|
||
|
||
---
|
||
|
||
Also made available to members of the press and electronic media on
|
||
request were the following statementby Mitchell Kapor and a legal
|
||
fact sheet prepared by Sharon Beckman and Harvey Silverglate of
|
||
Silverglate & Good, the law firm central to the filing of this
|
||
lawsuit.
|
||
|
||
|
||
WHY THE ELECTRONIC FRONTIER FOUNDATION IS BRINGING SUIT ON BEHALF OF
|
||
STEVE JACKSON.
|
||
|
||
|
||
With this case, the Electronic Frontier Foundation begins a new
|
||
phase of affirmative legal action. We intend to fight for broad
|
||
Constitutional protection for operators and users of computer
|
||
bulletin boards.
|
||
|
||
It is essential to establish the principle that computer bulletin
|
||
boards and computer conferencing systems are entitled to the same
|
||
First Amendment rights enjoyed by other media. It is also critical
|
||
to establish that operators of bulletin boards JQJ whether
|
||
individuals or businesses JQJ are not subject to unconstitutional,
|
||
overbroad searches and seizures of any of the contents of their
|
||
systems, including electronic mail.
|
||
|
||
The Electronic Frontier Foundation also believes that
|
||
it is vital to hold government, private entities, and individuals
|
||
who have violated the Constitutional rights of others accountable
|
||
for their actions.
|
||
|
||
|
||
Mitchell Kapor,
|
||
President, The Electronic Frontier Foundation
|
||
|
||
---
|
||
|
||
LEGAL FACT SHEET: STEVE JACKSON GAMES V. UNITED STATES SECRET
|
||
SERVICE, ET AL
|
||
|
||
|
||
This lawsuit seeks to vindicate the rights of a small, successful
|
||
entrepreneur/publisher to conduct its entirely lawful business, free
|
||
of unjustified governmental interference. It is also the goal of
|
||
this litigation to firmly establish the principle that lawful
|
||
activities carried out with the aid of computer technology, including
|
||
computer communications and publishing, are entitled to the same
|
||
constitutional protections that have long been accorded to the print
|
||
medium. Computers and modems, no less than printing presses,
|
||
typewriters, the mail, and telephones -being the methods selected by
|
||
Americans to communicate with one another -- are all protected by our
|
||
constitutional rights.
|
||
|
||
|
||
Factual Background and Parties:
|
||
|
||
Steve Jackson, of Austin, Texas, is a successful small businessman.
|
||
His company, Steve Jackson Games, is an award- winning publisher of
|
||
adventure games and related books and magazines. In addition to its
|
||
books and magazines, SJG operates an electronic bulletin board system
|
||
(the Illuminati BBS) for its customers and for others interested in
|
||
adventure games and related literary genres.
|
||
|
||
Also named as plaintiffs are various users of the Illuminati BBS.
|
||
The professional interests of these users range from writing to
|
||
computer technology.
|
||
|
||
Although neither Jackson nor
|
||
his company were suspected of any criminal activity, the company was
|
||
rendered a near fatal blow on March 1, 1990, when agents of the
|
||
United States Secret Service, aided by other law enforcement
|
||
officials, raided its office, seizing computer equipment necessary to
|
||
the operation of its publishing business. The government seized the
|
||
Illuminati BBS and all of the communications stored on it, including
|
||
private electronic mail, shutting down the BBS for over a month. The
|
||
Secret Service also seized publications protected by the First
|
||
Amendment, including drafts of the about-to-be-released role playing
|
||
game book GURPS Cyberpunk. The publication of the book was
|
||
substantially delayed while SJG employees rewrote it from older
|
||
drafts. This fantasy game book, which one agent preposterously
|
||
called "a handbook for computer crime," has since sold over 16,000
|
||
copies and been nominated for a prestigious game industry award. No
|
||
evidence of criminal activity was found.
|
||
|
||
The warrant application,
|
||
which remained sealed at the government's request for seven months,
|
||
reveals that the agents were investigating an employee of the company
|
||
whom they believed to be engaged in activity they found questionable
|
||
at his home and on his own time. The warrant application further
|
||
reveals not only that the Secret Service had no reason to think any
|
||
evidence of criminal activity would be found at SJG, but also that
|
||
the government omitted telling the Magistrate who issued the warrant
|
||
that SJG was a publisher and that the contemplated raid would cause a
|
||
prior restraint on constitutionally protected speech, publication,
|
||
and association.
|
||
|
||
The defendants in this case are the United States
|
||
Secret Service and the individuals who, by planning and carrying out
|
||
this grossly illegal search and seizure, abused the power conferred
|
||
upon them by the federal government. Those individuals include
|
||
Assistant United States Attorney William J. Cook, Secret Service
|
||
Agents Timothy M. Foley and Barbara Golden, as well Henry M. Kluepfel
|
||
of Bellcore, who actively participated in the unlawful activities as
|
||
an agent of the federal government.
|
||
|
||
These defendants are the same
|
||
individuals and entities responsible for the prosecution last year of
|
||
electronic publisher Craig Neidorf. The government in that case
|
||
charged that Neidorf's publication of materials concerning the
|
||
enhanced 911 system constituted interstate transportation of stolen
|
||
property. The prosecution was resolved in Neidorf's favor in July of
|
||
1990 when Neidorf demonstrated that materials he published were
|
||
generally available to the public.
|
||
|
||
|
||
Legal Significance:
|
||
|
||
|
||
This case is about the constitutional and statutory rights of
|
||
publishers who conduct their activities in electronic media rather
|
||
than in the traditional print and hard copy media, as well as the
|
||
rights of individuals and companies that use computer technology to
|
||
communicate as well as to conduct personal and business affairs
|
||
generally.
|
||
|
||
The government's wholly unjustified raid on SJG, and
|
||
seizure of its books, magazines, and BBS, violated clearly
|
||
established statutory and constitutional law, including:
|
||
|
||
|
||
. The Privacy Protection Act of 1980, which generally prohibits
|
||
the government from searching the offices of publishers for work
|
||
product and other documents, including materials that are
|
||
electronically stored;
|
||
|
||
|
||
. The First Amendment to the U. S. Constitution, which guarantees
|
||
freedom of speech, of the press and of association, and which
|
||
prohibits the government from censoring publications, whether in
|
||
printed or electronic media.
|
||
|
||
|
||
. The Fourth Amendment, which prohibits unreasonable governmental
|
||
searches and seizures, including both general searches and searches
|
||
conducted without probable cause to believe that specific evidence of
|
||
criminal activity will be found at the location searched.
|
||
|
||
|
||
. The Electronic Communications Privacy Act and the Federal
|
||
Wiretap statute, which together prohibit the government from seizing
|
||
electronic communications without justification and proper
|
||
authorization.
|
||
|
||
STEVE JACKSON LAWSUIT: FULL TEXT OF COMPLAINT (long)
|
||
This document was filed May 1 in federal court in Austin, Texas
|
||
|
||
UNITED STATES DISTRICT COURT
|
||
WESTERN DISTRICT OF TEXAS
|
||
AUSTIN DIVISION
|
||
|
||
STEVE JACKSON GAMES INCORPORATED,
|
||
STEVE JACKSON, ELIZABETH
|
||
McCOY, WALTER MILLIKEN, and
|
||
STEFFAN O'SULLIVAN,
|
||
|
||
Plaintiffs,
|
||
|
||
v.
|
||
|
||
UNITED STATES SECRET SERVICE,
|
||
UNITED STATES OF AMERICA,
|
||
WILLIAM J. COOK, TIMOTHY M. FOLEY,
|
||
BARBARA GOLDEN, and HENRY M. KLUEPFEL,
|
||
|
||
Defendants.
|
||
|
||
|
||
COMPLAINT AND DEMAND FOR JURY TRIAL
|
||
I. INTRODUCTION AND SUMMARY
|
||
This is a civil action for damages to redress
|
||
violations of the Privacy Protection Act of 1980,
|
||
42 U.S.C. 2000aa et seq; the Electronic
|
||
Communications Privacy Act, as amended, 18 U.S.C.
|
||
2510 et seq and 2701 et seq; and the First and
|
||
Fourth Amendments to the United States
|
||
Constitution.
|
||
Plaintiffs are Steve Jackson Games
|
||
Incorporated ("SJG"), an award-winning publisher of
|
||
books, magazines, and games; its president and sole
|
||
owner Steve Jackson; and three other users of an
|
||
electronic bulletin board system operated by SJG.
|
||
Defendants are the United States Secret
|
||
Service, the United States of America, an Assistant
|
||
United States Attorney, Secret Service agents, and
|
||
a private individual who acted at the direction of
|
||
these federal officers and agents and under color
|
||
of federal authority.
|
||
Although neither Steve Jackson nor SJG was a
|
||
target of any criminal investigation, defendants
|
||
caused a general search of the business premises of
|
||
SJG and the wholesale seizure, retention, and
|
||
conversion of computer hardware and software and
|
||
all data and communications stored there.
|
||
Defendants seized and retained work product and
|
||
documentary materials relating to SJG books, games,
|
||
and magazines, thereby imposing a prior restraint
|
||
on the publication of such materials. Defendants
|
||
also seized and retained an entire electronic
|
||
bulletin board system, including all computer
|
||
hardware and software used to operate the system
|
||
and all data and communications stored on the
|
||
system, causing a prior restraint on the operation
|
||
of the system. Defendants also seized and retained
|
||
computer hardware and software, proprietary
|
||
information, records, and communications used by
|
||
SJG in the ordinary course of operating its
|
||
publishing business.
|
||
The search of this reputable publishing
|
||
business and resulting seizures constituted a
|
||
blatant violation of clearly established law. The
|
||
search and seizure violated the Privacy Protection
|
||
Act of 1980, which strictly prohibits law
|
||
enforcement officers from using search and seizure
|
||
procedures to obtain work product or documentary
|
||
materials from a publisher, except in narrow
|
||
circumstances not applicable here. The seizure and
|
||
retention of SJG's work product and bulletin board
|
||
system, as well as the seizure and retentionof the
|
||
computers used to prepare SJG publications and to
|
||
operate the bulletin board system, violated the
|
||
First Amendment. The search and seizure, which
|
||
encompassed proprietary business information and
|
||
private electronic communications as well as
|
||
materials protected by the First Amendment, also
|
||
violated the Fourth Amendment. Defendants
|
||
conducted an unconstitutional general search
|
||
pursuant to a facially invalid, general warrant.
|
||
The warrant was issued without probable cause to
|
||
believe that any evidence of criminal activity
|
||
would be found at SJG and was issued on the basis
|
||
of false and misleading information supplied by the
|
||
defendants. Defendants also invaded plaintiffs'
|
||
privacy by seizing and intercepting the plaintiffs'
|
||
private electronic communications in violation of
|
||
the Electronic Communications Privacy Act.
|
||
Defendants' wrongful and unlawful conduct
|
||
amounted to an assault by the government on the
|
||
plaintiffs, depriving them of their property, their
|
||
privacy, their First Amendment rights and
|
||
inflicting humiliation and great emotional distress
|
||
upon them.
|
||
II. DEFINITIONS
|
||
When used in this complaint, the following
|
||
words and phrases have the following meanings:
|
||
Computer Hardware: Computer hardware consists
|
||
of the mechanical, magnetic, electronic, and
|
||
electrical devices making up a computer system,
|
||
such as the central processing unit, computer
|
||
storage devices (disk drives, hard disks, floppy
|
||
disks), keyboard, monitor, and printing devices.
|
||
Computer Software: Computer software consists
|
||
of computer programs and related instructions and
|
||
documentation.
|
||
Computer Program: A computer program is a set
|
||
of instructions that, when executed on a computer,
|
||
cause the computer to process data.
|
||
Source Code: Source code is a set of
|
||
instructions written in computer programming
|
||
language readable by humans. Source code must be
|
||
"compiled," "assembled," or "interpreted" with the
|
||
use of a computer program before it is executable
|
||
by a computer.
|
||
Text File: A computer file is a collection of
|
||
data treated as a unit by a computer. A text file
|
||
is a memorandum, letter, or any other alphanumeric
|
||
text treated as a unit by a computer. A text file
|
||
can be retrieved from storage and viewed on a
|
||
computer monitor, printed on paper by a printer
|
||
compatible with the computer storing the data, or
|
||
transmitted to another computer.
|
||
Modem: A modem, or modulator-demodulator, is
|
||
an electronic device that makes possible the
|
||
transmission of data to or from a computer over
|
||
communications channels, including telephone lines.
|
||
Electronic mail: Electronic mail (e-mail) is a
|
||
data communication transmitted between users of a
|
||
computer system or network. E-mail is addressed to
|
||
one or more accounts on a computer system assigned
|
||
to specific users and is typically stored on the
|
||
system computer until read and deleted by the
|
||
addressee. The privacy of electronic mail is
|
||
typically secured by means of a password, so that
|
||
only individuals withknowledge of the account's
|
||
password can obtain access to mail sent to that
|
||
account.
|
||
Electronic Bulletin Board System (BBS): A BBS
|
||
is a computerized conferencing system that permits
|
||
communication and association between and among its
|
||
users. A systems operator ("sysop") manages the
|
||
BBS on a computer system that is equipped with
|
||
appropriate hardware and software to store text
|
||
files and communications and make them accessible
|
||
to users. Users of the BBS gain access to the
|
||
system using their own computers and modems and
|
||
normal telephone lines.
|
||
A BBS is similar to a traditional bulletin
|
||
board in that it allows users to transmit and
|
||
"post" information readable by other users. Common
|
||
features of a BBS include:
|
||
(1) Conferences in which users engage in an
|
||
ongoing exchange of information and ideas.
|
||
Conferences can be limited to a specific group of
|
||
users, creating an expectation of privacy, or open
|
||
to the general public.
|
||
(2) Archives containing electronically stored
|
||
text files accessible to users;
|
||
(3) Electronic mail service, in which the host
|
||
computer facilitates the delivery, receipt, and
|
||
storage of electronic mail sent between users.
|
||
Bulletin board systems may be maintained as
|
||
private systems or permit access to the general
|
||
public. They range in size from small systems
|
||
operated by individuals using personal computers in
|
||
their homes, to medium-sized systemsoperated by
|
||
groups or commercial organizations, to world-wide
|
||
networks of interconnected computers. The subject
|
||
matter and number of topics discussed on a BBS are
|
||
limited only by the choices of the system's
|
||
operators and users. Industry estimates indicate
|
||
that well over a million people in the United
|
||
States use bulletin board systems.
|
||
III. PARTIES
|
||
1. Plaintiff SJG is a corporation duly
|
||
organized and existing under the laws of the State
|
||
of Texas. At all relevant times, SJG was engaged
|
||
in the business of publishing adventure games and
|
||
related books and magazines. Its place of business
|
||
is 2700-A Metcalfe Road, Austin, Texas.
|
||
2. Plaintiff Steve Jackson ("Jackson"), the
|
||
president and sole owner of SJG, is an adult
|
||
resident of the State of Texas.
|
||
3. Plaintiffs Elizabeth McCoy, Walter
|
||
Milliken, and Steffan O'Sullivan are adult
|
||
residents of the State of New Hampshire. At all
|
||
relevant times, they were users of the electronic
|
||
bulletin board system provided and operated by SJG
|
||
and known as the "Illuminati Bulletin Board System"
|
||
("Illuminati BBS").
|
||
4. The United States Secret Service, an
|
||
agency within the Treasury Department, and the
|
||
United States of America sued in Counts I, IV, and
|
||
V.
|
||
5. Defendant William J. Cook ("Cook") is an
|
||
adult resident of the State of Illinois. At all
|
||
relevant times,Cook was employed as an Assistant
|
||
United States Attorney assigned to the United
|
||
States Attorney's office in Chicago, Illinois.
|
||
Cook is sued in Counts II-V.
|
||
6. Defendant Timothy M. Foley ("Foley") is an
|
||
adult resident of the State of Illinois. At all
|
||
relevant times, Foley was employed as a Special
|
||
Agent of the United States Secret Service, assigned
|
||
to the office of the United States Secret Service
|
||
in Chicago, Illinois. At all relevant times, Foley
|
||
was an attorney licensed to practice law in the
|
||
State of Illinois. Foley is sued in Counts II-V.
|
||
7. Defendant Barbara Golden ("Golden") is an
|
||
adult resident of the State of Illinois. At all
|
||
relevant times, Golden was employed as a Special
|
||
Agent of the United States Secret Service assigned
|
||
to the Computer Fraud Section of the United States
|
||
Secret Service in Chicago, Illinois.
|
||
8. Defendant Henry M. Kluepfel ("Kluepfel")
|
||
is an adult resident of the state of New Jersey.
|
||
At all relevant times, Kluepfel was employed by
|
||
Bell Communications Research as a district manager.
|
||
Kluepfel is sued in Counts II-V.
|
||
III. JURISDICTION AND VENUE
|
||
9. This Court's jurisdiction is invoked
|
||
pursuant to 28 U.S.C. 1331 and 42 U.S.C. 2000aa-
|
||
6(h). Federal question jurisdiction is proper
|
||
because this is a civil action authorized and
|
||
instituted pursuant to the First and Fourth
|
||
Amendments to the United States Constitution, 42
|
||
U.S.C. 2000aa-6(a) and 6(h), and 18 U.S.C. 2707
|
||
and 2520.
|
||
10. Venue in the Western District of Texas is
|
||
proper under 28 U.S.C. 1391(b), because a
|
||
substantial part of the events or omissions giving
|
||
rise to the claims occurred within this District.
|
||
IV. STATEMENT OF CLAIMS
|
||
FACTUAL BACKGROUND
|
||
Steve Jackson Games
|
||
11. SJG, established in 1980 and incorporated
|
||
in 1984, is a publisher of books, magazines, and
|
||
adventure games.
|
||
(a) SJG books and games create imaginary worlds
|
||
whose settings range from prehistoric to futuristic
|
||
times and whose form encompass various literary
|
||
genres.
|
||
(b) The magazines published by SJG contain news,
|
||
information, and entertainment relating to the
|
||
adventure game industry and related literary
|
||
genres.
|
||
12. SJG games and publications are carried by
|
||
wholesale distributors throughout the United States
|
||
and abroad.
|
||
13. SJG books are sold by national retail
|
||
chain stores including B. Dalton, Bookstop, and
|
||
Waldenbooks.
|
||
14. Each year from 1981 through 1989, and
|
||
again in 1991, SJG board games, game books, and/or
|
||
magazines have been nominated for and/or received
|
||
the Origins Award. The Origins Award, administered
|
||
by the Game Manufacturers' Association, is the
|
||
adventure game industry's most prestigious award.
|
||
15. SJG is not, and has never been, in the
|
||
business of selling computer games, computer
|
||
programs, or other computer products.
|
||
16. On March 1, 1990, SJG had 17 employees.
|
||
Steve Jackson Games Computer Use
|
||
17. At all relevant times, SJG relied upon
|
||
computers for many aspects of its business,
|
||
including but not limited to the following uses:
|
||
(a) Like other publishers of books or magazines,
|
||
and like a newspaper publisher, SJG used computers
|
||
to compose, store, and prepare for publication the
|
||
text of its books, magazines, and games.
|
||
(b) SJG stored notes, source materials, and
|
||
other work product and documentary materials
|
||
relating to SJG publications on its computers.
|
||
(c) Like many businesses, SJG used computers to
|
||
create and store business records including, but
|
||
not limited to, correspondence, contracts, address
|
||
directories, budgetary and payroll information,
|
||
personnel information, and correspondence.
|
||
18. Since 1986, SJG has used a computer to
|
||
operate an electronic bulletin board system (BBS)
|
||
dedicated to communication of information about
|
||
adventure games, the game industry, related
|
||
literary genres, and to association among
|
||
individuals who share these interests.
|
||
(a) The BBS was named "Illuminati," after the
|
||
company's award-winning board game.
|
||
(b) At all relevant times, the Illuminati BBS
|
||
was operated by means of a computer located on the
|
||
business premises of SJG. The computer used to run
|
||
the Illuminati BBS (hereafter the "Illuminati
|
||
computer") was connected to the telephone number
|
||
512-447-4449. Users obtained access to
|
||
communications and information stored on the
|
||
Illuminati BBS from their own computers via
|
||
telephone lines.
|
||
(c) The Illuminati BBS provided a forum for
|
||
communication and association among its users,
|
||
which included SJG employees, customers, retailers,
|
||
writers, artists, competitors, writers of science
|
||
fiction and fantasy, and others with an interest in
|
||
the adventure game industry or related literary
|
||
genres.
|
||
(d) SJG, Jackson, and SJG employees also used
|
||
the Illuminati BBS in the course of business to
|
||
communicate with customers, retailers, writers, and
|
||
artists; to provide customer service; to obtain
|
||
feedback on games and new game ideas; to obtain
|
||
general marketing information; to advertise its
|
||
games and publications, and to establish good will
|
||
and a sense of community with others who shared
|
||
common interests.
|
||
(e) As of February 1990, the Illuminati BBS had
|
||
over 300 users residing throughout the United
|
||
States and abroad.
|
||
(f) At all relevant times, plaintiffs SJG,
|
||
Jackson, McCoy, Milliken, and O'Sullivan were
|
||
active users of the Illuminati BBS.
|
||
(g) Each user account was assigned a password to
|
||
secure the privacy of the account.
|
||
(h) The Illuminati BBS gave users access to
|
||
general files of electronically stored information.
|
||
General files included, but were not limited to,
|
||
text files containing articles on adventure games
|
||
and game-related humor, including articles
|
||
published in SJG magazines and articles contributed
|
||
by users of the BBS, and text files containing game
|
||
rules. These general files were stored on the
|
||
Illuminati computer at SJG.
|
||
(i) The Illuminati BBS provided several public
|
||
conferences, in which users of the BBS could post
|
||
information readable by other users and read
|
||
information posted by others. The discussions in
|
||
the public conferences focused on SJG products,
|
||
publications and related literary genres. All
|
||
communications transmitted to these conferences
|
||
were stored in the Illuminati computer at SJG.
|
||
(j) SJG informed users of the Illuminati BBS
|
||
that
|
||
|
||
"any opinions expressed on the BBS, unless
|
||
specifically identified as the opinions or policy
|
||
of Steve Jackson Games Incorporated, are only those
|
||
of the person posting them. SJ Games will do its
|
||
best to remove any false, harmful or otherwise
|
||
obnoxious material posted, but accepts no
|
||
responsibility for material placed on this board
|
||
without its knowledge.
|
||
(k) The Illuminati BBS also provided private
|
||
conferences that were accessible only to certain
|
||
users authorized by SJG and not to the general
|
||
public. All communications transmitted to these
|
||
conferences were stored in the Illuminati computer
|
||
at SJG.
|
||
(l) The Illuminati BBS provided a private
|
||
electronic mail (e-mail) service, which permitted
|
||
the transmission of private communications between
|
||
users on the system as follows:
|
||
(i) E-mail transmitted to an account on the
|
||
Illuminati BBS was stored on the BBS computer until
|
||
deleted by the addressee.
|
||
(ii) The privacy of e-mail was secured by the
|
||
use of passwords.
|
||
(iii) The privacy of e-mail was also secured by
|
||
computer software that prevented the system
|
||
operator from reading e-mail inadvertently.
|
||
(iv) The privacy of e-mail was also secured by
|
||
SJG policy. SJG informed users of the Illuminati
|
||
BBS that "[e]lectronic mail is private."
|
||
(v) As a matter of policy, practice, and
|
||
customer expectations, SJG did not read e-mail
|
||
addressed to Illuminati users other than SJG.
|
||
(vi) At all relevant times, all plaintiffs used
|
||
the e-mail service on the Illuminati BBS.
|
||
(vii) On March 1, 1990, the Illuminati computer
|
||
contained stored e-mail sent to or from each of the
|
||
plaintiffs.
|
||
The Illegal Warrant and Application
|
||
19. On February 28, 1990, defendant Foley
|
||
filed an application with this Court, for a warrant
|
||
authorizing the search of the business premises of
|
||
SJG and seizure of "[c]omputer hardware (including,
|
||
but not limited to, central processing unit(s),
|
||
monitors, memory devices, modem(s), programming
|
||
equipment, communication equipment, disks, and
|
||
prints) and computer software (including, but not
|
||
limited to, memory disks, floppy disks, storage
|
||
media) and written material and documents relating
|
||
to the use of the computer system (including
|
||
networking access files), documentation relating to
|
||
the attacking of computers and advertising the
|
||
results of computer attacks (including telephone
|
||
numbers and location information), and financial
|
||
documents and licensing documentation relative to
|
||
the computer programs and equipment at the business
|
||
known as Steve Jackson Games which constitute
|
||
evidence, instrumentalities and fruits of federal
|
||
crimes, including interstate transportation of
|
||
stolen property (18 USC 2314) and interstate
|
||
transportation of computer access information (18
|
||
USC 1030(a)(6)). This warrant is for the seizure
|
||
of the above described computer and computer data
|
||
and for the authorization to read information
|
||
stored and contained on the above described
|
||
computer and computer data."
|
||
A copy of the application and supporting affidavit
|
||
of defendant Foley (hereafter "Foley affidavit")
|
||
are attached as Exhibit "A" and incorporated herein
|
||
by reference.
|
||
20. The search warrant was sought as part of
|
||
an investigation being conducted jointly by
|
||
defendant Cook and the United States Attorney's
|
||
office in Chicago; defendants Foley, Golden, and
|
||
the Chicago field office of the United States
|
||
Secret Service; and defendant Kluepfel.
|
||
21. On information and belief, neither SJG
|
||
nor Jackson nor any of the plaintiffs were targets
|
||
of this investigation.
|
||
22. The Foley affidavit was based on the
|
||
investigation of defendant Foley and on information
|
||
and investigative assistance provided to him by
|
||
others, including defendants Golden and Kluepfel
|
||
and unnamed agents of the United States Secret
|
||
Service. Foley Affidavit para. 3.
|
||
23. The Foley affidavit alleged that
|
||
defendant Klu%p}el had participated in the
|
||
execution of numerous federal and state search
|
||
warrants. Id.
|
||
24. On information and belief, Defendant Cook
|
||
participated in the drafting, review, and
|
||
submission of the warrant application and
|
||
supporting affidavit to this Court.
|
||
25. The warrant application and supporting
|
||
affidavit were placed under seal on motion of the
|
||
United States.
|
||
26. On February 28, 1990, based on the Foley
|
||
affidavit, a United States Magistrate for the
|
||
Western District of Texas granted defendant Foley's
|
||
warrant application and issued awarrant authorizing
|
||
the requested search and seizure described in
|
||
paragraph 19 above. A copy of the search warrant
|
||
is attached as Exhibit B.
|
||
27. The warrant was facially invalid for the
|
||
following reasons:
|
||
(a) It was a general warrant that failed to
|
||
describe the place to be searched with
|
||
particularity.
|
||
(b) It was a general warrant that failed to
|
||
describe things to be seized with particularity.
|
||
(c) It swept within its scope handwritten,
|
||
typed, printed, and electronically stored
|
||
communications, work product, documents, and
|
||
publications protected by the First Amendment.
|
||
(d) It swept within its scope SJG proprietary
|
||
information and business records relating to
|
||
activities protected by the First Amendment.
|
||
(e) It swept within its scope a BBS that was a
|
||
forum for speech and association protected by the
|
||
First Amendment.
|
||
(f) It swept within its scope computer hardware
|
||
and software that were used by SJG to publish
|
||
books, magazines, and games.
|
||
(g) It swept within its scope computer hardware
|
||
and software used by SJG to operate a BBS.
|
||
28. The warrant was also invalid in that it
|
||
authorized the seizure of work product and
|
||
documentary materials from apublisher "reasonably
|
||
believed to have a purpose to disseminate to the
|
||
public a newspaper, book, broadcast, or other
|
||
similar form of public communication, in or
|
||
affecting interstate or foreign commerce," which is
|
||
generally prohibited by 42 U.S.C. 2000aa(a) and
|
||
(b), without showing the existence of any of the
|
||
narrow statutory exceptions in which such a search
|
||
and seizure is permitted. Specifically, the Foley
|
||
affidavit did not establish the existence of any of
|
||
the following circumstances:
|
||
(a) The Foley affidavit did not establish
|
||
probable cause to believe that SJG, or any employee
|
||
in possession of work product materials at SJG, had
|
||
committed or was committing a criminal offense to
|
||
which such materials related.
|
||
(b) The Foley affidavit did not establish
|
||
probable cause to believe that SJG or any employee
|
||
of SJG in possession of work product materials at
|
||
SJG, had committed or was committing a criminal
|
||
offense to which such materials related consisting
|
||
of other than the receipt possession,
|
||
communication, or withholding of such materials or
|
||
the information contained therein.
|
||
(c) The Foley affidavit did not establish
|
||
probable cause to believe that SJG, or any employee
|
||
of SJG in possession of work product materials at
|
||
SJG, had committed or was committing a criminal
|
||
offense consisting of the receipt, possession, or
|
||
communicationof information relating to the
|
||
national defense, classified information, or
|
||
restricted data under the provisions of 18 U.S.C.
|
||
793, 794, 797, or 798 or 50 U.S.C. 783.
|
||
(d) The Foley affidavit did not establish reason
|
||
to believe that immediate seizure of work product
|
||
materials from SJG was necessary to prevent the
|
||
death of, or serious bodily injury to, a human
|
||
being.
|
||
(e) The Foley affidavit did not establish
|
||
probable cause to believe that SJG, or any employee
|
||
of SJG in possession of documentary materials at
|
||
SJG, had committed or was committing a criminal
|
||
offense to which the materials related.
|
||
(f) The Foley affidavit did not establish
|
||
probable cause to believe that SJG, or any employee
|
||
of SJG in possession of documentary materials at
|
||
SJG had committed or was committing a criminal
|
||
offense to which the materials related consisting
|
||
of other than the receipt, possession,
|
||
communication, or withholding of such materials or
|
||
the information contained therein.
|
||
(g) The Foley affidavit did not establish
|
||
probable cause to believe that SJG, or any employee
|
||
of SJG in possession of documentary materials at
|
||
SJG, had committed or was committing an offense
|
||
consisting of the receipt, possession, or
|
||
communication of information relating to the
|
||
national defense, classifiedinformation, or
|
||
restricted data under the provisions of 18 U.S.C.
|
||
793, 794, 797, or 798 or 50 U.S.C. 783.
|
||
(h) The Foley affidavit did not establish
|
||
reason to believe that the immediate seizure of
|
||
such documentary materials was necessary to prevent
|
||
the death of, or serious bodily injury to, a human
|
||
being.
|
||
(i) The Foley affidavit did not establish
|
||
reason to believe that the giving of notice
|
||
pursuant to a subpoena duces tecum would result in
|
||
the destruction, alteration, or concealment of such
|
||
documentary materials.
|
||
(j) The Foley affidavit did not establish that
|
||
such documentary materials had not been produced in
|
||
response to a court order directing compliance with
|
||
a subpoena duces tecum and that all appellate
|
||
remedies had been exhausted or that there was
|
||
reason to believe that the delay in an
|
||
investigation or trial occasioned by further
|
||
proceedings relating to the subpoena would threaten
|
||
the interests of justice.
|
||
29. The warrant was invalid because the
|
||
warrant application and supporting affidavit of
|
||
defendant Foley did not establish probable cause to
|
||
believe that the business premises of SJG was a
|
||
place where evidence of criminal activity would be
|
||
found, in that:
|
||
(a) The Foley affidavit did not allege that
|
||
evidence of criminal activity would be found at
|
||
SJG. Rather, the affidavit alleged that "E911
|
||
source code and text file"and a "decryption
|
||
software program" would be "found in the computers
|
||
located at 1517G Summerstone, Austin, Texas, or at
|
||
2700-A Metcalfe Road, Austin, Texas [SJG], or at
|
||
3524 Graystone #192, or in the computers at each of
|
||
those locations." Foley Affidavit para. 30
|
||
(emphasis added).
|
||
(b) The Foley affidavit did not establish
|
||
probable cause to believe that E911 source code
|
||
would be found at the business premises of SJG.
|
||
(c) The Foley affidavit did not establish
|
||
probable cause to believe that an E911 text file
|
||
would be found at the business premises of SJG.
|
||
(d) The Foley affidavit did not establish
|
||
probable cause to believe that a decryption
|
||
software program would be found at the business
|
||
premises of SJG.
|
||
30. Even assuming, arguendo, that the warrant
|
||
affidavit demonstrated probable cause to believe
|
||
that "E911 source code and text file" and a
|
||
"password decryption program" would be found at the
|
||
business premises of SJG, the warrant was still
|
||
invalid because its description of items to be
|
||
seized was broader than any probable cause shown,
|
||
in that:
|
||
(a) The warrant authorized the seizure of
|
||
computer hardware, software, and documentation that
|
||
did not constitute evidence, instrumentalities, or
|
||
fruits of criminal activity;
|
||
(b) The warrant authorized the seizure and
|
||
reading of electronically stored data, including
|
||
publications, work product, proprietary
|
||
information, business records, personnel records,
|
||
and correspondence, that did not constitute
|
||
evidence, instrumentalities, or fruits of criminal
|
||
activity;
|
||
(c) The warrant authorized the seizure and
|
||
reading of electronically stored communications
|
||
that were not accessible to the public, including
|
||
private electronic mail, and that did not
|
||
constitute evidence, instrumentalities, or fruits
|
||
of criminal activity.
|
||
31. The warrant is invalid because there is
|
||
nothing in the Foley affidavit to show that the
|
||
information provided by defendant Kluepfel
|
||
regarding the BBS at SJG was not stale.
|
||
32. The warrant was invalid because the Foley
|
||
affidavit was materially false and misleading, and
|
||
because defendants submitted it knowing it was
|
||
false and misleading or with reckless disregard for
|
||
the truth, as set forth in paragraphs 33-40 below.
|
||
33. The Foley affidavit did not inform the
|
||
Magistrate that SJG was a publisher of games,
|
||
books, and magazines, engaged in the business of
|
||
preparing such materials for public dissemination
|
||
in or affecting interstate commerce;
|
||
(a) This omission was material;
|
||
(b) Defendants omitted this material information
|
||
>from the warrant application knowingly or with
|
||
reckless disregard for the truth or falsity of the
|
||
application.
|
||
34. The Foley affidavit did not inform the
|
||
Magistrate that SJG used computers to compose and
|
||
prepare publications for public dissemination;
|
||
(a) This omission was material;
|
||
(b) Defendants omitted this material information
|
||
>from the warrant application knowingly or with
|
||
reckless disregard for the truth or falsity of the
|
||
application.
|
||
35. The Foley affidavit did not inform the
|
||
Magistrate that the computer at SJG used to operate
|
||
the BBS contained electronically stored texts, work
|
||
product, documentary materials, and communications
|
||
stored for the purpose of public dissemination in
|
||
or affecting interstate commerce;
|
||
(a) This omission was material;
|
||
(b) Defendants omitted this material information
|
||
>from the warrant application knowingly or with
|
||
reckless disregard for the truth or falsity of the
|
||
application.
|
||
36. The Foley affidavit did not inform the
|
||
Magistrate that a computer used to operate the BBS
|
||
at SJG operated a forum for constitutionally
|
||
protected speech and association regarding
|
||
adventure games and related literary genres;
|
||
(a) This omission was material;
|
||
(b) Defendants omitted this material information
|
||
>from the warrant application knowingly or with
|
||
reckless disregard for the truth or falsity of the
|
||
application.
|
||
37. The Foley affidavit did not inform the
|
||
Magistrate that the computer used to operate the
|
||
BBS at SJG contained stored private electronic
|
||
communications;
|
||
(a) This omission was material;
|
||
(b) Defendants omitted this material information
|
||
>from the warrant application knowingly or with
|
||
reckless disregard for the truth or falsity of the
|
||
application.
|
||
38. The Foley affidavit falsely alleged that
|
||
the E911 text file was a "program." Foley Affidavit
|
||
paras. 8, 14, 17; (a) This false allegation
|
||
was material;
|
||
(b) Defendants made this material false
|
||
allegation knowingly or with reckless disregard for
|
||
its truth or falsity;
|
||
(c) Defendants Cook and Foley have acknowledged
|
||
that the E911 text file is not a program.
|
||
39. The affidavit of defendant Foley falsely
|
||
alleges that the information in the E911 text file
|
||
was "highly proprietary" and "sensitive". Foley
|
||
Affidavit paras. 13, 14, 22;
|
||
(a) This false allegation was material;
|
||
(b) Defendants made this material false
|
||
allegation knowingly or with reckless disregard for
|
||
its truth or falsity;
|
||
(c) Defendant Cook has acknowledged that much of
|
||
the information in the E911 text file had been
|
||
disclosed to the public.
|
||
40. The affidavit of defendant Foley falsely
|
||
alleges that the E911 text file was "worth
|
||
approximately $79,000.00," para. 4, and "engineered
|
||
at a cost of $79,449.00," para. 14;
|
||
(a) This false allegation was material;
|
||
(b) Defendants made this material false
|
||
allegation knowingly or with reckless disregard for
|
||
its truth or falsity;
|
||
(c) Defendant Cook has acknowledged that the
|
||
value of the nondisclosed information in the E911
|
||
text file was less than the $5000.00 jurisdictional
|
||
minimum for Interstate Transportation of Stolen
|
||
Property, 18 U.S.C. 2314.
|
||
41. Reasonable persons in defendants'
|
||
position would have known that the warrant was
|
||
invalid for the reasons given in paragraphs 27-40
|
||
and would not have requested or relied on the
|
||
warrant.The Search and Seizure:
|
||
42. Nevertheless, on March 1, 1990, defendant
|
||
Golden, other agents of the United States Secret
|
||
Service, and others acting in concert with them,
|
||
conducted a general search of the SJG office and
|
||
warehouse.
|
||
43. The searching officers prevented SJG
|
||
employees from entering their workplace or
|
||
conducting any business from 8:00 a.m. until after
|
||
1:00 p.m. on March 1, 1990.
|
||
44. The agents seized computer hardware and
|
||
related documentation, including, but not limited
|
||
to, the following:
|
||
(a) three central processing units;
|
||
(b) hard drives;
|
||
(c) hundreds of disks;
|
||
(d 2 monitors;
|
||
(e) 3 keyboards;
|
||
(f) 3 modems;
|
||
(g) a printer;
|
||
(h) electrical equipment including, but not limited
|
||
to, extension cords, cables, and adapters;
|
||
(i) screws, nuts, and other small parts.
|
||
45. The agents seized all computer hardware,
|
||
computer software, and supporting documentation
|
||
used by SJG to run the Illuminati BBS, thereby
|
||
causing the following to occur:
|
||
(a) the seizure of all programs, text files, and
|
||
public communications stored on the BBS computer;
|
||
(b) the seizure of all private electronic
|
||
communications stored on the system, including
|
||
electronic mail;
|
||
(c) preventing plaintiffs from operating and
|
||
using the BBS.
|
||
46. The agents seized computer software and
|
||
supporting documentation that SJG used in the
|
||
ordinary course of its business including, but not
|
||
limited to, word processing software.
|
||
47. The defendants seized all data stored on
|
||
the seized SJG computers and disks, including, but
|
||
not limited to, the following:
|
||
(a) SJG work product, including drafts of
|
||
forthcoming publications and games;
|
||
(b) Communications from customers and others
|
||
regarding SJG's games, books, and magazines;
|
||
(c) SJG financial projections;
|
||
(d) SJG contracts;
|
||
(e) SJG correspondence;
|
||
(f) SJG editorial manual, containing
|
||
instructions and procedures for writers and
|
||
editors;
|
||
(g) SJG address directories, contacts lists, and
|
||
employee information, including the home telephone
|
||
numbers of SJG employees.
|
||
48. The defendants seized all current drafts
|
||
-- both electronically stored copies and printed
|
||
("hard") copies -- of the book GURPS Cyberpunk,
|
||
which was scheduled to go to the printer later that
|
||
week.
|
||
(a) GURPS Cyberpunk was part of a series of
|
||
fantasy roleplaying game books published by SJG
|
||
called the Generic Universal Roleplaying System.
|
||
(b) The term "Cyberpunk" refers to a science
|
||
fiction literary genre which became popular in the
|
||
1980s. The Cyberpunk genre is characterized by the
|
||
fictional interaction of humans with technology and
|
||
the fictional struggle for power between
|
||
individuals, corporations, and government. One of
|
||
the most popular examples of the Cyberpunk genre is
|
||
William Gibson's critically acclaimed science
|
||
fiction novel Neuromancer, which was published in
|
||
1984.
|
||
(c) GURPS Cyberpunk is a fantasy roleplaying
|
||
game book of the Cyberpunk genre.
|
||
(d) SJG eventually published the book GURPS
|
||
Cyberpunk in 1990.
|
||
(e) The book has been distributed both
|
||
nationally and internationally.
|
||
(f) To date SJG has sold over 16,000 copies of
|
||
the book.
|
||
(g) The book has been nominated for an Origins
|
||
Award for Best Roleplaying Supplement.
|
||
(h) The book is used in at least one college
|
||
literature course as an example of the Cyberpunk
|
||
genre.
|
||
49. The search and seizure exceeded the scope
|
||
of the warrant, in that the searching officers
|
||
seized computer hardware, computer software, data,
|
||
documentation, work product, and correspondence
|
||
that did not constitute evidence, instrumentalities
|
||
or fruits of any crime.
|
||
50. The search was conducted in a reckless
|
||
and destructive fashion, in that the searching
|
||
officers caused damage to SJG property and left the
|
||
SJG office and warehouse in disarray.
|
||
Post-seizure Retention of Property
|
||
51. Plaintiffs Jackson and SJG put defendants
|
||
on immediate notice that they had seized the
|
||
current drafts of the about-to-be-published book
|
||
GURPS Cyberpunk and the computer hardware and
|
||
software necessary to operate a BBS and requested
|
||
immediate return of these materials.
|
||
52. SJG and Jackson made diligent efforts to
|
||
obtain the return of the seized equipment and data,
|
||
including but not limited to, retention of legal
|
||
counsel, numerous telephone calls to defendants
|
||
Cook and Foley by Jackson and SJG counsel, a trip
|
||
to the Austin Secret Service office, and
|
||
correspondence with defendants Cook and Foley and
|
||
with other federal officials.
|
||
53. On March 2, 1990, Jackson went to the
|
||
Austin office of the Secret Service in an
|
||
unsuccessful attempt to obtain the return of seized
|
||
documents and computer data, including the drafts
|
||
of the forthcoming book GURPS Cyberpunk and the
|
||
software and files stored on the Illuminati BBS.
|
||
54. On March 2, 1990, the Secret Service
|
||
refused to provide Jackson with the files
|
||
containing current drafts of GURPS Cyberpunk, one
|
||
agent calling the book a "handbook for computer
|
||
crime."
|
||
55. On March 2, 1990, the Secret Service also
|
||
refused to return copies of the software used to
|
||
run the Illuminati BBS and copies of any of the
|
||
data or communications stored on the BBS.
|
||
56. In the months following the seizure,
|
||
defendant Cook repeatedly gave Jackson and his
|
||
counsel false assurances that the property of SJG
|
||
would be returned within days.
|
||
57. In May of 1990, Jackson wrote to Senators
|
||
Philip Gramm and Lloyd Bentsen and Congressman J.
|
||
J. Pickle, regarding the search and seizure
|
||
conducted at SJG and requesting their assistance in
|
||
obtaining the return of SJG property.
|
||
58. On June 21, 1990, the Secret Service
|
||
returned most, but not all, of the computer
|
||
equipment that had been seized from SJG over three
|
||
months earlier.
|
||
59. The Secret Service did not return some of
|
||
SJG's hardware and data.
|
||
60. The Secret Service did not return any of
|
||
the printed drafts of GURPS Cyberpunk.
|
||
61. In July 3, 1990, letters to Senator
|
||
Bentsen and Congressman J. J. Pickle, Robert R.
|
||
Snow of the United States Secret Service falsely
|
||
stated that all of the items seized from SJG had
|
||
been returned to Jackson.
|
||
62. In his July 16, 1990, letter to Senator
|
||
Gramm, Bryce L. Harlow of the United States
|
||
Department of Treasuryfalsely stated that all of
|
||
the items seized from SJG had been returned to
|
||
Jackson.
|
||
63. Through counsel, SJG wrote to defendant
|
||
Foley on July 13, 1990, requesting, inter alia, a
|
||
copy of the application for the search warrant and
|
||
return of the property the government had not
|
||
returned. A copy of this letter was mailed to
|
||
Defendant Cook. Though the letter requested a
|
||
response by August 1, 1990, neither defendant
|
||
responded.
|
||
64. Through counsel, plaintiff SJG again
|
||
wrote to defendant Cook on August 8, 1990,
|
||
requesting, inter alia, a copy of the application
|
||
for the search warrant and return of the property
|
||
the government had not returned. Copies of this
|
||
letter were sent to other Assistant United States
|
||
Attorneys in Chicago, namely Thomas Durkin, Dean
|
||
Polales, and Michael Shepard.
|
||
65. Defendant Cook responded to this request
|
||
with an unsigned letter dated August 10, 1990. The
|
||
letter enclosed a number of documents that had not
|
||
previously been returned to SJG. The letter
|
||
further stated that "the application for the search
|
||
warrant is under seal with the United States
|
||
District Court in Texas since it contains
|
||
information relating to an ongoing federal
|
||
investigation."
|
||
66. On September 17, 1990, the warrant
|
||
affidavit was unsealed by the United States
|
||
Magistrate for the Western District of Texas on the
|
||
motion of the United States Attorney for the
|
||
Northern District of Illinois.
|
||
67. The United States Attorney's office did
|
||
not provide Jackson, SJG or their counsel with
|
||
notice of its motion to unseal the warrant
|
||
affidavit or of this Court's order granting its
|
||
motion.
|
||
Prior Restraint on Publication and Other Damages:
|
||
68. Defendants' seizure and retention of the
|
||
computer hardware and software used to operate the
|
||
Illuminati BBS prevented and interfered with
|
||
plaintiffs' operation and use of the Illuminati
|
||
BBS, including the following:
|
||
(a) In an attempt to minimize the damage caused
|
||
by defendants' conduct, SJG purchased replacement
|
||
computer hardware and software to operate the
|
||
Illuminati BBS;
|
||
(b) As a result of defendants' conduct, SJG was
|
||
unable to operate or use the Illuminati BBS for
|
||
over a month;
|
||
(c) As a result of defendants' conduct,
|
||
plaintiffs were deprived of the use of the
|
||
Illuminati BBS for over a month;
|
||
(d) Defendants seized and intercepted electronic
|
||
mail in which plaintiffs had a reasonable
|
||
expectation of privacy;
|
||
(e) Users of the BBS were substantially chilled
|
||
in their exercise of their constitutionally
|
||
protected rights of freedom of speech and
|
||
association;
|
||
(f) Some of the data previously available to
|
||
users of the Illuminati BBS was lost or destroyed.
|
||
69. Defendants' conduct caused a prior
|
||
restraint of the publication of the book GURPS
|
||
Cyberpunk, in that:
|
||
(a) On March 1, 1990, the book GURPS Cyberpunk
|
||
was nearly completed and scheduled to be sent to
|
||
the printer the following week;
|
||
(b) On March 1, 1990, defendants caused the
|
||
illegal seizure of all of the current drafts of
|
||
GURPS Cyberpunk, including both printed drafts and
|
||
electronically stored drafts.
|
||
(c) On March 1, 1990, Defendants caused the
|
||
illegal seizure of electronic communications stored
|
||
on the Illuminati BBS containing comments on GURPS
|
||
Cyberpunk.
|
||
(d) Defendants unreasonably refused for weeks to
|
||
return the electronically stored drafts of GURPS
|
||
Cyberpunk.
|
||
(e) Defendants have not yet returned the printed
|
||
drafts of GURPS Cyberpunk.
|
||
(f) Defendants refused to return electronically
|
||
stored comments regarding GURPS Cyberpunk for over
|
||
three months.
|
||
(g) By their conduct, defendants prevented SJG
|
||
>from delivering GURPS Cyberpunk to the printer on
|
||
schedule, and caused SJG to miss its publication
|
||
deadline.
|
||
(h) As a result of defendants' conduct, and in
|
||
an attempt to minimize damages, SJG and its
|
||
employeesreconstructed and rewrote GURPS Cyberpunk
|
||
>from older drafts.
|
||
(i) As a result of defendants' conduct, the
|
||
publication of GURPS Cyberpunk was delayed for six
|
||
weeks.
|
||
70. Defendants' conduct caused substantial
|
||
delay in the publication and delivery of other SJG
|
||
publications.
|
||
71. As a result of defendants' conduct, SJG
|
||
suffered substantial financial harm including, but
|
||
not limited to, lost sales, lost credit lines,
|
||
interest on loans, late payment penalties, and
|
||
attorney's fees and costs.
|
||
72. As a result of defendants' conduct, SJG
|
||
was forced to lay off 8 of its 17 employees.
|
||
73. As a result of defendants' conduct, SJG
|
||
suffered damage to its business reputation.
|
||
74. As a result of defendants' conduct, SJG
|
||
has suffered loss of, damage to, and conversion of
|
||
computer equipment and data, including, but not
|
||
limited to, the following:
|
||
(a) loss of and damage to computer hardware;
|
||
(b) loss and destruction of seized data;
|
||
75. Defendants have retained copies of data seized
|
||
>from SJG.
|
||
76. As a result of defendants' conduct,
|
||
plaintiff Steve Jackson has suffered additional
|
||
harm including, but not limited to, lost income,
|
||
damage to professional reputation,humiliation,
|
||
invasion of privacy, deprivation of constitutional
|
||
rights, and emotional distress.
|
||
77. As a result of defendants' conduct,
|
||
plaintiffs McCoy, Milliken, and O'Sullivan have
|
||
suffered additional harm including, but not limited
|
||
to, damages resulting from the seizure of their
|
||
private electronic mail and the interference with,
|
||
and temporary shut down of, the Illuminati forum
|
||
for speech and association, deprivation of their
|
||
constitutional rights, invasion of their privacy,
|
||
and emotional distress.
|
||
|
||
COUNT I:
|
||
PRIVACY PROTECTION ACT OF 1980,
|
||
42 U.S.C. 2000aa et seq
|
||
Against the United States Secret Service
|
||
and the United States of America
|
||
|
||
78. The allegations in paragraphs 1-77 are
|
||
incorporated herein by reference.
|
||
79. At all relevant times, SJG and its
|
||
employees were persons "reasonably believed to have
|
||
a purpose to disseminate to the public a newspaper,
|
||
book, broadcast, or other similar form of public
|
||
communication, in or affecting interstate or
|
||
foreign commerce" within the meaning of 42 U.S.C.
|
||
2000aa(a) and (b).
|
||
80. At all relevant times, SJG and its
|
||
employees possessed work product and documentary
|
||
materials in connection with a purpose to
|
||
disseminate to the public a newspaper, book,
|
||
broadcast, or other similar form of
|
||
publiccommunication, in or affecting interstate or
|
||
foreign commerce.
|
||
81. Defendants caused the submission of an
|
||
application for a warrant to search the business
|
||
premises of SJG and to seize work product materials
|
||
therefrom, in violation of 42 U.S.C. 2000aa, in
|
||
that:
|
||
(a) The Foley affidavit did not inform the
|
||
Magistrate that SJG and its employees were persons
|
||
"reasonably believed to have a purpose to
|
||
disseminate to the public a newspaper, book,
|
||
broadcast, or other similar form of public
|
||
communication, in or affecting interstate or
|
||
foreign commerce" within the meaning of 42 U.S.C.
|
||
2000aa(a) and (b).
|
||
(b) The Foley affidavit did not inform the
|
||
Magistrate that SJG and its employees possessed
|
||
work product materials and documentary materials in
|
||
connection with a purpose to disseminate to the
|
||
public a newspaper, book, broadcast, or other
|
||
similar form of public communication, in or
|
||
affecting interstate or foreign commerce.
|
||
(c) The Foley affidavit did not establish that
|
||
any of the exceptions to the statutory prohibition
|
||
of searches and seizures set out in 42 U.S.C.
|
||
2000aa(a) and (b) existed.
|
||
82. Defendants caused the March 1, 1990,
|
||
search of the business premises of SJG and seizure
|
||
of work product anddocumentary materials therefrom
|
||
in violation of 42 U.S.C. 2000aa et seq.
|
||
83. Defendants Cook, Foley, and Golden were
|
||
federal officers and employees acting within the
|
||
scope or under color of federal office or
|
||
employment.
|
||
84. Defendant Kluepfel acted in concert with
|
||
federal agents under color of federal office.
|
||
85. Plaintiffs SJG, Jackson, McCoy, Milliken,
|
||
and O'Sullivan are all persons aggrieved by
|
||
defendants' conduct, having suffered damages,
|
||
attorney's fees, and costs, as a direct result of
|
||
defendants' conduct.
|
||
86. The United States of American and the
|
||
United States Secret Service are liable to
|
||
plaintiffs for damages, attorney's fees and costs
|
||
caused by defendants' conduct.
|
||
|
||
COUNT II:
|
||
FIRST AMENDMENT
|
||
Against Defendants Cook, Foley, Golden & Kluepfel
|
||
|
||
87. The allegations in paragraphs 1-86 are
|
||
incorporated herein by reference.
|
||
88. Defendants violated plaintiffs' rights to
|
||
freedom of speech, freedom of the press, and
|
||
freedom of association as guaranteed by the First
|
||
Amendment, in that:
|
||
(a) At all relevant times SJG was a publisher of
|
||
books, magazines, and games protected by the First
|
||
Amendment;
|
||
(b) At all relevant times SJG was the operator
|
||
of a BBS that was a forum for speech and
|
||
association protected by the First Amendment;
|
||
(c) At all relevant times, plaintiffs SJG,
|
||
Jackson, McCoy, Milliken, and O'Sullivan used the
|
||
Illuminati BBS for speech and association protected
|
||
by the First Amendment;
|
||
(d) At all relevant times, plaintiff SJG used
|
||
computers to publish books, magazines, and games
|
||
and to operate the Illuminati BBS;
|
||
(e) The search, seizure, and retention of SJG
|
||
work product--both printed and electronically
|
||
stored--caused a prior restraint on SJG
|
||
publications in violation of plaintiffs' First
|
||
Amendment rights of freedom of speech and of the
|
||
press;
|
||
(f) The search and seizure of the Illuminati BBS
|
||
constituted a prior restraint on plaintiffs'
|
||
exercise of their First Amendment rights of freedom
|
||
of speech, of the press, and of association;
|
||
(g) The seizure and retention of computer
|
||
hardware and software used by SJG to publish books,
|
||
magazines, and games violated plaintiffs' rights to
|
||
freedom of speech and of the press;
|
||
(h) The seizure and retention of computer
|
||
hardware and software used by SJG to operate a BBS
|
||
violatedplaintiffs' First Amendment rights to
|
||
freedom of speech, of the press, and of
|
||
association.
|
||
89. Defendants knew or reasonably should have
|
||
known that their conduct violated plaintiffs'
|
||
clearly established First Amendment rights of
|
||
freedom of speech, freedom of the press, and
|
||
freedom of association.
|
||
90. Defendants acted with intent to violate,
|
||
or with reckless indifference to, plaintiffs'
|
||
clearly established First Amendment rights to
|
||
freedom of speech, freedom of the press, and
|
||
freedom of association.
|
||
91. Defendants Cook, Foley, and Golden acted
|
||
as federal agents and under color of federal law.
|
||
92. Defendant Kluepfel acted in concert with
|
||
the federal defendants under color of federal law.
|
||
93. As a direct result of the defendants'
|
||
conduct, plaintiffs have suffered damages.
|
||
|
||
COUNT III:
|
||
FOURTH AMENDMENT
|
||
Against Defendants Cook, Foley, Golden, and
|
||
Kluepfel
|
||
|
||
94. The allegations in paragraphs 1-93 are
|
||
incorporated herein by reference.
|
||
95. The defendants, by their actions,
|
||
violated plaintiffs' clearly established right to
|
||
be free from unreasonable searches and seizures as
|
||
guaranteed by the Fourth Amendment to the United
|
||
States Constitution, in that:
|
||
(a) Plaintiffs SJG and Jackson had a reasonable
|
||
expectation of privacy in the business premises of
|
||
SJG and in all SJG work product, SJG records, and
|
||
SJG documents kept there, including in all data
|
||
stored in the computers at SJG;
|
||
(b) All plaintiffs had a reasonable expectation
|
||
of privacy in private electronic communications
|
||
stored on the Illuminati BBS at SJG;
|
||
(c) The search and seizure at SJG games was a
|
||
general search;
|
||
(d) The search and seizure at SJG was not
|
||
authorized by a valid warrant particularly
|
||
describing the place to be searched and the things
|
||
to be seized;
|
||
(e) The search and seizure at SJG was conducted
|
||
without probable cause to believe that evidence of
|
||
criminal activity would be found at SJG;
|
||
(f) The search and seizure at SJG was based on
|
||
information that was not shown to be current;
|
||
(g) Defendants' warrant application was
|
||
materially false and misleading, and was submitted
|
||
by defendants with knowledge of its false and
|
||
misleading nature or with reckless disregard for
|
||
its truth or falsity.
|
||
96. The defendants knew, or reasonably should
|
||
have known, that their conduct violated plaintiffs'
|
||
clearly established constitutional right to be free
|
||
>from unreasonable searches and seizures.
|
||
97. The defendants acted with intent to
|
||
violate, or with reckless indifference to,
|
||
plaintiffs' clearly established Fourth Amendment
|
||
rights.
|
||
98. Defendants Cook, Foley, and Golden acted
|
||
as federal agents and under color of federal law.
|
||
99. Defendant Kluepfel acted in concert with
|
||
the federal defendants and under color of federal
|
||
law.
|
||
100. As a direct result of the defendants'
|
||
actions, plaintiffs suffered damages, attorney's
|
||
fees and costs.
|
||
|
||
COUNT IV:
|
||
ELECTRONIC COMMUNICATIONS PRIVACY ACT,
|
||
18 U.S.C. 2707
|
||
Seizure of Stored Electronic Communications
|
||
Against All Defendants
|
||
|
||
101. The allegations in paragraphs 1-100 are
|
||
incorporated herein by reference.
|
||
102. At all times relevant times, plaintiff
|
||
SJG was the provider of an electronic communication
|
||
service within the meaning of 18 U.S.C. 2510(15)
|
||
and 2707.
|
||
103. At all relevant times, plaintiffs SJG,
|
||
Jackson, McCoy, Milliken, and O'Sullivan were
|
||
subscribers to or customers of the electronic
|
||
communication service provided by SJG within the
|
||
meaning of 18 U.S.C. 2510(15) and 2707.
|
||
104. At all relevant times, plaintiffs had
|
||
electronic communications in electronic storage on
|
||
the communicationservice provided by SJG that were
|
||
not accessible to the general public.
|
||
105. Defendants applied for a warrant to
|
||
search and seize the computer operating the
|
||
electronic communication service provided by SJG
|
||
and all data stored thereon, but failed to inform
|
||
the Magistrate that the computer contained stored
|
||
electronic communications that were not accessible
|
||
to the general public.
|
||
106. Defendants, acting without a valid
|
||
warrant, required SJG to disclose the contents of
|
||
electronic communications that were not accessible
|
||
to the general public and that were in electronic
|
||
storage for 180 days or less, in violation of 18
|
||
U.S.C. 2703(a).
|
||
107. Defendants disrupted the normal
|
||
operations of the communication service operated by
|
||
SJG without compensation to plaintiffs in violation
|
||
of 18 U.S.C. 2706(a).
|
||
108. Defendants Cook, Foley, and Golden acted
|
||
as federal agents and under color of federal law.
|
||
109. Defendant Kluepfel acted in concert with
|
||
the federal defendants and under color of federal
|
||
law.
|
||
110. Defendants acted knowingly and
|
||
intentionally.
|
||
111. Defendants did not act in good faith.
|
||
112. Plaintiffs were aggrieved by defendants'
|
||
conduct, and suffered damages, attorney's fees and
|
||
costs.
|
||
|
||
COUNT V:
|
||
ELECTRONIC COMMUNICATIONS PRIVACY ACT,
|
||
18 U.S.C. 2510 et seq.
|
||
Interception of Electronic Communications
|
||
Against All Defendants
|
||
|
||
113. The allegations in paragraphs 1-112 are
|
||
incorporated herein by reference.
|
||
114. Defendants intercepted, disclosed, or
|
||
intentionally used plaintiffs' electronic
|
||
communications in violation of 18 U.S.C. 2510 et
|
||
seq and 2520.
|
||
115. Defendants intentionally intercepted,
|
||
endeavored to intercept, or procured others to
|
||
intercept or endeavor to intercept, plaintiffs'
|
||
electronic communications in violation of 18 U.S.C.
|
||
2511(1)(a).
|
||
116. Defendants did not comply with the
|
||
standards and procedures prescribed in 18 U.S.C.
|
||
2518.
|
||
117. The warrant application was not
|
||
authorized by the Attorney General, Deputy Attorney
|
||
General, Associate Attorney General, or any
|
||
Assistant Attorney general, acting Assistant
|
||
Attorney General, or any Deputy Assistant Attorney
|
||
General in the Criminal Division specially
|
||
designated by the Attorney General, in violation of
|
||
18 U.S.C. 2516.
|
||
118. Defendants Cook, Foley, and Golden acted
|
||
as federal agents and under color of federal law.
|
||
119. Defendant Kluepfel acted in concert with
|
||
the federal defendants and under color of federal
|
||
law.
|
||
120. Defendants did not act in good faith.
|
||
121. Defendants did not compensate plaintiffs
|
||
for reasonable expenses incurred by defendants'
|
||
seizure of the Illuminati BBS, in violation of 18
|
||
U.S.C. 2518(4).
|
||
122. As a direct result of defendants'
|
||
conduct, plaintiffs suffered damages, attorney's
|
||
fees and costs.
|
||
Prayers for Relief
|
||
WHEREFORE, plaintiffs SJG, Jackson, McCoy,
|
||
Milliken, and O'Sullivan pray that this Court:
|
||
1. Assume jurisdiction of this case.
|
||
2. Enter judgment against defendants and in
|
||
favor of plaintiffs.
|
||
3. Enter an order requiring defendants to
|
||
return all property and data seized from the
|
||
premises of SJG, and all copies of such data, to
|
||
SJG.
|
||
4. Award plaintiffs damages.
|
||
5. Award plaintiffs punitive and liquidated
|
||
damages.
|
||
6. Award plaintiffs all costs incurred in the
|
||
prosecution of this action, including reasonable
|
||
attorney's fees.
|
||
7. Provide such additional relief as may
|
||
appear to the Court to be just.
|
||
|
||
|
||
|
||
|
||
|
||
PLAINTIFFS DEMAND A JURY TRIAL ON ALL CLAIMS
|
||
TRIABLE BY JURY
|
||
Dated: May 1, 1991
|
||
|
||
|
||
Respectfully submitted
|
||
by their attorneys,
|
||
|
||
|
||
|
||
|
||
_____________________________
|
||
Sharon L. Beckman
|
||
Harvey A. Silverglate
|
||
Andrew Good
|
||
SILVERGLATE & GOOD
|
||
89 Broad St., 14th floor
|
||
Boston, MA 02110
|
||
(617) 542-6663
|
||
Fax: (617) 451-6971
|
||
|
||
|
||
|
||
|
||
____________________________
|
||
Eric M. Lieberman
|
||
Nicholas E. Poser
|
||
Rabinowitz, Boudin, Standard,
|
||
Krinsky & Lieberman, P.C.
|
||
740 Broadway, at Astor Place
|
||
New York, NY 10003-9518
|
||
(212) 254-1111
|
||
Fax: (212) 674-4614
|
||
|
||
|
||
|
||
|
||
___________________________
|
||
R. James George, Jr.
|
||
Graves, Dougherty,
|
||
Hearon & Moody
|
||
2300 NCNB Tower
|
||
515 Congress Street
|
||
Austin, Texas 78701
|
||
(512) 480-5600
|
||
Fax: (512) 478-1976
|
||
|
||
====================================================================
|
||
|
||
|
||
|
||
/ /
|
||
/ File 07 / NIA071 /
|
||
/ Comments From Editors /
|
||
/ JD & LMcD /
|
||
/ /
|
||
|
||
|
||
Hello, welcome to the new issue NIA071. This issue was primarily to put out
|
||
things that do not go anywhere else. It is a collection of some text that
|
||
would not normaly fit into a normal issue.
|
||
|
||
We realize it has been quite some time between NIA070 and NIA071, we do
|
||
remind you that NIA is released on a non-scheduled basis. Rather, it is
|
||
released when we have enough material for a new issue. On that note, please
|
||
share what you have with the rest of the community. Submissions go to
|
||
elisem@nuchat.sccsi.com
|
||
|
||
We have received a lot of attention regarding Sir Hackalot's article in the
|
||
previous release. We appreciate your comments, but let us remind you that
|
||
we are editors, not censors. This file contained information useful not
|
||
only to the underground community but also to system administrators, operators
|
||
and users about general unix security. If this file was presented in an
|
||
offensive manner, than excuse us. It was not meant to please everybody.
|
||
|
||
In releasing issue 70, a problem with our maillist occured. We apologize
|
||
for anyone who was inconvenienced by this. The problem has been fixed.
|
||
|
||
Look for the new NIA072 coming out within the next month, it will be a
|
||
very informative issue. Also to add to this note, Phrack will be releasing
|
||
(hopefully) an issue in late May. To EFF, the best of luck in your case
|
||
against the SS. A final note, Doctor Dissector has officially retired but
|
||
can be reached at doctord@darkside.com
|
||
|
||
Submissions, questions, comments and subscriptions can be mailed to
|
||
elisem@nuchat.sccsi.com. Our files can be found on Ripco BBS and the
|
||
CuD archive server (Ref: CuD Newsletter).
|
||
|
||
"There's something about a beautiful woman without a brain in her head
|
||
that can still be exiting."
|
||
--Oliver Stone
|
||
|
||
JD & LMcD
|
||
Ignorance, There's No Excuse.
|
||
"Forcing the issue was always worth it."--Jello Biafra
|
||
NIA - Network Information Access
|
||
=============================================================================
|
||
|