The RISKS Digest
Volume 22 Issue 32

Wednesday, 23rd October 2002

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Hacker attack targets root servers
NewsScan
Memo reveals FBI national security wiretap violations
Marc Rotenberg
Math in the cockpit: yet another units conversion risk
George N. White III
Navy searching for missing computers
Bradley Wood
FDA approves implantable ID chip
NewsScan
Family receives enormous deposit in error
Ulf Lindqvist
Bugbear hugs?
Justin Macfarlane
Privacy Journal Ranking of States
Robert Ellis Smith
IE flaws leave systems vulnerable
Monty Solomon
Re: The high risk of low security: element 118
Mike Hogsett
Stephen Poley
Re: UCSD bans WinNT/2K — NO, it is UCSB
Tom Perrine
Re: UCSB bans WinNT/2K — will it do any good
Alistair McDonald
Re: password complexity ...
Jeremy Ardley
Martyn Thomas
Merlyn Kline
Miro Jurisic
Jordin Kare
REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles
Rob Slade
REVIEW: "Hack Proofing Your Identity in the Information Age", Teri Bidwell
Rob Slade
Info on RISKS (comp.risks)

Hacker attack targets root servers

<"NewsScan" <newsscan@newsscan.com>>
Wed, 23 Oct 2002 08:58:30 -0700

A powerful denial-of-service attack briefly crippled nine of the 13 Internet
"root" servers, but traffic routing was able to continue unimpeded, said
ICANN VP Louis Touton: "As best we can tell, no user noticed and the attack
was dealt with and life goes on."  One government official described
Monday's attack as the most sophisticated and large-scale assault on these
root servers to date.  The attack, which began around 4:45 p.m. EDT on
Monday, blasted the servers with 30 to 40 times the normal amount of
messages, rendering seven computers unable to respond to legitimate Internet
traffic.  Two others failed intermittently during the attack.  The Internet
theoretically can run with just one operational root server, but response
times would be very slow.  [AP 23 Oct 2002; NewsScan Daily, 23 October 2002]
  http://apnews.excite.com/article/20021023/D7MR8PT00.html


Memo reveals FBI national security wiretap violations

<Marc Rotenberg <rotenberg@epic.org>>
Thu, 17 Oct 2002 15:47:06 -0400

  [Excerpted from EPIC Alert 9.19.  PGN]

A recently released FBI memo provides the latest evidence that the Bureau
has frequently overstepped its legal bounds when conducting intrusive
national security surveillance.  The document, which was written in April
2000 and originally classified as "secret," reveals that FBI agents
illegally videotaped suspects, intercepted e-mail without court permission,
recorded the wrong phone conversations, and conducted "unauthorized
searches."  The incidents detailed in the memo involved cases requiring
warrants under the Foreign Intelligence Surveillance Act (FISA).

The declassified document was obtained by Rep. William Delahunt (D-MA), with
the assistance of EPIC.  The existence of the memo was first revealed in an
FBI document obtained by EPIC earlier this year through its Freedom of
Information Act lawsuit for information concerning the Bureau's
controversial Carnivore Internet surveillance system (see EPIC Alert 9.11).
That earlier disclosure, which showed that an anti-terrorism investigation
involving Osama bin Laden was hampered by technical flaws in the Carnivore
system, alluded to a separate document discussing other "FISA mistakes."
EPIC worked with Rep. Delahunt's office to seek disclosure of the "mistakes"
memo.

The latest disclosure comes as the Foreign Intelligence Surveillance Court
of Review (FISCR), in its first proceeding since being created in 1978, is
considering the legality of new Justice Department surveillance rules.  DOJ
has asked the FISCR to overturn a decision of the Foreign Intelligence
Surveillance Court, which in May unanimously rejected the government's bid
for expanded powers.  In its decision, the intelligence court documented
abuses of "national security" warrants by both the Bush and Clinton
Administrations, including serious errors in approximately 75 applications
for foreign intelligence surveillance (see EPIC Alert 9.16).

