Subject: RISKS DIGEST 15.55

Subject: RISKS DIGEST 15.55
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest Tuesday 15 February 1994 Volume 15 : Issue 55

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

***** See last item for information on RISKS (comp.risks) *****

Contents:
YAMIC [Yet Another Mistaken Identity Case] (Robert Herndon)
William Safire on Clipper: ESSAY: SINK THE CLIPPER CHIP
Over 10,000 Sign Petition to Oppose Clipper (Dave Banisar)
Canada to monitor phone calls,fax,etc.? (Sahel Alleyasin)
No switch on new Sun Microphone (Olin Sibert)
Electronic Mail vs Paper Mail (mathew)
FIRP report comments (Stephen D Crocker)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

----------------------------------------------------------------------

Date: Tue, 15 Feb 94 14:50:59 MST
From: [email protected] (Robert Herndon)
Subject: YAMIC [Yet Another Mistaken Identity Case]

Excerpted from the Minneapolis Star and Tribune, Sunday, Feb. 13, 1994.

THE RIGHT NAME, THE WRONG MAN

Freed after a month in jail, innocent man found he'd lost
job, van, and girlfriend. By Margaret Zack, Staff Writer

Maintenance worker Russ Hamilton tried for more than a month to convince
authorities that he wasn't truck driver Russ Hamilton, who was wanted for
fraud. .... His troubles began Nov. 28 at a Salt Lake City party that got out
of hand. Police were called, and Hamilton was arrested on two misdemeanor
charges. In a routine check, police found there was a warrant out for a
Russell Hamilton in Wisconsin, and both men had the same birth date. So
Hamilton sat in jail.

.. Dane County deputies flew to Salt Lake City and took him to Wisconsin on
Dec. 19. He remained jailed, always protesting his innocence, until Dec. 30,
when authorities learned they had the wrong man and released him. ... the
evidence that freed him -- a photo of the man wanted on the fraud charges --
had been in the prosecutor's file all along.

Hamilton, and his attorney Alan Albrecht of Brooklyn Center, said last week
that someone had obtained Hamilton's birth date and gotten a driver's license
in his name. They said they don't know how that occurred. The fraud suspect
has reportedly been identified but is not in custody.

What Albrecht finds so appalling about the case is that the photo of the real
person wanted in Wisconsin was always in the prosecutor's file. "The picture
could have been faxed out to Salt Lake City," he said. Or at least the
deputies who flew to Utah could have taken the photo with them to be sure they
had the right suspect, he said.

.. But the prosector told him those would have been "extraordinary" measures
and weren't warranted in the case, Albrecht said. The Dane county prosecutor
who handled the case did not return repeated phone calls last week.

