precedence: bulk
Subject: RISKS DIGEST 18.93

RISKS-LIST: Risks-Forum Digest  Monday 24 March 1997  Volume 18 : Issue 93

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

***** See last item for further information, disclaimers, caveats, etc. *****

 Contents:
Splendour of the Seas not so Splendid (Mich Kabay)
County Data Trouble (Dave Rand)
Bill Would Outlaw Online Gambling (Edupage)
Legal action against Internet provider affects customers (Klaus Johannes Rusch)
Austria to disconnect from Internet on March 25 (Gary Beckmann)
On looking before you leap? (Dick Mills)
The Year 2000 Problem -- a new principle for Y2K tools (Thomas Reps)
Retiring hardware after Y2K (Matt Welsh)
Virtual Real-Estate (Tony Lima)
"The Illusion of Truth" in action: apology to Simson Garfinkel (Troy Heagy)
Net random-number server (Stefek Zaba)
"Emergency" Web Access! (Robert J. Woodhead)
Re: Telephone Scam (James Byers)
Area code split and verification (Alan K. Jackson)
Re: Risks of online commerce (Bob Frankston)
1997 IEEE Symposium on Security and Privacy program (Mike Reiter)
Abridged info on RISKS (comp.risks)

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

Date: Mon, 24 Mar 1997 05:19:27 -0500
From: "Mich Kabay [NCSA]" <[email protected]>
Subject: Splendour of the Seas not so Splendid

The Canadian _Globe and Mail_ newspaper (97.03.22, p. A17) reports that
computerization hit choppy waters on a recent cruise:

 Splendour on the seas:
 As we learned one evening, computer problems aren't the sole domain of
 land lubbers.  Nowadays, everything is run by the darned things -- even
 cruise ships.

 By Helga Loverseed

 An after-dinner power failure was probably not what the captain had in
 mind as part of our evening's entertainment, but just as we were downing
 our dessert, there was an ominous thump and we were plunged into darkness.

The author makes the following key points:

* Splendour of the Seas is a fully computer-dependent cruise ship.
* After 8 months trouble-free, the ship developed "computer problems" when
 it sailed through the Caribbean.
* The author writes that "the computers evidently didn't like the hot,
 humid climate."
* The computer failure lasted 2 hours; during that time, the ship was dead
 in the water.
* In addition, lights were dim, air-conditioning was off, and toilets
 wouldn't flush.

This behemoth is 11 stories tall, 112 metres long, and 35 metres wide.  It
houses 2,077 passengers and 723 crew and includes amenities such as a
jogging track, shopping, movies, bars, and even an 18-hole miniature golf
course.  The ship depends on computer-driven stabilizers to control roll in
rough seas.

[Comments by MK:

If the main screws and the ship's toilets don't work without computer
control, what else is computer controlled?  Navigation?  Communication?

Why was the time to repair two hours?  Are there no backup systems or were
the backup systems also down?

If anyone has more information about this incident, please contribute to
this thread.

As for me, I hope the ship's officers test its computers to see if they are
Year-2000 compliant ...

Mich

M. E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)  http://www.ncsa.com

 [I suppose it might add to the hypothetical risks if the ship were to
 cross the equator for the first time precisely at the Y2K midnight!  PGN]

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

Date: Mon, 24 Mar 1997 08:37:58 -0600
From: Dave R <[email protected]>
Subject: County Data Trouble

From *The Dallas Morning News*, 24 Mar 1997, datelined Lubbock, TX:

A cranky county computer has resulted in some minor traffic scofflaws being
listed in official records as drug offenders, child molesters, or burglars,
according to the *Lubbock Avalanche-Journal* (23 Mar 1997).  Apparently, the
computer has been mismatching the names and charges of some defendants,
including one man who was cited for not wearing a seat belt but listed in
the county computer as an accused child molester.  Officials at Ki Corp.,
which developed the software, insist that the computerized criminal record
has complete data integrity.

 [whatever that means!  PGN]

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

Date: Sun, 23 Mar 1997 15:35:44 -0500
From: Edupage Editors <[email protected]>
Subject: Bill Would Outlaw Online Gambling (Edupage, 23 March 1997)