The newly disclosed "mistakes" memo reveals errors that extend beyond those
detailed by the surveillance court in May, which concerned FBI
misrepresentations in applications for surveillance warrants.  The new
"mistakes" involve the manner in which surveillance activities were actually
conducted, a potentially more serious issue as the incidents appear to
involve violations of both FISA and the Fourth Amendment.

The FBI "FISA mistakes" memo is available at:
  http://www.epic.org/privacy/terrorism/fisa/FISA-mistakes.pdf

Background information (including selected documents) on EPIC's
Carnivore FOIA litigation is available at:
  http://www.epic.org/privacy/carnivore/

Background information on FISA is available at:
  http://www.epic.org/privacy/terrorism/fisa/


Math in the cockpit: yet another units conversion risk

<"George N. White III" <aa056@chebucto.ca>>
Tue, 22 Oct 2002 21:44:25 -0300 (ADT)

An article by Mark Bowden in the November, 2002, Atlantic Monthly describes
the process of delivering smart bombs as practiced in Afghanistan.  Air
Force pilots working with Army "forward air controllers" (FAC) sometimes
drop laser guided precision bombs through cloud cover using guidance from a
laser operated by the FAC.  The Army uses different coordinate systems for
position and elevation from that of the Air Force.  Apparently the Air Force
system does not provide for coordinate conversion, so the "weapons system
officer" (WSO) must make manual calculations to convert coordinates, often
under intense pressure, including watching for a ground-to-air missile
launch.  After one such episode, Bowden quotes one WSO as saying, "The
recruiter said there would be no math in the cockpit".  In fact, the ability
to do simple math under pressure has always been an important cockpit skill.
Years ago, pilots carried circular slide rules to perform fuel and distance
calculations.  The WSO quoted in the article used a calculator in his watch.

The risks associated with a system that requires manual coordinate
conversion are clear — many examples have appeared in this forum.  We may
never know how many people died in Afghanistan as a result of errors in
manual coordinate conversions, either as direct casualties from a
misdirected bomb or as a result of enemy action that a properly directed
bomb would have prevented.

George N. White III  <aa056@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia, Canada


Navy searching for missing computers

<"Bradley Wood" <Bradley.Wood@sri.com>>
Tue, 22 Oct 2002 10:17:50 -0600

At least 595 laptops and desktops belonging to the Navy's Pacific Command in
Hawaii were reported as potentially lost or compromised, according to a July
2002 inventory of onboard units performed by the Naval Audit Service.  The
report identifies failures and breakdowns in the Navy's largely manual
system for tracking sensitive equipment deployed aboard Navy ships and
submarines.  However, the number was reduced to 187 by mid-October, after
further checking.  Shore-based units are now being surveyed, and a new
inventory control system is being developed.  In August, two top-secret
laptops disappeared from a Sensitive Compartmented Information Facility
(SCIF) run by the U.S. Central Command at MacDill Air Force Base in Tampa,
Fla.  This was detected as part of an attempt to find out how plans for an
invasion of Iraq had leaked to the media.  [Various similar cases were noted
involving the U.S. Departments of State, Energy, and Justice, and the FBI.]
[Source: Dan Verton, 21 Oct 2002, *Computerworld*; PGN-ed]
www.computerworld.com/securitytopics/security/story/0,10801,75295,00.html


FDA approves implantable ID chip

<"NewsScan" <newsscan@newsscan.com>>
Wed, 23 Oct 2002 08:58:30 -0700

In a surprise move, the Food and Drug Administration okayed the use of
implantable ID chips in humans, providing they are used for "security,
financial and personal identification or safety applications."  The FDA has
still not ruled on whether the VeriChip, made by Applied Digital Solutions,
can be used for medical purposes, however.  The company has promoted the
device in the U.S. for its ability to provide detailed medical history data
in cases where the patient is unable to communicate with emergency room
personnel.  Applied Digital president Scott Silverman says he's happy with
the FDA's decision: "We'll now go into high gear with our sales, marketing
and distribution plans in the U.S.," adding that the company will focus on
the security and ID aspects of the chip, at least for the time being.
Meanwhile, Leslie Jacobs, whose family volunteered to "get chipped" last
May, says she's still hoping the FDA will approve the VeriChip for medical
use.  Both her husband and son have ongoing health problems.  [Wired.com 23
Oct 2002; NewsScan Daily, 23 October 2002]
  http://www.wired.com/news/politics/0,1283,55952,00.html


