RISKS-LIST: Risks-Forum Digest Friday 6 May 2005 Volume 23 : Issue 86
ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy
***** See last item for further information, disclaimers, caveats, etc. *****
This issue is archived at <http://www.risks.org> as
<http://catless.ncl.ac.uk/Risks/23.86.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
PDF not a good format for redacting classified documents (Bob Blakley iii)
Time Warner backup tapes lost with 600,000 records (PGN)
Hundreds of Texas driver's licenses mailed to wrong people (Peter Gregory)
False negatives on fingerprints (Jeremy Epstein)
Re: SecurID and E*TRADE (Vin McLellan)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sun, 1 May 2005 17:24:16 -0500
From: Bob Blakley iii <bob.blakley@private>
Subject: PDF not a good format for redacting classified documents
Net-net, just in case you've been in a coma or something: PDF format used to
black out portions of the classified report on the Nicola Calipari/Giuliana
Sgrena incident; Italian newspaper (Corriere Della Sera) recovered and
posted the classified text by performing a "copy and paste" operation on the
blacked-out sections. Story here:
http://it.slashdot.org/it/05/05/01/1314216.shtml?tid=172&tid=103
COTS strikes again. The main risk is in using something you don't understand.
Another risk is in having allies whose press is eager to publish information
which will endanger your troops.
------------------------------
Date: Mon, 2 May 2005 15:41:49 PDT
From: "Peter G. Neumann" <neumann@private>
Subject: Time Warner backup tapes lost with 600,000 records
Time Warner Inc. data on 600,000 current and former employees stored on
computer backup tapes was lost by an outside storage company. The Secret
Service is now investigating. The tapes included names and Social Security
information on current and former Time Warner employees, dependents, and
beneficiaries, back to 1986.
http://money.cnn.com/2005/05/02/news/fortune500/security_timewarner/index.htm?cnn=yes
[See also
http://www.nytimes.com/2005/05/03/business/media/03warner.html?th&emc=th
http://finance.lycos.com/home/news/story.asp?story=48820133
In addition, the *Wall Street Journal*, 3 May 2005, noted that the tapes
were lost by Iron Mountain Inc., a data-storage company based in Boston. An
Iron Mountain spokeswoman said this is the fourth time this year that Iron
Mountain has lost tapes during delivery to a storage facility. PGN]
------------------------------
Date: Thu, 28 Apr 2005 13:01:52 -0700
From: "Gregory, Peter" <Peter.Gregory@private>
Subject: Hundreds of Texas driver's licenses mailed to wrong people
An agency that warns Texans not to share personal information with strangers
because of the risks of identity theft mistakenly mailed hundreds of
driver's licenses to the wrong people. The Texas Department of Public Safety
(DPS) blamed the mixup on a malfunctioning machine that was recently
installed to sort licenses for mailing. Statewide, at least 500 to 600
people who applied for a license renewal or replacement in late March or
early April instead received somebody else's card, said DPS spokesperson
Tela Mange. A driver's license contains enough personal information for
thieves to open up a line of credit or a bank account in that name, make
long-distance phone calls or apply for a Social Security card, according to
the Texas attorney general's office. Information on the license includes a
full name, signature, birth date, height, eye color, address and a
photograph. The driver's license number, assigned by DPS, is also used by
many agencies to verify a person's identity. In the case of the mismailed
licenses, no identity theft or other crime has been reported, Mange said.
[Source: *Knight Ridder Tribune*, 26 Apr 2005]
http://www.kansascity.com/mld/kansascity/news/nation/11497175.htm
(registration required)
Peter Gregory, CELLULARONE, Western Wireless Corporation Bellevue, WA
425-586-8386 CISSP, CISA, Information Security Analyst
------------------------------
Date: Thu, 5 May 2005 16:35:39 -0400
From: Jeremy Epstein <jeremy.epstein@private>
Subject: False negatives on fingerprints
National Public Radio's Morning Edition included a report this morning that
an accused murderer using an alias had been stopped and fingerprinted
three times, but IAFIS (the FBI's Integrated Automated Fingerprint
Identification System) didn't match his fingerprints to those on file under
his real name. After the first false positive, it added his fingerprints to
the database using his alias, and subsequent matches turned up the alias
rather than his real name.
Based on the news report, there seems to be an assumption among the public
that IAFIS is 100% accurate, with 0% false negatives (the failure this time)
and 0% false positives (where someone is inaccurately accused of a crime).
IMHO, this isn't a case so much of technology failure, as it is of
unrealistic expectations of technology.
http://www.npr.org/templates/story/story.php?storyId=4631503&sourceCode=RSS
Also in the *Atlanta Journal Constitution*
http://www.ajc.com/metro/content/metro/0505/04jones.html
(free signup required).
[He was already wanted on charges of rape, sodomy, and jumping bond, and
now has been charged with three subsequent murders and suspected of
another. See an article by Ellen Barry and Jenny Jarvie, *Los Angeles
Times*, 5 May 2005]
http://www.latimes.com/news/nationworld/nation/la-na-killer5may05,0,7657766.story?coll=la-home-nation
------------------------------
Date: Tue, 03 May 2005 17:38:30 -0400
From: Vin McLellan <vin@private>
Subject: Re: SecurID and E*TRADE (Taft, Risks-23.84)
In RISKS-23.84, Ed Taft <taft@private>, Principal Engineer at Adobe, and a
respected Adobe spokesman on standards and security issues, expressed
skepticism about the security, reliably, and user-friendliness of the RSA
SecurID, the one-time password (OTP) token that E*TRADE Financial is
distributing to customers to enhance the security of their online market
trades, and the privacy and integrity of E*TRADE's brokerage records.
Subsequently, in RISKS-23.85, Jon Lewthwaite <JLewthwaite@private>,
offered the Adobe exec the vigorous if convoluted endorsement of an RSA
competitor, while Kurt Raschke <kurt@private>, a Baltimore high school
student, tech editor of the Towson High "Colophon," reacted to Mr. Taft's
complaints with wry insight.
"Ed raises these issues as though E*TRADE is the first company to ever
implement SecurID," wrote a bemused Raschke, "but in reality they are not
very grave issues, and many government labs and other organizations find
SecurID to be a very good security method despite them." Mr. Raschke, a
teenager who develops open-source projects on SourceForge, turns out to be a
veteran sysop, quite familiar with SecurID and practical security issues.
By contrast, Mr. Taft, one of the architects of Postscript and PDF, reacted
to his new SecurID as if it was the first time he had encountered a blinking
LCD:
>I recently received "The E*TRADE Complete Security System" for controlling
>access to my online E*TRADE account. It introduces two-factor
>authentication to the login process, requiring both something I know (my
>password) and something I have (a keyfob device). While this seems like a
>very good idea on the surface, the implementation leaves something to be
>desired from a usability standpoint.
RSA's SecurID is a small, hand-held, personal authentication device that
uses the US standard AES cipher, Current Time, and a 128-bit "shared secret"
to generate, and continuously display, one-time passwords: 6-8 character
"token-codes" that change every 60 seconds. E*TRADE has re-branded the RSA
OTP token as its own "Digital Security ID" and is offering it without charge
to its "Power" and "Priority" customers: independent market traders who make
15 trades per quarter, or have more than $50,000 at play in E-TRADE
accounts.
A FDIC study published in December 2004 concluded that -- with 24/7 remote
global access to financial networks now the norm; and "fraud through
impersonation" rampant -- "single-factor" password-based credentials,
susceptible to capture and replay, no longer provide financial service
customers with the credible security required for remote access to critical
infrastructure. "Two-factor authentication," said the FDIC, "should be
considered as the new security baseline for remote access to computer
systems."
Unlike banks, brokerages are not covered by the FDIC and "Regulation E"
rules that limit consumer liability and ensure that defrauded bank customers
are made whole. US brokerages usually return money that was transferred from
an account due to criminal activity, but they are not obligated to do
so. Losses due to online fraud are growing, but financial institutions
across the board worry far more about the public reaction to the drumbeat of
headlines about "identity theft" and multiple thefts of personal information
data files. Perceived risk has already had a noticeable impact on public
trust. Financial institutions increasingly rely on online channels for
margins in their delivery of retail financial services, but Gartner reports
that almost 60 percent of online consumers are "concerned" or "very
concerned" about the security of financial services' web portals.
Spurred by regulators, carping customers, foreign competitors, and consumer
surveys, all US financial institutions are looking at two-factor
authentication (2FA) -- but US brokerage firms, led by E*TRADE, the first
online broker, seem to be adapting to the 2FA requirement more quickly than
US banks. E*TRADE Financial, with assets exceeding $17 billion, is today
the 3rd largest online brokerage (by transaction volume); as well as the 3rd
largest mortgage originator; and the 8th largest financial institution
regulated by the US Treasury's Office of Thrift Supervision.
Mr. Taft described E*TRADE's new access protocol:
>The keyfob device, which carries E*TRADE and RSA logos, has a 6-digit
>display that changes once per minute. In order to login, I need to present
>my username and a password consisting of my regular fixed password
>appended with the currently displayed 6-digit number.
E*TRADE is using one of RSA's newer SecurIDs -- a smaller key-shaped token,
sometimes called a key ring "fob" -- but the SecurIDs deployed by E*TRADE
are functionally identical to those used daily by over 15 million men and
women, largely enterprise corporate employees, at over 15,000 institutions.
E*TRADE chose to substitute its own established password system -- so
customers like Mr. Taft need not memorize a new password -- for the small
password (aka "PIN") typically required as the second factor in SecurID 2FA
installations. These passwords were previously used as E*TRADE's
stand-alone authenticators, so they are surely at least marginally more
secure than the 4-digit PINs traditionally used with SecurIDs by the White
House staff, US Senators, and (as Mr. Raschke noted) employees in numerous
government agencies, American and allied, around the globe.
Mr. Taft began a querulous litany:
>While this appears to have good security, some potential deficiencies come
>to mind --
>
>* It requires more typing than the old scheme, including an unfamiliar
>sequence of characters that changes every time.
I've been a consultant to RSA for nearly as long as Mr. Taft has been at
Adobe, but Taft's fussy fretful complaints about "potential deficiencies" in
the E*TRADE initiative bewilder me. The carefully-nuanced E*TRADE
implementation is, to my mind, a case study of how to do 2FA right:
application-specific, proportional, and customer-savvy -- with the option of
cranking up the security barrier even higher, as needed, with additional
changes at the server end of the SSL link.
E*TRADE launched this program in March after an extensive pilot project in
which E*TRADE adapted the SecurID to their specific client requirements, and
carefully explored the receptivity of E*TRADE customers to 2FA. Online
investors expect their brokerage to offer security that will adapt to
evolving threats, transparently where possible, overtly when necessary.
They also demand immediate and relatively unobstructed access to their
accounts, any time, from anywhere. And when they feel secure, they buy more
financial services.
Most SecurID token-holders are corporate employees required to use 2FA to
safeguard corporate resources. E*TRADE knows consumers march to a different
drum. E*TRADE's P&P clients are given a choice: 2FA is voluntary -- and,
for these select clients, the token is free. The old password system
doesn't change; the OTP is simply an added service option. E*TRADE expects a
high opt-in from brokerage customers who realize that it's their own assets
and privacy that is at risk.
Instead of an OTP token, Mr. Taft opined, E*TRADE should have provided its
customers with digital certificates in USB plugs:
>A better arrangement would be for the keyfob to have a USB connector that
>I plug into my computer to prove that I have the keyfob.
Yet, as young Mr. Raschke noted:
>>Having a keyfob with a display allows the device to be used with any sort
>>of computer -- not every computer out there has a USB port, or one that
>>is user-accessible. What if you log in using a phone or a PDA?
USB authentication tokens are hot, the fastest-growing niche market in
personal authentication. USB ports are multi-use connectors, and their
widespread use in PC hardware has delighted PKI advocates who waited 25
years for smart-card readers on PCs. But USB is not ubiquitous. Twenty
percent of the PCs sold two years ago didn't have USB ports, and the
percentage rises rapidly with older PCs. Phones and PDAs, as Kurt noted,
lack the port. Publicly accessible PCs -- at airport kiosks, hotel business
centers, Internet cafes, conference sites -- often block USB ports to
minimize their vulnerability to vandals and other local threats.
A USB plug, for those unfamiliar with the tech, is a small injection-molded
dongle, typically with a microprocessor and sufficient memory to securely
store digital certificates and crypto keys. Plugged into a computer's USB
port and initialized with a password, it can, like a smartcard, provide
cryptographic services locally, and -- in conjunction with a public-key
infrastructure (PKI) -- over a network: two-way authentication, encryption,
digital signatures, assurances of message integrity, even "non-repudiation."
Cost-effective PKI is still an institutional challenge, and consumer PKI an
irksome Grail, but it's a rich technology.
Against all that, the SecurID offers a stark if elegant simplicity. The OTP
is available anytime, anywhere. It provides the functionality expected, and
no more -- an assurance difficult to obtain from a USB memory stick or a
smartcard with a direct circuit connection to the CPU and the Net.
Adobe's market lies largely in institutional sales, where users are
disciplined to hierarchy and PCs are standardized and routinely upgraded. A
financial services firm like E*TRADE serves opinionated individual
investors, like Mr. Taft, who have no common computing platform -- and
little patience with any service provider which tries to dictate the
configuration of their computers, let alone what communications device they
can use, when they get down to business.
(RSA, of course, invented RSA public key crypto and the PKCS protocols used
to implement certificate-based PKI. So when E*TRADE chose classic SecurIDs
over USB plugs, it wasn't because RSA didn't offer the USB option. RSA has
sold USB tokens, smartcards, Keon PKI, and BSAFE crypto modules for a long
time. RSA's newest SecurID -- one of the five models it now sells --
actually features both a LCD for OTP display and a USB plug:
<http://tinyurl.com/9rqoq>.)
Mr. Taft had another worry about the E*TRADE setup:
>* What if I need to login when I don't have the keyfob? There is a phone
>number I can call to obtain temporary-access instructions, assuming that I
>can convince the agent that I am the legitimate owner of the account. This
>seems like a potential weak link in the scheme.
Anything less than 2FA is inherently less secure, but jeeeze! -- the problem
of temporary credentials exists where E*TRADE still relies on static
passwords, and would exist even if the brokerage had issued USB plugs. If
Mr. Taft forgets his fob, he can still offer his password, which might gain
him some account privileges, but not others. These are local policy issues,
and E*TRADE is a financial institution which has had a lot of experience
managing this particular risk.
People are always the "weak link" in any security scheme. E*TRADE customers
are people with power, with a choice among service providers. Like C-level
executives who call their corporate help desk, privileged consumers probably
expect E*TRADE to have a human over-ride for rigid technology (and granular
levels of authorization at hand).
Mr. Taft had one prescient concern:
>* If multiple service providers adopt this scheme, I'll need a pocket full
>of keyfobs. A better arrangement would be one keyfob that can hold
>credentials for logging into multiple sites.
In the token trade, this is called the "necklace" scenario, which for me
always conjures up an image of cargo-cult Polynesian natives dancing with a
string of SecurIDs around their necks. Corporate partners deal with this
today with "federated identity" mechanisms: bilateral or group agreements to
honor one another's authentication credentials, with the privileges of the
"visitors" constrained as appropriate. (See, e.g.,
<http://tinyurl.com/43jfl>)
In consumer financial services, however, attempts to establish a
collaborative "trusted third-party" entity for federated identity management
have run afoul of competitive realities. In response, two months ago, RSA
announced the RSA Authentication Service, a managed service provider which
later this year will offer a network of bilateral authentication services
for organizations serving consumer markets.
E*TRADE immediately announced that it would be the first RAS pilot site.
RSA VP Chris Young -- who was the head of safety and security for AOL
premium services, when AOL first offered SecurIDs to its subscribers --
leads the product development team.
The RSA Authentication Service (RAS) will require only that each
participating institution has to trust RSA, as many already do for mission
critical IT services. And the design goal for RAS is for RSA to hold almost
zero information about the token-holder or his accounts.
A customer of, say, "BoldBank" may have a SecurID issued by his bank. If he
needs a broker, and he sees (on the E*TRADE website) that E*TRADE is willing
to use the BoldBank SecurID he already carries as his E*TRADE 2nd
authenticator for 2FA -- he simply gives E*TRADE the serial number embossed
on that SecurID and creates a password.
E*TRADE then asks RAS to associate that SecurID, by serial number, with an
E*TRADE-specific value -- say a pseudo-random number -- that will in the
future be used to link authentication requests from that SecurID with a
specific but unidentified E*TRADE account. RAS can now validate SecurID
authentication calls from both account providers.
The next time the customer signs on at the E*TRADE SSL portal, he provides
his account name, password, and SecurID OTP. E*TRADE will validate the
password locally. It will then link the SecurID "token-code" with the PRN
identifier it gave RAS, and pass both over to RSA for a blind validation of
the OTP.
When E*TRADE receives the RAS's validation of the OTP, it has 2FA. The
brokerage then makes the final link to the customer's account and opens that
account with whatever privileges it has conferred on the customer. The
account providers maintain total control over their customer account
information; RAS doesn't want to know who or what is involved.
Needless to say, Metcalfe's Law applies. RAS is an ambitious undertaking,
perhaps comparable to the introduction of the early ATM networks, or RSA's
spin-off of VeriSign ten years ago to exploit the potential of digital
certs. The politics of trust, and the potential risks of "one token, many
sites," will probably be the subject of RISKS commentaries at least through
Mr. Raschke's college years. Expect a few from him.
In his E*TRADE litany, Mr. Taft eventually stepped beyond grounded concerns.
>* The scheme seems to depend on the keyfob and the server to have
>synchronized clocks. What happens if the keyfob's battery dies or the
>server's clock becomes misadjusted, as appears to occur with some regularity?
Without sources or citations, without claiming first-hand experience
himself, Mr. Taft -- a gentleman of some prominence in this industry --
offers an accusation on the level of a "wife-beating" rumor. If Mr. Taft
had a competitive bias in this discussion (as I do), this would rank as
FUD: fear, uncertainty, and disinformation
If a battery fails, as Mr. Raschke put it, "replace the token. It's as
simple as that." RSA provides a full warranty on its sealed,
tamper-resistant, SecurIDs. In 17 years, I can only recall a single batch of
SecurIDs that had to be recalled (two years ago) because of electrical or
battery problems. SecurIDs are programmed for a pre-designated product life
of up to five years -- three years for the E*TRADE token, I think -- but the
risk of a flawed SecurID battery is, historically, minuscule
If and when a host server's clock becomes "misadjusted," it may (but not
necessarily) require the RSA Authentication Manager to reset -- but the RAM
(aka ACE/Server) is itself rarely the cause of any disruption in the host.
(Veteran ACE Admins on the list are invited to comment.)
No hardware/software product is perfect, but the stability and reliability
of the SecurID and its authentication server is such that it has -- for 15
years -- constantly held about a 70 percent share in a very competitive
growth market for OTP tokens. After nearly two decades in the field, RSA's
regular enhancements to the SecurID, and functional extensions for its
authentication server, can still pull in a dozen respected ""Best New
Product" and "Readers' Trust" awards. See the 04/05 prize list at:
<http://tinyurl.com/8xbdg>.
Mission-critical applications are necessarily held to a high standard. Does
Mr. Taft really believe that RSA's SecurID could be this popular, for this
long, if the employees of RSA's customers -- "with some regularity" -- were
unable to access network resources? Does anyone believe that Microsoft would
open up the Windows logon process, as it did last year -- so that SecurIDs
and 2FA could be used to replace Windows XP passwords -- if SecurID 2FA was
so undependable?
A series of time-synch patents give RSA exclusive control over the mechanism
that keeps the RAM server's clock "virtually" synchronized with the clock
chips in each of the SecurIDs pre-registered on that server. Those patents
allow for the elegant roll of 60-second OTPs on a SecurID, and that
simplicity, historically, conferred on the SecurID an ease-of-use advantage
over Challenge/Response tokens.
Some analysts expect the half-billion dollar market for "strong
authentication" tech to double over the next three years -- largely because
of new regulatory demands, in the US and elsewhere -- but the 2KA market is
also increasingly splintered among software and hardware options. OTP
tokens; smartcards; USB plugs; GSM SIMs; biometric sensors; and flash drives
are all in the hardware mix. Time-synch was the foundation of RSA's market
dominance in OTPs, but it confers no particular advantage over C/R when
smartcards or USB plugs can make a direct circuit connection with the
network. In an increasingly-level competitive field, RSA has only
reliability and innovation to hold customers and win new ones, like E*TRADE.
(OT: RSA has leveraged the SecurID's popularity, and its BSAFE crypto savvy,
into an array of oft-lauded products <http://tinyurl.com/3k334> for Identity
& Access Management, Single Sign-On, Federated Identity Management, and a
2FA-enabled Microsoft security infrastructure: SecurID for Windows.)
Mr. Taft offered a final pessimistic coda:
>Fortunately, use of this security system is optional. The RISK is that
>nobody will use this scheme because it is too inconvenient.
The real RISK here is that someone might be influenced by Mr. Taft.
Mr. Taft, maybe, is going to refuse to use the free E*TRADE token? As an
E*TRADE customer, that's his privilege. Risk, like convenience, is
relative. Threats that move me or others to mitigate a risk may not
motivate Mr. Taft enough to get him to type an additional six digits.
Mr. Taft, however, seems to be recommending that other E*TRADE customers
should reject the E*TRADE 2FA tokens. "Fortunately," he concludes, all
distant and academic, they don't have to use the SecurIDs. Is Mr. Taft
urging E*TRADE investors to ignore the free E*TRADE tokens? Urging them,
instead, to continue to use static passwords, on vulnerable PCs, to execute
market trades and access their financial records?
That, from a prominent IT professional, strikes me as mischievous, if not
irresponsible.
PS. My bias is overt. I have been a consultant to RSA since before the
first SecurID was brought to market, and an evangelist for OTPs even before
that. I beg the indulgence of the List and PGN for length, but its been a
quiet weekend on the Net, and a rainy Sunday here.
Vin McLellan + The Privacy Guild + <vin@private>
22 Beacon St., Chelsea, MA 02150
------------------------------
Date: 29 Dec 2004 (LAST-MODIFIED)
From: RISKS-request@private
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. Mailman can let you subscribe directly:
http://lists.csl.sri.com/mailman/listinfo/risks
Alternatively, to subscribe or unsubscribe via e-mail to mailman your
FROM: address, send a message to
risks-request@private
containing only the one-word text subscribe or unsubscribe. You may
also specify a different receiving address: subscribe address= ... .
You may short-circuit that process by sending directly to either
risks-subscribe@private or risks-unsubscribe@private
depending on which action is to be taken.
Subscription and unsubscription requests require that you reply to a
confirmation message sent to the subscribing mail address. Instructions
are included in the confirmation message. Each issue of RISKS that you
receive contains information on how to post, unsubscribe, etc.
INFO [for unabridged version of RISKS information]
.UK users should contact <Lindsay.Marshall@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> The INFO file (submissions, default disclaimers, archive sites,
copyright policy, PRIVACY digests, etc.) is also obtainable from
<http://www.CSL.sri.com/risksinfo.html>
The full info file may appear now and then in future issues. *** All
contributors are assumed to have read the full info file for guidelines. ***
=> SUBMISSIONS: to risks@private with meaningful SUBJECT: line.
*** NOTE: Including the string "notsp" at the beginning or end of the subject
*** line will be very helpful in separating real contributions from spam.
*** This attention-string may change, so watch this space now and then.
=> ARCHIVES: ftp://ftp.sri.com/risks [subdirectory i for earlier volume i]
<http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue.
Lindsay has also added to the Newcastle catless site a palmtop version
of the most recent RISKS issue and a WAP version that works for many but
not all telephones: http://catless.ncl.ac.uk/w/r
<http://the.wiretapped.net/security/info/textfiles/risks-digest/> .
==> PGN's comprehensive historical Illustrative Risks summary of one liners:
<http://www.csl.sri.com/illustrative.html> for browsing,
<http://www.csl.sri.com/illustrative.pdf> or .ps for printing
------------------------------
End of RISKS-FORUM Digest 23.86
************************
This archive was generated by hypermail 2.1.3 : Fri May 06 2005 - 17:44:30 PDT