Sen. Jon Kyl (R-Ariz.) has introduced the Internet Gambling Prohibition Act
of 1997, which would make illegal the transmission of any information
related to gambling, including bets, wagers or the chance to win a prize or
lottery.  "We don't ask ISPs (Internet service providers) to be law
enforcers, constantly checking sites," says Kyl.  Rather, ISPs would be
asked to cut off Internet access only following a written notice from a law
enforcement agency.  The ISP would not be liable for any damages, penalties
or forfeiture resulting from the perpetrator's gambling operation.  (BNA
Daily Report for Executives 20 Mar 1997; Edupage, 23 March 1997)

 [Don't bet on it.  PGN]

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

Date: Sat, 22 Mar 1997 18:02:38 CET
From: Klaus Johannes Rusch <[email protected]>
Subject: Legal action against Internet provider affects customers

On 20 Mar 1997, all computer equipment at an Internet provider's office,
VIP, was confiscated by the police following an order by judge Helene
Partik-Pable, who has been investigating a charge against persons unknown
regarding the distribution of material containing child pornography more
than a year ago.  It should be stressed that the provider, VIP, is not
subject to any legal action, the confiscation is for evidence only.

Both the office rooms and the private homes of the owners were searched, and
all equipment, including private computers, office equipment which was not
even connected to Internet and computers which customers had placed at the
ISP's location and backup tapes, were unplugged (rather than properly shut
down) and taken away.

Consequently, about 2500 customers have no connection to Internet any more,
nor access to their business data and private e-mail.

References (in German):
[1] Martin J. Laubach <[email protected]> on <news:at.general>
[2] DER STANDARD, March 22, 1997, <http://www.derstandard.at/>

Klaus Johannes Rusch  [email protected], [email protected]
http://www.atmedia.net/KlausRusch/

 [Check out the full press release [1] which was also sent to RISKS
 by Martin Laubach.  PGN]

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

Date: Mon, 24 Mar 1997 17:18:36 -0500
From: Gary Beckmann <[email protected]>
Subject: Austria to disconnect from Internet on March 25