Family receives enormous deposit in error

<Ulf Lindqvist <ulf@sdl.sri.com>>
Tue, 22 Oct 2002 16:53:33 -0700 (PDT)

We have heard of bogus deposits before, but this one is unusually high.

The Swedish local newspaper *Tidningen Angermanland* (www.tidningen.to)
reports that a "human error" caused an amount of more than 92,700,000,000
SEK (roughly $10 billion, or 10 milliard Euro if you will) to be deposited
into the bank account of a family, instead of the normal 950 SEK per child
per month that all families in Sweden receive from the government. The bank
spokesperson said that payments were processed manually because of a backlog
caused by other problems, and would not elaborate on the actual cause,
citing security concerns.  After less then a day, the payment was reversed,
and the family were not allowed to keep the 15 million SEK of interest that
had accrued on their account during this time.


Bugbear hugs?

<"Justin Macfarlane" <Justin.Macfarlane@lafferty.com>>
Tue, 22 Oct 2002 10:44:19 +0100

The recent Bugbear epidemic recently had pleasant repercussions for a
colleague.  An e-mail they had sent to an external business, which later
became infected with the virus, was chosen for mass circulation.  It ended
up in many people's inboxes, one of whom turned out to be an old university
friend.  They had lost contact over the years, and thanks to the virus, now
they're back in touch.


Privacy Journal Ranking of States

<"Robert Ellis Smith" <ellis84@rcn.com>>
Tue, 22 Oct 2002 10:25:23 -0400

PRIVACY JOURNAL ISSUES RANKING OF STATES IN PRIVACY

California ranks highest in protecting its citizens against invasions of
privacy, according to a ranking issued by Privacy Journal, the nation's
leading publication on privacy.

California finished at the top because its legislature passed a raft of new
protections in the last two years; also, its courts and its constitution
provide the strongest privacy protection in the nation.

In 1999, when the Providence, R.I.-based monthly newsletter announced its
first ranking of the states, California and Minnesota tied for first. This
year, after Privacy Journal considered laws and practices since 1999,
California finished first and Minnesota finished second, both with numerical
rankings 33 percent higher than the next ranked state.

The top ten states, according to the Providence R.I.-based monthly
newsletter, are, in alphabetical order: California, Connecticut, Florida,
Hawaii, Illinois, Massachusetts, Minnesota, New York, Washington, and
Wisconsin. There was little change among the top ten states from Privacy
Journal's original ranking of the states, in 1999. California and Minnesota
tied in 1999. California, Minnesota, and Hawaii - alone among the states -
have state offices assigned to protect personal privacy.

The ranking is based on the 2002 edition of Privacy Journal's "Compilation
of State and Federal Privacy Laws," a 106-page reference book available for
$35 from Privacy Journal, PO Box 28577, Providence RI 02908, 401/274-7861,
fax 401/274-4747, orders@privacyjournal.net, www.privacyjournal.net.

Privacy Journal rates the states on several factors, including whether they
protect privacy in their constitutions, have laws protecting financial,
medical, library, and government files, and have fair credit reporting laws
stronger than the federal law. Points are added when the highest court in
the state has a strong record on privacy and deducted for anti-privacy
actions by state agencies or the state legislature.

Contact: Robert Ellis Smith, 401/274-7861
orders@privacyjournal.net
http://www.privacyjournal.net

  [See the Web site for further details.  PGN, who is now on the
  Advisory Council of the California Office of Privacy Protection...]


IE flaws leave systems vulnerable

<"Monty Solomon" <monty@roscom.com>>
Tue, 22 Oct 2002 16:27:18 -0400

By Robert Lemos, Staff Writer, CNET News.com, 22 Oct 2002

An Israeli Web-application company has warned users of Internet Explorer
that nine related security flaws in the program could be used by malicious
hackers to gain access to a victim's computer files.  GreyMagic Software
said Tuesday that the vulnerabilities--eight of which it deemed critical --
could be exploited using a specially coded Web page that would run malicious
programs on a victim's computer if the victim visited the page.  ...
  http://news.com.com/2100-1001-962966.html


