The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 19 Issue 60

Friday 27 February 1998

Contents

o CyberAttack on the Pentagon
PGN
o Former Director of the NSA says "no" to key escrow
PGN
o Year 2100 compliance?
Tsutomu Shimomura
o COMPAQ usability problem
Pete Mellor
o Shuttle conversation; April already?
PGN
o First Cybersex Pregnancy
Anthony E. Scandora Jr.
o A little accidental porn-in-the-morn
PGN
o DES-II-1 challenge cracked
David McNett
o Re: Markus Kuhn and Ross Anderson's Soft Tempest
Lloyd Wood
o Risk: Massive NT Outage due to Registry corruption
Mike Andrews
o Airport Big Brother Blocks Buggies
Marcus J. Ranum
o Dennings' "Internet Besieged: Countering Cyberspace Scofflaws"
Rob Slade
o Info on RISKS (comp.risks)

CyberAttack on the Pentagon

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Fri, 27 Feb 1998 10:25:49 PST
  [This is pretty much what I said earlier this morning in an interview
  with James Glave of Wired News (something is expected to appear at
  http://www.wired.com), although I have extended it somewhat for RISKS.  PGN]

The operative phrase seems to be ``smoke and mirrors'' in the case of the
Pentagon HackAttack.  Yesterday we were told by John Hamre (Deputy Secretary
of Defense) that this attack was ``the most organized and systematic the
Pentagon has seen to date''.  Today we are told that it was just a bright
high-school kid (or maybe a few) who was able to penetrate so many systems.
Given the incredible collection of breaches of so-called secure systems over
the past few years, one can conclude only that the computer-communication
infrastructure stinks, and that the U.S. Government is foolish to believe or
pretend that it is secure in the first place.  And if unclassified are so
weak, what should we expect of the classified systems?

On the *other* hand, perhaps this is a con game.  You put out a system with
miserable protection and hope that someone breaks it.  Then you can ask for
millions of dollars more to perform further palliative protections, rather
than getting to the core of the problem -- significantly ratcheting up the
security of the infrastructure.  Or perhaps it is just another bogus
argument for mandatory key escrow or whatever else it might euphemistically
be called (currently, ``key recovery'' a.k.a. ``sound key management'').
The real irony of is that we are continually told that there are no undue
risks in key-recovery crypto systems.  But, if our infrastructure is *this*
bad, how can anyone hope to protect what is perhaps most critical, namely,
the crypto keys!

  [On the *OTHER* other hand, if the Y2K problem is causing the Government
  so much grief, how can anyone expect them to do security properly?  Date
  arithmetic is not difficult if you know what you are doing.  Security is
  much harder.  Although, I note that in date arithmetic you are often
  dependent on other systems, not just your own.  The same is true of
  security.]

    [Check out my own URL for a bunch of related items on this subject,
    including House and Senate testimonies on the allegedly secure
    infrastructure (http://www.csl.sri.com/neumann/).]

      [By the way, there's *is* good stuff in the research community, such
      as the Rivest-Lampson Simple Distributed Security Infrastructure
      (SDSI) (http://theory.lcs.mit.edu/~rivest/sdsi) as just one example.
      It is high time some decent authentication with strong encryption
      found its way more vitally into commercial systems.  Which gets us
      back to crypto policy as well as legislative attempts to link
      certificate keys and key recovery!  But technology is not enough.
      Sanity and common sense are also necessary.]


Former Director of the NSA says "no" to key escrow, TTP etc

"Peter G. Neumann" <neumann@csl.sri.com>
Fri, 13 Feb 98 10:16:45 PST
http://www.us.net/softwar/mcc.html
This is a snip from an interview of Adm. Mike McConnell - former Director of
the NSA under Presidents Bush and Clinton:

  SOFTWAR: What is your view of the Clinton administration's current export
restrictions on encryption?

  McConnell: It was our view in the 80s that strong crypto will happen.  The
export restrictions were only meant to slow down foreign development. It was
a matter of national security. Today, it is not a matter of national
security. The FBI Director has made it a law enforcement issue involving
domestic controls. The Department of Justice and the FBI are still seeking
to "mandate" key escrow.

  SOFTWAR: The Clinton Administration is pushing KEY RECOVERY encryption as
a tool to catch criminals and terrorists. Could this type of software be
abused by foreign powers or dictators to persecute dissidents and political
opponents?

  McConnell: Can Key Recovery be used against dissidents and political
opponents? In a word, YES.

  [See SOFTWAR http://www.us.net/softwar ; the interview is at
  http://www.us.net/softwar/mcc.html and it it is fascinating.  PGN]

    [BTW, how many third parties will YOU trust?  PGN]

      [redundant incorrect URL fixed in Archive copy.]

         [inadvertent stray text removed in ARCHIVE COPY.  PGN]


Year 2100 compliance?

Tsutomu Shimomura <tsutomu@ariel.sdsc.edu>
Sat, 21 Feb 1998 19:06:26 -0800 (PST)
Excerpted from the American Megatrends ("the world's premier BIOS provider")
web site: http://www.amibios.com/support/2000.html

> Year 2000 compliance means that the internal BIOS date and time clock will
> continue above the date 1999. It will not reset it self after 1999 to the
> date of 1980. It will continue to the date of 2099 before resetting to 1980.

Tsutomu Shimomura       tsutomu@ucsd.edu        +1 619 534 5050
University of California at San Diego/San Diego Supercomputer Center, USA


COMPAQ usability problem

Pete Mellor <pm@csr.city.ac.uk>
Sat, 21 Feb 1998 13:02:20 +0000 (GMT)
COMPAQ is replacing the on-screen instruction
"Press any key" with "Press the return key",
in an attempt to reduce the flood of telephone
calls to their help desk asking where the "Any" key is.

[Source: UK press, quoted on "The News Quiz", BBC Radio 4, 21st Feb. 1998]

Pete Mellor, Centre for Software Reliability,
City University, Northampton Square, London EC1V 0HB


Shuttle conversation; April already?

"Peter G. Neumann" <neumann@csl.sri.com>
Thu, 19 Feb 98 9:15:19 PST
  [Note: The last previous Friday the 24th was in October 1997,
  and the next one, ominously, is in April 1998.]

From THE WEEKLY UNIX NEWSPAPER, London, 16-20 Feb 1998, Issue Number 667

On Friday the 24th, I was watching the NASA Channel on cable TV to see how
the experiments and Shuttle crew were doing.  The men on board needed to
send some adjusting instructions to the automated setups doing experiments
in the cargo bay, and they were using a laptop to do the sending.  As some
of you may have heard, there was a "computer problem" on board as reported
by CNN.  The dialog between the crew and the Johnson Space Center (JSC) went
something like this:

Crew: Urgent, Johnson, we can't get a DOS prompt!
JSC:  Press "C:<enter>".
Crew: Heck, we're not familiar with all this.
JSC:  What screen are you looking at?
Crew: It says "My Computer", and, er, various other icons.
JSC:  Click on "Start", and then "Shutdown".
Crew: You click the "Start" button to shut down?
JSC:  Yeah.  Isn't it obvious?
Crew: Somebody get me an aspirin.
JSC:  Just hit the damn "Start" button.
Crew: We can't do that.  It didn't load a mouse.
JSC:  Didn't load any mouse at all?
Crew: Well, yeah, a PS/2 or something.  But we don't have one of those.
JSC:  Okay.  Press Alt + Esc.
Crew: And what does that do?
JSC:  It should help.
Crew: Negative.
JSC:  Stand by, will attempt to replicate the problem down here.
Crew: Roger.

<Long Pause>

JSC:  Okay then.  Double-click on the MS-DOS icon.
Crew: I don't have a mouse.
JSC:  Go to the backup plan.
Crew: Which is what?
JSC:  Dock with the Russians.  They have a Unix workstation you can borrow.


First Cybersex Pregnancy

"Scandora, Anthony E., Jr." <scandora@cmt.anl.gov>
Tue, 3 Feb 1998 17:45:40 -0600
My favorite newspaper, the *Weekly World News*, in last week's (27 Jan
1998?)  issue, reported that a woman who has been having an intimate
relationship via the Internet with a man she has never physically met is
with child.  She is considering a paternity suit.

Tony Scandora, Argonne National Lab, 630-252-7541  <scandora@cmt.anl.gov>

  [Remember, please, this is a newspaper that apparently uses a computer
  to generate the plot lines for its stories.  PGN]


A little accidental porn-in-the-morn

"Peter G. Neumann" <neumann@chiron.csl.sri.com>
Fri, 27 Feb 1998 10:25:49 PST
  From at least 1 Feb 1998 until it was fixed on 10 Feb, at 5:20am each
  morning TCI gave San Francisco's Channel 27 viewers 40 minutes of
  free porn from the Adam-and-Eve network on its pay-per-view preview
  channel.  (However, there were interruptions for commercials advertising
  similar stuff.)  The glitch was attributed to the computer system turning
  off the masking supposedly provided by the scrambler, ahead of schedule.
  [Premature emasculation?]

[PGN Stark Abstracting from Nando.net Scripps-McClatchy Western item, by
Anastasia Hendrix in the San Francisco Examiner, 12 Feb 1998,
http://www.techserver.com/newsroom/ntn/info/021298/info23_29316_noframes.html
Thanks to Aydin Edguer <edguer@MorningStar.Com> for noting this one.]

  [No telling what we'll see when Y2K hits their computer -- perhaps
  total unscrambling!]


DES-II-1 challenge cracked

David McNett <nugget@slacker.com>
Tue, 24 Feb 1998 23:38:58 -0600
  [Sent to RISKS courtesy of Dave Farber's IP list.]

Original-Subject: [RC5] [ADMIN] The secret message is...

  [http://www.distributed.net/des/nugget.txt]

Once again I have the great privilege of coming to you with good news.

It is with great pleasure (and a sigh of relief) that I can now inform you
that the DES-II-1 challenge has been successfully met by distributed.net.

The winning key to the challenge was detected and submitted to RSA Labs
at 02:26 GMT on Monday, 23-Feb-1998.

The correct key, 76 9E 8C D9 F2 2F 5D EA, revealed the words which we've
been anticipating these past 39 days:

"The secret message is: Many hands make light work."

(If you ask me, this is a nice nod in our direction.  Thanks, RSA Labs!)

In addition to proving that 56-bit DES is no longer sufficient for
protecting valuable information, we've now also proved that blind luck need
not be a factor in brute-force decryption attacks.  The original DES
Challenge and the more recent RC5-56 wins were fortunate and did not have to
sweep a significant portion of the keyspace.  This time around, however, we
managed to complete almost 90% of the keyspace and have now proven that even
when the law of averages chooses to catch up to us and forces us to pay our
dues, we are still an unstoppable force.  Our collective victory is all the
more impressive when you consider what we had to accomplish to achieve it.

We tested sixty-three quadrillion keys.  That number is simply staggering.

Assuming *0* growth between now and July, we'll be able to sweep the entire
DES-II-2 keyspace in just under 29 days.  That's assuming that we do not
recruit another person, don't add any more machines, and are even more
unlucky next time.  I daresay at least one of those assumptions is probably
false.

I'd invite all of you to join us in IRC (efnet, #distributed) for a rowdy
victory party.  Take a breather.  Sit back and watch your clients
automatically roll over to RC5-64.

The only other issue at hand is *who* found the key.  The person who found
the winning key has politely asked to remain anonymous.  Rest assured, I've
been in contact with them and they know they've won.  They will be receiving
their full share of the prize and are quite excited about the victory.  All
I'd ask is that we all respect this person's wishes and not bother the list
with public speculation as to their identity.  I'm sure we all appreciate
just how important privacy and anonymity can be.

Here are some numbers to chew on while the stats are down:

Project statistics:
        Start of contest:                       January 13, 1998 at 09:00 PST
        Start of distributed.net effort:        January 13, 1998 at 09:08 PST
        End of Contest:                         February 23, 1998 at 02:26 PST

        Size of keyspace:                       72,057,594,037,927,936
        Approximate keys tested:                63,686,000,000,000,000


        Number of 2^30 (average) keyblocks:                 67,108,864
        Number of keys in average keyblock:              1,073,741,824
        Peak blocks per day:                                 5,540,982
        Peak keys per second:                           34,430,460,000

The unencrypted message: Many hands make light work

Computing equivalents:

   Distributed.net is equivalent in processing power to:

           11,264       DEC Alpha 21064 533s
           15,316       Sun Ultra I 167s
           22,393       Intel Pentium II 333s
           68,859       Macintosh PowerPC 604e/200s.
           41,712       Intel Pentium 166s
          399,374       Intel 486DX2/66s
        7,446,033       Intel 386SX/20s

(based solely on DES client performance)

Prospective:

If Keys were dollars, we could pay off the U.S. National Debt in 6.25 minutes

If Keys were pennies, we could buy 536249385 Mazda Miatas each day.

If Keys were pennies, we could buy 256728249 Jeep Cherokees each day!

If you printed a single page to represent each key block as it was checked
and placed those pages in a stack, it would grow 12.83 inches taller every
minute.

If blocks were liters of Dr. Pepper, we could produce 6381493 six-packs
each day.

If Key Blocks were cheeseburgers, fries, and a large Dr. Pepper, we could
feed the entire city of Toronto, Ontario lunch each day.

(On a personal note, It sure feels nice to be doing RC5 blocks again.  I
feel like I've just slipped on an old, comfortable pair of loafers that were
lost in the attic for two months.)


Re: Markus Kuhn and Ross Anderson's Soft Tempest (RISKS-19.59)

Lloyd Wood <L.Wood@surrey.ac.uk>
Fri, 13 Feb 1998 20:39:04 +0000 (GMT)
In RISKS-19.59 Ross Anderson is quoted by Minow et al. as saying:
> <http://www.cl.cam.ac.uk/~mgk25/ih98-tempest.pdf>
> In its simplest form, our technique uses specially designed `Tempest
> fonts' to make the text on your screen invisible to the spooks.

Specially designed fonts as such aren't required; with the advent of
routines to generate smoothed anti-aliased fonts on personal computers, the
detection of text on a CRT as discussed by Anderson et al is made slightly
more difficult as the edges are already smoothed, removing high-frequency
signal components.

Modifying the system bitmap text anti-aliasing routines, rather than the
display drivers as the paper suggests, to 'lowpass-buffer-alias' (for lack
of a better term) all output fonts as directed is rather easier than
redesign of individual fonts. It offers more transparent results, and the
resulting security solution is more easily distributed to and accepted by
users than a host of new fonts or a replacement display driver would be.

On the Macintosh, you'd generate lowpass-buffer-aliased SoftTempest fonts by
modifying the source to Landweber's "Greg's Hack", now his shareware
SmoothType (source and pointers to antialiasing algorithms available from
http://www.kaleidoscope.net/greg/smoothtype.html  [CORRECTED IN ARCHIVE.]

On Windows, Microsoft's own antialiasing routines - a later product,
also called Smoothtype - are included in their Plus! Pack and with
Explorer 4.0.  [previously noted by bos, RISKS 19.42]

I'd worry about a Tempest virus that polled a personal computer's
CD-ROM drive to pulse the motor as a signalling method:

* Modern high-speed CD-ROM drive motors are both acoustically and
  electrically noisy, giving you two attack methods for the price of one;

* Laptop computer users without CRTs, and the PC users that can afford
  large LCD screens instead of CRTs, often have CD-ROM drives;

* Users are getting quite used to sitting patiently while their
  CD-ROM drives grind away for no visibly obvious reason (but
  that's quite enough about the widespread installs of software from
  Microsoft CD-ROMs that prompted Kuhn's investigation in the first place.)

<L.Wood@surrey.ac.uk>PGP<http://www.sat-net.com/L.Wood/>+44-1483-300800x3641


Risk: Massive NT Outage due to Registry corruption

<mandrews@fd9ns01.okladot.state.ok.us>
Thu, 12 Feb 1998 11:23:36 -0500
  [This was sent me by someone at a Fortune-100 manufacturer, and is
  anonymized and sanitized at the original sender's request.  It is genuine.]

> The recent power fluctuations here in [placename] corrupted the NT
> registries in our [server-community-names].  As a result, our entire NT
> network (>10K machines) is down, and has been since 5 am this
> morning. (I'm doing direct IP to [product-name] to do mail. Thank God.)
> Once the registries got corrupted, the databases of user signons went,
> too. And, of course, the tape backups won't load because NT requires a
> timestamp somewhere in the guts that the tape image doesn't match to the
> clock. So every NT server, and most NT workstations, won't do anything
> except local work.

> If this were just office workers, it would be annoying enough. But the
> [product name] servers require such close tie-ins to the machine accounts
> that they are dead -- guess what helps run our factories? Can you say loss
> of $1M+ per hour?"

> Why am I telling you? Because our NT guys have suddenly realized that this
> is a good candidate for a denial of service attack: once the registries
> get corrupted, the entire resource domain has to be reloaded by hand --
> and that apparently includes desktops. If you have ideas on how to go
> check the registries on your NT servers, I'd suggest you go do so.

In another letter, the original sender elaborates:

> If you are recovering from this, every desktop user will have to
> delete/disable their <user>.pwl file to be able to get back on the
> network, because that file hardcodes which domain server they are
> on. HOWEVER, if they do that, they can then not get into any other service
> on their desktop for which they've stored the password, because they're
> all in that file. if the user doesn't remember the password, they're SOL,
> because the latest patch from MS keeps the *.pwl files from being hackable
> by the "standard" hacker and pwledit tools -- but it is also rendered
> unreadable to the MS standard pwl editor, too.

The total outage was in excess of 12 hours, and the loss-of-revenue from
the outage is estimated to be more than $10 million.

Mike Andrews, D.P. Director, Okla. Dept. of Transportation
mandrews@fd9ns01.okladot.state.ok.us


Airport Big Brother Blocks Buggies

"Marcus J. Ranum" <mjr@nfr.net>
Mon, 09 Feb 1998 17:10:27 -0500
Baltimore Washington International Airport recently installed a system "for
my protection" "with my tax dollars" which delayed me considerably in
getting home one night.

About a month ago, I noticed small video cameras appearing at the exit lanes
of the parking lot. I assumed that they were to record license plates in the
event of someone trying to skip paying, or using a stolen credit card. Since
my car is kind of short, they've already had to ask me several times to back
up so that the camera could get my plate. I usually pay with a credit card
so I didn't think this was an especially big deal.  Now, I'm not so sure at
all.

The other night I got back from a late trip, and when I came to pay the lady
apologized and explained that there were some delays "because the system is
running slow." I said that was no problem because I was paying cash, handed
her exact change, and waited for the bar to go up. She was still fiddling
with a computer and I began to get irritated and asked her to let me
leave. "I can't do that, the state police computer has to clear your tag,
first!"

I sat there for quite a while, and while I was waiting (maybe a total of 10
minutes) I got more details from her. It seems that "to protect us"
Maryland's State Police established the system. Either she was no rocket
scientist, or someone had lied to her about the purpose of the system,
because she was convinced it was to prevent theft of vehicles. I tried some
logic: "if someone was stealing my car from the lot, I would still be away
on my business trip, so I wouldn't have reported it stolen, yet."  I suppose
that a stupid criminal who was going to rob cars would car-pool into the lot
with a buddy, but I have to wonder who/what they are really trying to track.
My paranoia was heightened by the state police cruiser that was idling in
the vacant lot just across the access road.

As a computer security guy, I worry about these things more than most
people.  But, I suppose that the presence of this system means there is a
record someplace of who and when people went to a major airport. Since it's
presumably not "sensitive" information, the security on that record is
probably lousy. (I've seen how government agencies usually handle any
computer records that are not CLEARLY sensitive) :( I guess the technology
will appear elsewhere - perhaps at stop lights in major intersections "to
protect us" by detecting cars that have somehow been identified as "worth
catching."

When you go to the airport they ask you "has any unknown person asked you to
carry anything in your bags?"  I guess the savvy frequent flier will make
sure they never travel to BWI with an unknown person or in an unknown car --
I am just Real Happy that the police computer didn't have my tag number in
its database as a dangerous, armed felon. I see all kinds of potential for
disaster in the event of a license tag confusion. I got off lucky because
all Big Brother did that evening was waste 15 minutes of my time and give me
a good cardiovascular workout by raising my blood pressure a notch. It's
nice to see my "tax dollars at work."  :-P

Marcus J. Ranum, CEO, Network Flight Recorder, Inc.  http://www.nfr.net
home - http://www.clark.net/pub/mjr


Dennings' "Internet Besieged: Countering Cyberspace Scofflaws"

"Rob Slade" <rslade@sprint.ca>
Fri, 20 Feb 1998 08:28:41 -0800
BKINBSGD.RVW   971120

"Internet Besieged: Countering Cyberspace Scofflaws",
Dorothy E. Denning/Peter J. Denning, 1998, 0-201-30820-7
%A   Dorothy E. Denning denning@cs.georgetown.edu
%A   Peter J. Denning
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D   1998
%G   0-201-30820-7
%I   Addison-Wesley Publishing Co.
%O   416-447-5101 fax: 416-443-0948 800-822-6339 617-944-3700
%O   Fax: (617) 944-7273 bkexpress@aw.com
%P   547 p.
%T   "Internet Besieged: Countering Cyberspace Scofflaws"

As with the earlier "Computers Under Attack" (cf. BKDENING.RVW), this book
is a collection of papers related to the titular topic.  This text is not
just an updating of the earlier work, although some of the same papers
appear, having been revised and updated.  It is also more narrowly focussed,
with sections discussing the worldwide network, Internet security,
cryptography, secure electronic commerce, and finally dealing with law,
policy, and education.  The anthology style is well suited to a constantly
changing and still emergent field.

Under the scope of the worldwide network, there is an initial review of the
history of the net by Peter Denning.  Dorothy Denning follows up with an
overview of system security breaking methods over networks.  (While it is a
fine and readable piece of work, the essay is not quite as riveting as the
interview with a system cracker in "Computer Under Attack.")  As usual, the
most interesting papers deal with real case studies, such as the attack on
Rome Labs.  Peter Neumann's brief piece on the RISKS-FORUM archives
indicates the value that the net can be in protecting itself, since RISKS
acts as a kind of repository memory of attacks and weaknesses.  The even
briefer article on securing the information infrastructure is a kind of call
to arms to pay attention to security in important control systems.  Part one
is finished off with Eugene Spafford's computer virus paper; by now the
classic short work in the field.

Part two, specifically looking at Internet security, starts with another
case study; that of the Berferd attack on Bell Labs.  This is followed by an
overview of network security threats and protective tools.  Two articles
look at specific types of assaults: "sniffing", which works because of the
broadcast nature of many means of media access, and "spoofing", which works
because of the automatic configuration and repair protocols intended to
provide reliability.  An overview of password use looks primarily at
technologies to make password cracking more difficult.  Four security tools
are introduced, a GPS (Global Positioning System) based authentication
scheme, Tripwire, DIDS (Distributed Intrusion Detection System), and SATAN
(Security Administrator Tool for Analyzing Networks).  Java security also
gets a thorough examination.

The section on cryptography starts with the development of the Data
Encryption Standard.  (It is indicative of the rate of change in this field
that the following article, looking at the breaking of two recent
cryptographic systems, doesn't cover the cracking of DES.  The book was
published just before that happened.)  There is a detailed essay on the
Internet Privacy Enhanced Mail (PEM) protocol, and a more conceptual paper
on authentication for distributed networks.  There is also a taxonomy, or
method of classifying, for key recovery encryption systems.

Security of electronic commerce covers electronic commerce itself, atomicity
in electronic commerce (which determines the general usefulness of a
system), another overview of Internet security vulnerabilities, digital
forms of money and cash, ad identify misuse and fraud.

The final part looks at social issues.  The law enforcement in cyberspace
address, coming as it does from a US federal agency, is unsurprising in its
call for key escrow.  Dorothy Denning follows up with a more reasoned review
of the market forces.  Bruce Sterling gets two cracks at computers and
privacy.  Eugene Spafford gets the hardest job--looking at computer
ethics--and does a decent and practical job.  There are two examples of use
policies from universities, and a final, very interesting, article on the
inclusion of data security topics and activities in the teaching of computer
science concepts (rather than the other way around).

Even within this limited frame of reference, the book cannot be exhaustive.
When you start to consider the gaps that are missing, like the international
nature of many activities that make them essentially immune to legal
remedies, you also find that whole fronts of the Internet siege are
unmentioned, or only tangentially referred to.  Spam, fraudulent scams, and
chain letters claim many more victims than do system crackers.

Still, this work is both interesting and valuable.  It should be of
particular use to the student or teacher of data security, although
there is much to hold the attention of any interested individual.

copyright Robert M. Slade, 1997   BKINBSGD.RVW   971120

Please report problems with the web pages to the maintainer

Top