[I'm summarizing several reports I read in German.]

All the ISPs in Austria are going to pull the plug on the Internet on
Tuesday, 25 Mar 1997 from 16:00 to 18:00 MET.  This action is being taken to
protest the seizure of all the computer equipment of an ISP named ViP last
Thursday.  [...text duplicating previous message omitted...]  The ISP cannot
even begin to calculate the financial losses they will post due to this
action.

There is some disagreement among the Austrian ISPs as to the results of the
planned Internet disconnection (A Land Goes Offline), ranging from those
that worry about their contracts guaranteeing net access to those who feel
that two hours is nothing -- even one day would be barely enough to express
their outrage.  But all the ISPs have apparently agreed to the two-hour
protest shutdown.

[The risks of having agencies that don't understand the technology trying to
control it have been gone over again and again.  This is the first time,
though, that I've heard it going to this extreme.  It will be interesting to
see what the results of the protest are. --gb]

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

Date: Fri, 21 Mar 1997 15:26:08 -0500 (EST)
From: [email protected] (Dick Mills)
Subject: On looking before you leap?

I attended a firefighter's training drill this week.  We heard from a
gas/electric company representative.  He related the following anecdote.

The gas company was called to a house in Albany, NY to respond to a
complaint about a carbon-monoxide alarm activating.  When the serviceman
questioned the woman of the house about the circumstances, she said that the
alarm had been sounding since the night before.  Astounded, he asked why she
hadn't called immediately.  She replied, "My husband charged upstairs to
surf the internet for information about what to do about carbon monoxide in
the house. I'm still waiting for an answer."

The Risk?  Letting one's mind roam cyberspace while forgetting that our
bodies remain in corporeal space.  Personally, I vow to never send the
message, "FIRE! FIRE!" via e-mail.

Dick Mills +1(518)395-5154 http://www.pti-us.com aka [email protected]

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

Date: Fri, 21 Mar 1997 20:09:19 -0600 (CST)
From: Thomas Reps <[email protected]>
Subject: The Year 2000 Problem -- a new principle for Y2K tools (RISKS-18.53)

Back in October, PGN posted the following note to the RISKS newsgroup.

>> I ran into Tom Reps this morning in San Francisco ...  Tom has been
>> chartered by DARPA to make serious recommendations on the Year-2000 problem.

I would like to bring one of the results that came out of this to the
attention of RISKS readers.

As PGN indicated, the Defense Advanced Research Projects Agency (DARPA)
asked me last summer to help them plan a project aimed at reducing the
impact of the Year 2000 (Y2K) problem on the Department of Defense.  DARPA
was particularly interested in whether there were "any techniques in the
research community that could be applied to the Y2K problem and have impact
beyond present commercial Y2K products and services".  The most exciting of
the ideas that turned up concerns a method for using path profiling as a
heuristic to locate some of the sites in a program where there are
problematic date manipulations.  It works as follows:

 In path profiling, a program is instrumented so that the number of
 times each different loop-free path executes is accumulated during an
 execution run.  With such an instrumented program, each run (or set of
 runs) of the program generates a path spectrum for the execution --- a
 distribution of the paths that were executed.  Path spectra can be
 used to identify paths in a program that are good candidates for being
 date-dependent computations by finding differences between path
 spectra from execution runs on pre-year-2000 data and post-year-2000
 data.  By choosing input datasets to hold all factors constant except
 the way dates are used in the program, any differences in the spectra
 obtained from different execution runs can be attributed to
 date-dependent computations in the program.  Differences in the
 spectra reveal paths along which the program performed a new sort of
 computation during the post-year-2000 run, as well as paths --- and
 hence computations --- that were no longer executed during the
 post-year-2000 run.

With some further analysis of the spectra, for each such path that shows up
in the spectral difference, it is possible to identify the shortest prefix
that distinguishes it from all of the paths in the other path set.

For the Y2K problem, the path-spectrum comparison technique may
provide help with two aspect of the problem:

 (i)  determining the sites at which date-manipulation code occurs, and
 (ii) post-renovation testing.

Of course, the path-spectrum comparison technique is not guaranteed to
uncover all sites of date manipulations.  No technique can do this; all one
can hope for are good heuristics.  However, because path-spectrum comparison
involves a different principle from the principles that lie behind the
heuristics used in commercial Y2K tools, it should be a good complement to
current techniques.

Furthermore, the path-spectrum comparison technique is actually applicable
to a much wider range of software-maintenance problems than just the Y2K
problem; it offers new perspectives on program testing, on the task of
creating test data, and on what tools can be created to support program
testing.

This work is described in the following paper:

 Reps, T., Ball, T., Das, M., and Larus, J., "The use of program
 profiling for software maintenance with applications to the Year 2000
 Problem".  Technical Report TR-1335, Computer Sciences Department,
 University of Wisconsin, Madison, WI, January 1997.

The paper is available over the WWW at URL
 http://www.cs.wisc.edu/wpis/papers/tr1335.ps.

A prototype tool for gathering and comparing path spectra (for programs that
run under Solaris on Sun SPARCstations) has been built at the University of
Wisconsin.

(The Wisconsin Alumni Research Foundation is in the process of seeking
patent protection for these techniques.)

Tom

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

Date: 23 Mar 1997 12:43:52 GMT
From: [email protected] (Matt Welsh)
Subject: Retiring hardware after Y2K

In 18.90, Geoffrey Cooper writes:

>We decided to retire the product in (or at least upgrade the flash ROM
>by) the year 2037.

I hate to point this out, but this is exactly the mentality that caused the
Y2K problem in the first place. How do you know that all of these devices
will be out of use by 2037?

It seems that people can either fix the problem, or ignore it, or pretend to
fix it and give themselves a good pat on the back for doing so.

M. Welsh, Cambridge Computer Laboratory

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

Date: Sun, 23 Mar 1997 20:34:00 -0700
From: [email protected] (Tony Lima)
Subject: Virtual Real-Estate

In the San Francisco area, Coldwell-Banker is running an ad for their
real-estate services.  This ad shows a woman worrying about how she will be
able to keep the house clean while it is for sale, what with their three
kids, two dogs, and so on.  Her solution?  Coldwell-Banker puts their house
on the Web, keeping it (virtually) spotless.  The risks are obvious.  Next
step: virtual patching of that cracked foundation...

[email protected] (Tony Lima)

 [I'd be just as suspicious of Real Virtual-Estate.  PGN]

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

Date: Mon, 24 Mar 1997 12:14 -0500 (EST)
From: [email protected]
Subject: "The Illusion of Truth" in action: apology to Simson Garfinkel

Last week I posted a message in the Usenet newsgroup
rec.arts.sf.tv.babylon5.moderated.  The message was then forwarded to the
RISKS digest by someone else who was browsing through the newsgroups.

It looked as if I had written the article, but I did NOT.  The author of
that column, "Hard Pressed," was Simson Garfinkel.  His Webpage address is
http://www.packet.com/garfinkel .

"Hard Pressed" reminded me of the recent episode "Illusion of Truth"...how
the press reports what it wishes rather than what you actually say...and I
wanted to pass it on to Babylon 5 fans.  Rather than quote the entire
article I should have listed Simson's web page address.  OR asked his
permission to quote.  I did neither.

I apologize to Simson Garfinkel and the readers of the Risks Digest for
infringing on his copyright and for the misunderstanding this caused.

[email protected]

 [Your moderator is astounded, mortified, and apologetic that the obvious
 self-references pointing to Simson as the creator of that piece (coauthor
 of books with Spaf, friend of Beth Weise, etc. -- I had seen Simson and
 Beth at CFP just the week before) did not set off alarm bells and cause me
 to reject the message as a clear copyright violation.  However, I somehow
 missed them when selecting that item.  The volume of RISKS e-mail is
 enormous, RISKS is a pro bono effort, and this piece was really good based
 on a fast review for content that incredibly did not pick up on the
 omitted true identity of the author!  Besides, Simson has been
 occasionally sending me heads-up notices on his particularly-relevant
 Wednesday packet columns at http://www.packet.com/garfinkel, for possible
 mention in RISKS, but he did not so so on this seemingly relevant column.
 So, my apologies as well as Troy's.  We also received some groveling
 from Gary Grossoehme, who, unknowing, submitted the item to RISKS.

 In any event, this does remind us once again of the risks of enforcing
 copyrights and the importance of netiquette in attributions.  That even
 gives me a chance to remind you to check the RISKS reuse policy in
 http://www.csl.sri.com/risksinfo.html if you rebroadcast RISKS items!  PGN]

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

Date: Mon, 24 Mar 1997 22:13:08 +0000
From: Stefek Zaba <[email protected]>
Subject: Net random-number server

Among the risks not yet mentioned is the one of using an observable quantity
directly as (for example) keying material.  Since the link to the hotbits
site is not encrypted, anyone with a machine sharing the transmission medium
can see what the random bits are. The cautious crypto-oriented user of this
service will mix the bits from the net.randomness server with some
locally-generated non-predictable bits; however, the incautious might not,
and in any case if a local source of non-predictable (and non-observable)
bits is available, using an external non-predictable but observable source
adds only the illusion of security. (There are unusual applications where
non-predictability is all that's needed, and observability is irrelevant;
but it's not the common case.)

If this service were to be used for crypto applications, the bits would need
to be not just PGP-signed, as Dan Drake suggested, but encrypted. PGP use
would require the requester to send a public key with the request; SSL would
allow the secure channel to be set up with less manual intervention.

Stefek  [email protected]

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

Date: Fri, 21 Mar 1997 16:40:03 -0500
From: "Robert J. Woodhead (AnimEigo)" <[email protected]>
Subject: "Emergency" Web Access!

Like many people, I use a PPP modem-dialup to an ISP to access the net from
my portable computer.  Usually this is a local call, but occasionally when
travelling I have to make a quick long-distance call to get my email.

Recently I was at the video studio subtitling samurai films when the urge to
check email became too much.  The studio had a new phone system, so I found
out what the outside line prefix was, adjusted my PPP settings, and happily
TCP/IP'd.

The next day, back home, I plugged in my Mac and dialed up - but forgot to
revert my settings.  I dialed, immediately noticed the problem, and aborted
the attempt.

30 seconds later, the phone rang - it was 911 asking why I'd called!

My video studio had chosen "91" as their outside dialing prefix.  And, of
course, I then needed to have my modem dial 1 for long distance access, thus
putting in place a little time bomb for when I returned home!

Whoever came up with the idea of 91 as a dialing prefix ought to be stuffed
and mounted!

Robert J. Woodhead ** [email protected] ** "Anime Your Way!" tm
WWW.ANIMEIGO.COM - "REGULAR" and "LITE" flavors - CHAT room too!

 [Another variant on an old RISKS theme.  PGN]

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

Date: Mon, 24 Mar 1997 15:00:36 -0500
From: James Byers <[email protected]>
Subject: Re: Telephone Scam (Nugent RISKS-18.92; Fernandez, RISKS-18.91)

Bill Nugent correctly points out that many telcos leave dialtones on
disconnected lines for safety reasons.  However, our local phone company was
prone to crossing their lines in their jumble of antique phone equipment.

Several years ago, I mistakenly attached a phone to a disconnected line.  As
realized my mistake later that day, the phone rang!  I did not pick the
phone up, thinking that the call belonged to someone else.  It rang about
four times and then stopped.  Curiosity got the better of me and I dialed
the operator from the phone a few minutes later.  I told the operator that I
was at a pay phone that was not labeled and I wanted to know the number.
"You're at a coinbox?" she replied incredulously.  With my affirmative
reply, she gave me the number.

I dialed the phone from another line and, sure enough, my phone rang four
times and an answering machine picked up.  Apparently, our disconnected
phone was crossed with a local construction company!  The phone company
representative who got to hear this story tried to convince me that that I
was imagining things.  The representative also refused to believe that an
operator would give me the number of a domestic phone.  Not surprisingly,
their was a repair truck out on the street the next morning.  Funny
coincidence, the line got disconnected at about the same time.

The risks?  Certainly there are billing issues here that could cause someone
quite a headache.  Had I been a more malicious individual, I could have lost
the construction company a fair bit of business.  The operator also
disregarded whatever indications she had that I was not on a pay phone.
What would she have done if I had convincingly argued that I was a repairman
and needed some sort of special phone access?  Another case of a human
operator disregarding both training and diagnostic indicators.

James Byers  [email protected]  http://www.people.cornell.edu/pages/jwb19

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

Date: Mon, 24 Mar 1997 07:40:59 -0600
From: "Alan K. Jackson 245-7355" <[email protected]>
Subject: Area code split and verification

Houston split its area code a few months ago, and we are beginning to
experience many problems. The latest - my wife received a new credit
card. She called the number to enable the card, and it failed because the
number in their database didn't match the number she called from - wrong
area code!

The risk - the credit card issuer will certainly lose some business, anyone
not willing to spend the time to get a human to enable the card.

In general, this is a problem with the burgeoning systems that take
advantage of the ease with which one can now trap the number of an incoming
call.  One's database of numbers can very quickly become badly out of date.

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

Date: Mon, 24 Mar 1997 18:40 -0500
From: [email protected]
Subject: Re: Risks of online commerce

The problem of remembering purchases you made a month ago is one I
specifically dealt with in my Masters Thesis (URL on request -- I'm on a
plane so can't check it) in 1974. The basic approach is to keep a personal
log of all transactions and automatically check the bill against these to
note exceptions. The assumption is that there would be too many
microtransactions to be able to check them all, especially when there is a
delay.

Implementing this would require a payment system with a standard client-side
component. Something that is difficult in today's decentralized marketplace.

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

Date: Mon, 24 Mar 1997 14:34:44 GMT
From: Mike Reiter <[email protected]>
Subject: 1997 IEEE Symposium on Security and Privacy program

1997 IEEE SYMPOSIUM ON SECURITY AND PRIVACY
May 5-7, 1997
The Claremont Resort, Oakland, California

Sponsored by the IEEE Technical Committee on Security and Privacy
In cooperation with the International Association of Cryptologic Research

Symposium Committee:
Stephen Kent, General Chair
Michael Reiter, Vice Chair
George Dinolt, Program Co-Chair
Paul Karger, Program Co-Chair

                       PRELIMINARY PROGRAM
                        Subject to Change

Sunday May 4, 1997  4:00-7:00 Registration and Reception

Monday May 5, 1997
8:30 Introductory Remarks
9:00-10:30 Panel/Debate
       Resolved: The concept of Trusted Computing Base as a basis for
                 constructing systems to meet security requirements
                 is fundamentally flawed and should no longer be used
                 to justify system security architectures.

       Arguing in favor: Lead: Bob Blakley (IBM)
                         Second: Darrell Kienzle (U. of Virginia)
       Opposed:          Lead: William R. Shockley
                         Second: LT (USN) James P. Downey
                                 (Naval Postgraduate School)
       Moderator:        John D. McLean (Naval Research Laboratory)

11:00-12:00 Authorization and Authentication
   Toward Acceptable Metrics of Authentication
       Michael K. Reiter and Stuart G. Stubblebine (AT&T Labs--Research)
   An Authorization Scheme for Distributed Object Systems
       V. Nicomette and Y. Deswarte (LAAS-CNRS & INRIA, France)
   A Logical Language for Expressing Authorizations
       Sushil Jajodia (George Mason University), Pierangela Samarati
       (Universita' di Milano) and V. S. Subrahmanian (University of Maryland)

1:30-3:00 Applications
   Anonymous Connections and Onion Routing
       Paul F. Syverson, David M. Goldschlag and Michael G. Reed
       (Naval Research Laboratory)
   The Design and Implementation of a Multilevel Secure Log Manager
       Vikram R. Pesati, Thomas F. Keefe and Shankar Pal (Penn State
       University)
   A Secure and Reliable Bootstrap Architecture
       A. Arbaugh, David J. Farber and Jonathan M. Smith
       (University of Pennsylvania)
   An MBone Proxy for an Application Gateway Firewall
       Kelly Djahandari and Dan Sterne (Trusted Information Systems)

3:30-5:00 Security Theory
   Secure Software Architectures
       Mark Moriconi, Xiaolei Qian, R. A. Riemenschneider (SRI) and
       Li Gong (JavaSoft)
   A General Theory of Security Properties and Secure Composition
       A. Zakinthinos and E.S. Lee (Cambridge University, U.K.)
   Analyzing Consistency of Security Policies
       Laurence Cholvy and Frederic Cuppens (ONERA CERT, France)

6:00-7:30 Reception

Tuesday May 6, 1997

9:00-10:30
   Panel: Ensuring Assurance in Mobile Computing
   Moderator: Marv Schaefer (Arca)
   Panel Members: Sylvan Pinsky (NSA)
                  Drew Dean (Princeton University)
                  Jim Roskind (Netscape)
                  Li Gong (JavaSoft)
                  TBD (Microsoft)

11:00-12:00 Architectures
   Packet Filtering:  Local Enforcement for Global Policies
       Joshua D. Guttman (MITRE)
   Providing Flexibility in Information Flow Control for
   Object-Oriented Systems
       Elena Ferrari, Pierangela Samarati and Elisa Bertino
       (Universita' di Milano) and Sushil Jajodia (George Mason University)
    Automated Analysis of Cryptographic Protocols
       J. Mitchell, M. Mitchell, and U. Stern (Stanford University)

1:30-3:00 Intrusion Detection and Beyond
   How to Systematically Classify Computer Security Intrusions
       Ulf Lindqvist and Erland Jonsson (Chalmers University of
       Technology, Sweden)
   Surviving Information Warfare Attacks on Databases
       Paul Ammann and Sushil Jajodia (George Mason University),
       Catherine D. McCollum and Barbara T. Blaustein (MITRE)
   Execution Monitoring of Security-Critical Programs in a
   Distributed System: A Specification-based Approach
       Calvin Ko (Trusted Information Systems), Manfred Ruschitzka
       and Karl Levitt (University of California Davis)
   Catalytic Inference Analysis: Detecting Inference Threats due to
   Knowledge Discovery
       John Hale and Sujeet Shenoi (University of Tulsa)

3:30-5:00 5-Minute talks on breaking research results
5:00-6:00 Meeting, IEEE Technical Committee on Security and Privacy

Wednesday May 7, 1997

9:00-10:30
   Panel: Security in Innovative New Operating Systems
   Moderator: Cynthia E. Irvine (Naval Postgraduate School)
   Panel Members: Robert Grimm, Spin Project (University of Washington)
                  Frans Kaashoek, Exokernel Project
                                  (Massachusetts Institute of Technology)
                  Jay Lepreau, Flux Project (University of Utah)
                  George Necula, Fox Project (Carnegie Mellon University)
                  Larry Peterson, Scout Project (University of Arizona)

11:00-12:00 System Vulnerabilities
   Analysis of a Denial of Service Attack on TCP
       Christoph L. Schuba, Ivan V. Krsuland, Markus G. Kuhn,
       Eugene H. Spafford, Aurobindo Sundaram and Diego Zambon
       (Purdue University)
   Deniable Password Snatching: On the Possibility of Evasive
   Electronic Espionage
       A. Young and M. Yung (Columbia University)
   Number Theoretic Attacks On Secure Password Schemes
       Sarvar Patel (Bellcore)

12:00-12:15 Final Remarks

 [Truncated for RISKS.  Registration form, hotel information, etc., at
 http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/SP97pgmandreg.html .  PGN]

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

Date: 15 Aug 1996 (LAST-MODIFIED)
From: [email protected]
Subject: Abridged info on RISKS (comp.risks)

The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
if possible and convenient for you.  Or use Bitnet LISTSERV.  Alternatively,
(via majordomo) DIRECT REQUESTS to <[email protected]> with one-line,
  SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or
  INFO     [for unabridged version of RISKS information]
=> The INFO file (submissions, default disclaimers, archive sites, .mil/.uk
subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from
http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
The full info file will appear now and then in future issues.  *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to [email protected] with meaningful SUBJECT: line.
=> ARCHIVES are available: ftp://ftp.sri.com/risks or
ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
or http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
The ftp.sri.com site risks directory also contains the most recent
PostScript copy of PGN's comprehensive historical summary of one liners:
  get illustrative.PS

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

End of RISKS-FORUM Digest 18.93
************************