Re: The high risk of low security: element 118 (RISKS-22.31)

<Mike Hogsett <hogsett@csl.sri.com>>
Mon, 21 Oct 2002 16:25:47 -0700

> [What to name the would-be new element?
> Phonium?  Phakium?  Phorgium?  Phudgium?  PGN]

Itaintium?
  [PGN notes this includes a nice pun: It-ain't-ium vs I-taint-ium]
Unscrupulum?


Re: The high risk of low security: element 118 (RISKS-22.31)

<Stephen Poley <sbpoley@xs4all.nl>>
Tue, 22 Oct 2002 16:56:04 +0200

Given elements 102 Nobelium and 101 Mendelevium, 118 would obviously be

  Nobelievium

    [Sent to RISKS via Mark Brader... apparently from an UNMODERATED
    comp.risks pipeline over which I have no control!  PGN]


Re: UCSD bans WinNT/2K — NO, it is UCSB (Epstein, RISKS-22.31)

<Tom Perrine <tep@sdsc.edu>>
Tue, 22 Oct 2002 09:21:43 -0700

There's an error in the subject line of Jeremy Epstein's message.  It is
UCS*B* that is banning NT/2000, not UCS*D* (where I am).  However, it is
correct in the story itself.

> Citing security reasons, the University of California at Santa Barbara
> (UCSB) has banned the use of Microsoft Windows NT/2000 on its residential
> network, ResNet. ...


Re: UCSB bans WinNT/2K — will it do any good

<"Alistair McDonald" <alistair@inrevo.com>>
Tue, 22 Oct 2002 12:52:20 +0100 (BST)

An interesting opposite to this story is a thread on the uk.comp.os.linux,
where King's College (London University) bans the connection of Unix and
Linux systems to their network.

The thread is archived here:
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=7d532ada.0209180542.6503efb6%40posting.google.com&rnum=1&prev=/groups%3Fq%3Dg:thl1127390037d%26dq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D7d532ada.0209180542.6503efb6%2540posting.google.com

Now, a badly administered box is a risk to everyone, no matter the OS, but
this seems to be a trifle heavy-handed.

Alistair McDonald, InRevo Ltd.
Land: +44 1344 642 521   Mobile: +44 7812 829 020   http://www.inrevo.com


Re: password complexity ... (Arnold, RISKS-22.31)

<Jeremy Ardley <jeremy@electrosilk.net>>
Tue, 22 Oct 2002 09:28:28 +0800

Seth Arnold <sarnold@wirex.com> wrote about the security implications of
putting 10 electronic numerals onto only 5 buttons.  This is not a bright
idea from the electronic age, but simply a rehash of traditional
locksmithing practice.

Many combination locks may have 100 or more marks on the dial, but
physically have far less. So for instance, selecting 57 on the dial could
work equally as well if you chose any number from 55 to 60.

I quote from a published project by Neil Fraser on how to crack cheap 60
mark 3 wheel combination locks using custom built machinery:
  http://neil.fraser.name/hardware/locraker/

  "Its strategy is essentially the brute-force approach of trying all
  combinations until the lock opens; however it uses several short cuts. A
  standard combination lock does not have 60 possible divisions (as its dial
  might suggest), but rather more like 15. To be thorough, the Locraker
  assumes 20 divisions. Thus the number of possible combinations is 20*20*20
  or 8000. Another shortcut is that it doesn't have to dial in all three
  numbers separately for each try. Instead, it can dial in the first two
  numbers, then try all the possible third numbers in one pass by
  continually jerking the clasp as it spins the dial around once. The lock
  doesn't know it is being repeatedly polled. This reduces the number of
  passes to 20*20 or 400. Finally, the average lock will open after half the
  combinations have been tried, so the expected number of passes would be
  200. At six and a half passes per minute, it can open a lock in about half
  an hour."


Re: password complexity ... (Arnold, RISKS-22.31)

<"Martyn Thomas" <martyn@thomas-associates.co.uk>>
Tue, 22 Oct 2002 09:28:28 +0800

My digital lock has ten buttons, one per digit, and has a five digit code.

An examination of the mechanism shows that it doesn't matter in what order the
digits are entered ...

I have never met a computer password system with that particular weakness.

Martyn Thomas, Holly Lawn, Prospect Place, Bath BA2 4QP  01225 335649


Re: password complexity ... (Arnold, RISKS-22.31)

<"Merlyn Kline" <merlyn@zyweb.com>>
Tue, 22 Oct 2002 09:56:15 +0100

> Date: Sat, 19 Oct 2002 17:15:15 -0700
> From: Seth Arnold <sarnold@wirex.com>
> Subject: Password complexity — not just for computers anymore
>
> The outside key-code on my building has five buttons but ten digits — two
> digits per button. This allows for 10^n different "combinations" as humans
> must remember it, but 5^n different combinations as the door remembers it.

Either 5^n combinations provides adequate security or it does not. If it
does not, then the system is flawed regardless of key labelling. If, OTOH,
it *does* provide adequate security then you could report the key labelling
as follows:

"The outside key-code on my building has five buttons but ten digits — two
digits per button. This allows for 5^n different combinations, each with 2^n
mnemonic representations thus reducing the number of false negatives and the
need to re-issue codes to those who have forgotten theirs."

Of course if people are allowed to choose their own codes then there is an
increased chance of two people choosing the same code. However if this is a
problem for the implementation of this particular system then it needs to be
managed anyway.

Merlyn Kline


Re: password complexity ... (Arnold, RISKS-22.31)

<Miro Jurisic <macdev@meeroh.org>>
Tue, 22 Oct 2002 09:19:22 -0400

I believe the intent here is to allow you to use the same combo on two
different doors, one using a 3x4 grid, one using five buttons. MIT uses this
in public computer clusters, where all the older combo pads are 3x4 and the
newer ones are 1x5, yet the same combo can be used on all of them.


Re: password complexity ... (Arnold, RISKS-22.31)

<Jordin Kare <jtkare@attglobal.net>>
Tue, 22 Oct 2002 02:55:29 -0700

This one isn't a mistake, it's quite deliberate, and (arguably) sensible.

The intent is to allow people to use any number they want as a combination
-- birthdate, phone number, building-number-plus-3, etc.  If only digits 1-5
were shown, then most such easy-to-recall numbers wouldn't work, and the
combination would have to be remembered like a random-character password
string.  Code locks on luxury car doors use the same arrangement, for the
same reason, and the letters on telephone keys serve an equivalent function.
(Originally for translating named exchanges to numbers — MOhawk 4,
BUtterfield 8 — but now mostly for advertising; it's easier to remember
I-FLY-SWA than 435-9792).

Of course, encouraging people to use an easily-recalled number does lower
the security level, but 5-button locks are not generally intended for strong
security.  (On one occasion, I opened one with the second "random"
combination I tried, much to the bemusement of the secretary whose office it
was supposed to be protecting.)

Jordin Kare, 222 Canyon Lakes Pl., San Ramon, CA  94583


REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles

<Rob Slade <rslade@sprint.ca>>
Tue, 22 Oct 2002 07:15:08 -0800

BKSECXML.RVW   20020831

"Secure XML", Donald E. Eastlake/Kitty Niles, 2003, 0-201-75605-6,
U$44.99/C$69.99
%A   Donald E. Eastlake III
%A   Kitty Niles
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2003
%G   0-201-75605-6
%I   Addison-Wesley Publishing Co.
%O   U$44.99/C$69.99 416-447-5101 fax: 416-443-0948
%P   532 p.
%T   "Secure XML: The New Syntax for Signatures and Encryption"

Part one is introductory material.  Chapter one is about XML
(eXtensible Markup Language), but is not very clear, especially in
regard to the relationship between XML, SGML (Standard Generalized
Markup Language), and HTML (HyperText Markup Language).  Security
concepts do not play a big part.  The tutorial on cryptography, in
chapter two, is very simplistic, uses obtuse language, and is much
harder on the reader than is really necessary.

Part two deals with the basics of XML.  Chapters three through eight
present some of the syntax and structure of XML documents, DTDs
(Document Type Definitions), Schemas (particularly unclear), XPath,
XPointer, and SOAP.  That is about all they provide: the material is
not helpful in explaining uses, or how the parts fit into a framework
or package.

Part three covers canonicalization and authentication.
Canonicalization is important to authentication, as chapter nine
points out, because it allows us to eliminate meaningless differences
between essentially the same file, as when different file systems use
varying newline characters or sequences.  Ordinarily, such differences
would result in differences in hash code results, and therefore a
false failure of authentication.  Chapter ten outlines signature
syntax, while eleven talks very briefly about the XMLDSIG standard for
digital signatures, and twelve reviews the European Telecommunications
Standards Institute's (ETSI) somewhat more advanced signatures.

Part four looks at keying, with the KeyInfo element in chapter
thirteen, and XKMS key management in fourteen.  Chapter fifteen, on
the proposed XMLENC standard, and sixteen, containing some discussion
of combinations of encryption and signatures, make up part five.  Part
six, entitled "Algorithms," reviews algorithm specification, in
chapter seventeen; available algorithms, in eighteen; and related non-
cryptographic algorithms, in nineteen.

The writing is turgid, almost deliberately dense, and fails to provide
necessary tutorial details.  Those who are well familiar with XML will
find some particulars regarding the specific encryption documents, but
few others will find the work useful.

copyright Robert M. Slade, 2002   BKSECXML.RVW   20020831
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade


REVIEW: "Hack Proofing Your Identity in the Information Age", Teri Bidwell

<Rob Slade <rslade@sprint.ca>>
Wed, 23 Oct 2002 07:14:25 -0800

BKHPYIIA.RVW   20020826

"Hack Proofing Your Identity in the Information Age", Teri Bidwell,
2002, 1-931836-51-5, U$29.95/C$46.95
%A   Teri Bidwell
%C   800 Hingham Street, Rockland, MA   02370
%D   2002
%G   1-931836-51-5
%I   Syngress Media, Inc.
%O   U$29.95/C$46.95 781-681-5151 fax: 781-681-3585 www.syngress.com
%P   370 p.
%T   "Hack Proofing Your Identity in the Information Age"

Chapter one does say a bit about what identity theft is, and suggests some
basic protections against it.  The rest of the book, however, seems to be
just another attempt to provide an "easy" security book for home users.  And
it doesn't do it very well.

Chapter two is a miscellaneous grab bag.  It recommends keeping all your
files in a standard place (bad), has some nice content on cleaning up
temporary files (good), suggests novice users change the Registry
(dangerous), promotes the use of a power on password (good), has rotten
material on viruses and trojans (conflicting definitions on facing pages as
well as a confusion of adware and spyware, although it does get a point for
mentioning F-Prot), insists users install all patches (possibly bad),
outlines how to set up multiple accounts (good), and has some decent advice
on choosing passwords (also good).  There is a range of information on
e-mail security in chapter three, although the details are questionable.
The "man-in-the-middle" attack is described as TCP hijacking and is said to
be foiled by cryptography, when, in fact, it is usually an attack on
cryptography.  There is good advice on scams.  Web security, in chapter
four, is heavy on cookies and e-commerce, and light on many more serious
issues.  Chapter five is generic Internet connection information.  It
defines a sniffer correctly once but elsewhere as a keylogger, and
oversimplifies firewalls.  Random topics loosely related by being popular
with kids make up chapter six.  Chapter seven does return to the topic of
identity theft and discusses what to do if it occurs.  Some of the advice is
helpful (particularly if you live in the US), but most is vague common
sense.  There is a repeat of the material (with slightly more detail) on
firewalls and browser settings, in chapter eight.

There is little here that is specific to the titular topic.  As for a
general security text, Jeff Crume (cf. BKININSC.RVW) as well as Cronkhite
and McCullough (cf. BKACCDEN.RVW) have already done it better.

copyright Robert M. Slade, 2002   BKHPYIIA.RVW   20020826
rslade@vcn.bc.ca  rslade@sprint.ca  slade@victoria.tc.ca p1@canada.com
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

x
Top