[The article goes on to detail differences between Hamilton and the man
wanted for fraud: Hamilton is 37, 5'9", heavy, with long hair, a goatee, and
tattoos on his arms. The man wanted for fraud is over 6' tall, thin, and in
his 50s.

In addition, while Hamilton was in jail, authorities seized his van and its
contents and sold them. His girlfriend, with whom he shared an apartment,
moved out, and he hasn't been able to locate his clothes, furniture, or
other possessions. He is now living in Minneapolis with a brother, and is
preparing a civil lawsuit.

The risks of technology here are apparent and familiar to RISKS readers. In
this case, too, technology would seem able to have provided reasonable
safeguards. That a simple check would be regarded as "extraordinary" seems
itself extraordinary, but alas, is all too common.

[Here is a case where checking the SSN might have helped -- except that
the RISKS archives contain several cases of two people with the same name
who were accidentally assigned the same SSN! PGN]

------------------------------

Date: Tue, 15 Feb 94 10:40:52 PST
From: "Peter G. Neumann" <[email protected]>
Subject: William Safire on Clipper: ESSAY: SINK THE CLIPPER CHIP

The Op-Ed page (A13) of the National Edition of The New York Times on 14 Feb
1994 had a piece by William Safire that is worth ferreting out. Three
paragraphs (excerpted out of 15) summarize his message:

To the tune of ``I Got Algorithm,'' the Eavesdrop Establishment is singing
that it will help us protect our privacy but not from intrusion by the Feds.
In effect, its proposal demands we turn over to Washington a duplicate set
of keys to our homes, formerly our castles, where not even the king in olden
times could go.

Tomorrow's law enforcement and espionage cannot be planned by people stuck
in the wiretap and Big Ear mind set of the past. The new Ultra secret is
that the paradigm has shifted; encryption has overcome decryption.

Cash in your clipper chips, wiretappers: you can't detect the crime wave of
the future with those old earphones on.

------------------------------

Date: Tue, 15 Feb 1994 13:42:29 -0500
From: Dave Banisar <[email protected]>
Subject: Almost 15,000 Sign Petition to Oppose Clipper

Washington, DC
February 15, 1994 (second edition)
Computer Professionals for Social Responsibility (CPSR)
ALMOST 15,000 HAVE SIGNED PETITION TO OPPOSE CLIPPER

In only two weeks, almost 15,000 users of the nation's computer networks have
signed the CPSR petition calling for President Clinton to withdraw the Clipper
proposal. Opposition has been widespread, from CEOs of large firms to college
students in small towns, from librarians and civil libertarians to computer
programmers and product marketers.

To sign the petition, email <[email protected]> with the message
"I Oppose Clipper". [See Banisar, RISKS-15.44 for the petition. PGN]

In 1990, over 30,000 people sent email message to Lotus asking that a product
containing detailed personal information called "Marketplace" be withdrawn.
Eventually Lotus withdrew the product.

CPSR is a non-profit, membership organization based in Palo Alto, CA.
CPSR's mission is to provide analysis of the effects of new technological
developments on society. For more information, please email [email protected] or
call 415-322-3778.

[MODERATOR's NOTE: Many contributions have been received on escrowed keys,
Clipper, et al. Some are repetitions of what has already been included,
others are full of ad hominem comments and not appropriate for RISKS.
There are also some messages that are lengthy interstitiations of already
too-long messages. You will all appreciate that I am having to moderate
much more stringently than usual. But the overwhelming majority of
E-mail is opposed to EES/Clipper, and in support of the CPSR petition.
PGN]

------------------------------

Date: 15 Feb 1994 23:41:17 GMT
From: [email protected] (Sahel Alleyasin)
Subject: Canada to monitor phone calls,fax,etc.?

Canadian security intelligence services is trying to make equipment to keep
records of all conversations from millions of airborne phone, fax, radio
signal and other transmissions.
The first thing that comes to my mind from this high-tech snoop gadget is
that it violates the people's trust and confidence. Nobody can ever be
confident to have a private conversation with others. They are always afraid
of what have been said because the government keeps records of these
conversations. This monitoring of phone calls is the invasion of privacy.
As we have read from the other examples in the text book about risk_forum
digest contributions, the computers could make mistakes. In the case of
Canadian government, using computers could cause someone else to be accused by
the government for something he/she didn't do. An error could result, for
example, from two persons having the same name.
The other risk factor could be the possibility of an intruder accessing a
system and erasing some of the data or other information. An intruder changing
the data could cause other people to be at risk.
Computers are not always to be credited. They could make errors, or
someone else could cause these errors by changing the data. This hardware on
Canadian security service will have the same problem, but the main issue is
that the Canadian government is taking advantage of the new technology to
invade people's private life.

------------------------------

Date: Tue, 15 Feb 94 09:47:11 EST
From: Olin Sibert <[email protected]>
Subject: No switch on new Sun Microphone

A recent product announcement from Sun Microsystems (SunFLASH Vol 62 #8,
4 February 1994) introduces "new microphone, SunMicrophone II, to ship
with current and new Sun desktop platforms". Among the features
described by the announcement for this "uni-directional microphone
which allows greater focus on direct voice input while providing less
interference from background ambient noise" is the following Q&A:

Q. Does the SunMicrophone II look similar to the SunMicrophone?

A. No, the two products look very different. The current SunMicrophone
has a unique square shape, with an on/off switch. The SunMicrophone II
looks like a classic microphone on a rectangular stand, with no
on/off switch. Both products come in Sun colors and with Sun logo.

So, the new, "improved" model has no "on/off" switch, although the old
one did. Maybe the new microphone is "uni-directional", but that
doesn't mean it can't pick up ambient sound--just turn up the gain.

This "improvement" makes it all the more difficult to follow the final
recommendation of CERT Advisory CA-93:15 (21 October 1993), quoted in
part below. It's bad enough that the problem existed in the first
place, but Sun has now made it worse!

III. /dev/audio Vulnerability
This vulnerability affects all Sun systems with microphones. ...

A. Description
/dev/audio is set to a default mode of 666. There is also no
indication to the user of the system that the microphone is on.

B. Impact
Any user with access to the system can eavesdrop on conversations
held in the vicinity of the microphone.

C. Solution
[...]
*** Any site seriously concerned about the security risks
associated with the microphone should either switch off the
microphone, or unplug the microphone to prevent unauthorized
listening. ***

Even if this vulnerability is fixed from a systems viewpoint, a user is
still vulnerable to Trojan horse programs that exploit the user's own
(legitimate) access to the microphone--and the information discussed in
a person's office may be far more sensitive than the information stored
on an office computer.

This is especially a problem for multi-level secure (MLS) systems. Although
MLS systems offer protection against disclosure of information by Trojan horse
programs, that's no help at all if the microphone picks up a Top Secret
conversation that occurs in the office while the user happens to be logged in
at Unclassified. Sure--one might look around to be sure there's nobody who
can inadvertently overhear, or close the office door--but the computer?
Computers don't eavesdrop, do they?

Computer manufacturers need to address these risks. It's certainly
nifty to have desktop audio- and video-conferencing, but not when that
equivalent to installing a bug in every office (and remember not to aim
your video camera at the whiteboard).

Every microphone and video camera should have a positive on/off switch and
some positive indication (such as a light) to show when it's actually in use
(as opposed to just being enabled by the on/off switch). The broadcast
industry learned this years ago, with its "ON THE AIR" lights. Fail-safes,
such as permitting only manual activation, but computer deactivation, or
requiring manual confirmation of any attempted activation, would be better
still.

Olin Sibert |Internet: [email protected]
Oxford Systems, Inc. |UUCP: uunet!oxford!sibert

------------------------------

Date: Tue, 15 Feb 94 13:54 GMT
From: [email protected] (Snakes of Medusa)
Subject: Electronic Mail vs Paper Mail (RISKS DIGEST 15.53)

I'd just like to disagree briefly with one of the comments made in RISKS 15.53
by Jack B. Rochester <[email protected]>, talking about electronic mail.

He writes that "Good grammar and proper punctuation are not required in
e-mail, and their absence does not seem to affect regard for that
person." I must disagree with that assertion strongly.

One particular case springs to mind, where I first met someone over the net.
I got the impression that he was, shall we say, 'intellectually challenged'.
When I eventually met him in real life, I was astounded to discover that he
was quite eloquent. I had built up a very strong disregard for him, based on
his appalling grammar, spelling and punctuation.

That may seem unfair, but people discriminate the same way in real
life, as any stutterer or stammerer will know. At the risk of being
contentious, my perception is that those who claim spelling,
punctuation and grammar are unimportant, generally turn out to be
people who cannot spell, punctuate or string together a sentence.

It's true that e-mail lacks the boilerplate formalisms of paper mail. In
fact, when I get e-mail which starts "Dear Sir", it seems very odd to me.
Whether the lack of generally meaningless stock phrases is a risk, I don't
know. Doubtless such formalisms originally served some purpose, or else they
wouldn't be there; I'm not sure that all etiquette is worth keeping in the
transition from paper to screen, though. Some of it may be obsolete.

Regarding notoriety, I do still find it bemusing to discover that "real
people" (from TV, films and so on) have e-mail addresses. Sometimes the lack
of distance and formalism one gets with e-mail can give a whole new
perspective on a person. For example, I gave in to temptation and sent
electronic mail to Billy Idol. He turned out to be a really nice guy, and
articulate too -- absolutely not what I was expecting from a world-famous rock
musician.

mathew

------------------------------

Date: Tue, 15 Feb 94 17:12:30 -0500
From: Stephen D Crocker <[email protected]>
Subject: FIRP report comments -- forward to your lists if you wish

Response to the Draft Report of the Federal Internetworking
Requirements Panel (FIRP), 14 January 1994

Part 1: Strategic Comments

Stephen D. Crocker
Vice President, Trusted Information Systems, Inc.
IETF Security Area Director

15 February 1994

INTRODUCTION

"The Federal Internetworking Requirements Panel (FIRP) was established by the
National Institute of Standards and Technology (NIST) to reassess federal
requirements for open systems networks and to recommend policy on the [U.S.]
Government's use of networking standards." [Preface, para 1.]

The FIRP report describes the need for the U.S. Federal Government to embrace
not only the OSI protocol suite but also the ubiquitous TCP/IP Protocol Suite.
In fact, Internet Standards, which include the TCP/IP Protocol Suite, are in
very wide use in the Government, throughout the U.S. and throughout the world.
Some OSI products and systems exist, and it may be impossible to switch
completely to TCP/IP-based systems. Nonetheless, the report says, it is time
to acknowledge the widespread use of the Internet Standards and give formal
sanction to their use in the Government.

This is indeed a welcome change, and it should help the Government take better
advantage of modern data networking.

This memo is the first of two responses to the report. In this memo, some
issues are raised with respect to the recommendations in the FIRP report, and
suggestions are made for avoiding problems in the future.

In the other memo, comments are given with respect to specific sections of the
report.

STRATEGIC COMMENTS

This panel was convened in response to a divergence between the strategy the
U.S. Federal Government had been following for several years and the direction
of the marketplace. As the report makes clear, the divergence had become so
great that the policy no longer reflected attainable objectives. The
accommodation of the Internet Standards brings policy into line with
widespread practice and removes obstacles for rational management decisions in
the future.

In this light, it's worth examining the recommendations to ascertain if they
are sufficient to avoid similar problems in the future. As with any large
organization, the U.S. Federal Government pursues multiple policy objectives
and has ingrained organizational imperatives. Recommendations that respond
only to the current marketplace without also anticipating the future or
without including the flexibility to follow the lead of the marketplace may
lead to the convening of a similar panel in the not too distant future.

The FIRP report makes five recommendations:

1. The role of oversight and integration across federal agency
internetworking activities should be strengthened within the Office of
Management and Budget.

2. The roles and responsibilities for fostering standards and
assessing technological change should be refocused and strengthened by
the Department of Commerce.

3. The roles and responsibilities for infrastructure development and
operations to support all internetworking services from advanced
research and development to leading edge to core/commodity services
should be clearly defined and formally assigned through the
Information Infrastructure Task Force.

4. The roles and responsibilities of affinity groups should be
defined, including how they are created and coordinated by the
Government Information Technology Services working group.

5. In accordance with OMB Circular A-119, Revised October 1992,
voluntary standards should be adopted and used by Federal agencies,
and international standards should be considered in the interests of
promoting trade. The current GOSIP policy should be modified by the
Department of Commerce to reflect the wider range of international
voluntary standards for internetworking.

Recommendation 1 asks that OMB's role be strengthened. OMB has the charter to
review the roles, responsibilities and performances of the various agencies
which provide, develop or guide the U.S. Government's internetworking
activities.

This is an important role. The OMB should develop guidelines for measuring
the performance of the assigned agencies and the attainment of the overall
objectives. Although there is usually a preference to avoid duplication of
activities, some degree of competition, exploration of alternative strategies
and comparison of results is desirable because it tends to produce more cost
effective products and services that are better matched to the needs of the
users. Wherever feasible, the OMB should also foster multiple approaches
and/or participation by multiple agencies in order to provide for maximum
feedback within the system.

Recommendation 2 suggests the Department of Commerce be tasked with new
responsibility for "fostering standards."

Presumably the context of this recommendation is with respect to internal
standards within the U.S. Government. The general arena for developing
Internet Standards is the Internet Engineering Task Force (IETF) which
operates in conjunction with the Internet Architecture Board (IAB) under the
auspices of the Internet Society. The Internet Society, along with NSF, ARPA,
DOE and NASA, provide considerable financial support to the standards
activities. This process enjoys wide spread support form the industrial,
academic and government communities, and as a result, the standards developed
in this arena reflect the needs of marketplace and are usually adopted widely
and quickly.

Even if this recommendation is understood to be limited to refer to internal
use of the U.S. Government, the recommendation is flawed. "Department of
Commerce" here certainly includes NIST, but is likely to include other parts
of the Department. While NIST is indeed the federal agency tasked with
promoting and developing standards, NIST and the rest of the Department have
at least two difficulties to overcome.

First, NIST has been the lead agency with respect to GOSIP. NIST personnel
are deeply knowledgeable about the OSI suite and less familiar with the TCP/IP
Protocol Suite. NIST is not now in a position to provide leadership in this
area, although it does have the technical strength to follow, assist and
participate in the ongoing standards activities. One challenge for NIST in
the next few years will be to strengthen its staff and adjust its direction to
move toward a stronger involvement in the Internet Standards activities. A
significant part of this challenge is working in a standards arena in which
the U.S. Government does not have de jure authority or veto power.

Second, the Department of Commerce is heavily committed to a particular
strategy with respect to cryptography that is currently in conflict with the
forces in the marketplace. NIST is the lead agency involved in the
promulgation of the Digital Signature Standard (DSS) and the "Clipper"
escrowed-key encryption system. Both of these initiatives are meeting very
strong resistance from industry and academia. The RSA algorithm is the de
facto standard for signatures and key exchange, and some form of DES and/or
some proprietary algorithms, e.g. RC2 and RC4, are likely to be the de facto
standards for bulk encryption.

The U.S. Government's orientation toward cryptography comes from the specific
concerns of the intelligence and law enforcement agencies. While not denying
the principle that the intelligence and law enforcement agencies have
legitimate concerns, it is far from clear that the approach being taken by the
Department in support of these concerns will be successful. In fact, it is
entirely possible these initiatives will not succeed in the marketplace. If
so, the result will be the existence of dual standards in which the Government
algorithms will be used only under duress, both the Government and the general
population will bear unnecessary costs dealing with dual standards, the
introduction of strong security controls will be retarded, and the
intelligence and law enforcement agencies will not succeed in preventing the
use of strong encryption, except in so far as they succeed in retarding the
use of encryption altogether. On February 4, 1994, the Department announced
it had made substantial progress in its review of policies governing
cryptography. Its announced that export controls on DES and similar
cryptography will remain in place, that the Department will continue to
promulgate the Digital Signature Standard despite uncertainties about the
patent and licenses, and it will adopt the escrowed encryption system
(Clipper) as a Government standard. Nothing in the public record supports
these decisions, and it was made clear that these decisions are driven by the
views of the law enforcement and intelligence agencies.

The purpose of citing these controversies concerning cryptography policy here
is to explicate a consequence relevant to the FIRP report. The Commerce
Department, and in particular NIST, have a conflict of interest. Like a
lawyer with two clients with intertangled interests, the Department is trying
to serve two constituencies. One constituency is the federal government as a
whole, and in that role, it must do the best job it can of interpreting the
market forces and adopting federal standards that are consistent with the
marketplace.

The Department's other constituency is the particular needs of the law
enforcement and intelligence agencies. Those agencies desire to
influence and change the direction of the marketplace. In service of
this role, NIST is adopting federal standards that reflect the
direction the law enforcement and intelligence agencies want the
market to go.

The only way for the Department to be successful is if the law enforcement and
intelligence agencies prevail and the marketplace adopts the standards the
Government is promulgating. Perhaps this will happen, and if so, the
Government's gamble will pay off. However, if the marketplace continues to
adopt RSA as the preferred public key algorithm, if DES and other non-escrowed
algorithms are used for symmetric key encryption, and if products with
encryption are become prevalent in non-U.S. markets, not only will the stated
goals of the law enforcement and intelligence communities be lost, the rest of
the federal government and indeed the rest of the country will have paid the
price in struggling with dual standards.

Like a stubborn child with a tensed jaw, the U.S. Government seems bent on
pressing forward with these initiatives. So be it. But in handing out
accolades because NIST is now willing to accommodate the protocols that have
been commonplace for many years, it's fair to note that NIST and the rest of
the Department are engaged in an exercise which promises to bring a repeat of
the same divergence, confusion and waste of resources which the FIRP report
documents.

Recommendation 3 suggests that each role and responsibility should be tasked
to some specific agency. Apparently this is aimed at reducing duplication.
While useful in principle, this approach is fragile. If the assigned agencies
are incompetent or inefficient, everyone suffers. The report does suggest
that some assignments may be decentralized. Decentralization should be
emphasized. Wherever possible, multiple approaches and multiple agencies
should be encouraged. Competition and comparison are enormously useful
forces. As noted above with respect to recommendation 1, the OMB should
encourage as much decentralization as possible and should oversee the agencies
establishing a means of measuring the results.

Recommendations 4 and 5 are oriented toward implementation of the first three
recommendations and raise fewer strategic concerns except that recommendation
5 implicitly acknowledges that the role of the U.S. Government in the
standards process shift from one of controlling the process to one of
participating in the process. As noted above with respect to recommendation
2, this shift poses an institutional challenge for the Government in general
and NIST in particular.

------------------------------

Date: ongoing
From: [email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.

SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible
and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA)
with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military
and Government machines should contact <[email protected]> (Dennis
Rears). UK subscribers please contact <[email protected]>.
Local redistribution services are provided at many other sites as well.
Check FIRST with your local system or netnews wizards. If that does not
work, send requests to <[email protected]> (not automated).

CONTRIBUTIONS: to [email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

ARCHIVES: "FTP CRVAX.SRI.COM<CR>login anonymous<CR>YourName<CR> CD RISKS:<CR>
GET RISKS-i.j<CR>" (where i=1 to 15, j always TWO digits) for Vol i Issue j.
Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>"
logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.30.65];
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
WAIS and [email protected] are alternative repositories.

FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot E-mail [email protected] .

------------------------------

End of RISKS-FORUM Digest 15.55
************************