Subject: RISKS DIGEST 15.52 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 11 February 1994 Volume 15 : Issue 52 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: Cygnus Support frees its security software to beat Internet break-ins (John Gilmore) Re: Campaign and Petition Against Clipper (Dorothy Denning, Marcus J. Ranum, Carl Ellison, Paul R. Coen) Re: Notes on key escrow meeting with NSA (Roy M. Silvernail) Re: Coincidences (Sniffers, Breakins, and EES) (A. Padgett Peterson) Re: Verify your backups (Li Gong) Re: Electronic Keys vs. The Old Kind (Morgan Price) * New List on Computer/Telephone Problems/Bugs/Viruses/Dangers (Paul Robinson) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 10 Feb 1994 09:49:52 -0800 From: John Gilmore Subject: Cygnus Support frees its security software to beat Internet break-ins Cygnus Support Frees Its Security Software To Beat Internet Break-Ins MOUNTAIN VIEW, Calif., February 10, 1994 - Cygnus Support today announced public availability of its Cygnus Network Security (CNS), a software solution to guard against the recently publicized rash of break-ins over the Internet. Cygnus Network Security is a freely available, stable, tested version of Kerberos, the well known network security software. Cygnus Support is giving CNS to the public in an effort to protect users of the "data superhighway". The Internet community gains an immediate solution for this break-in problem. Organizations can then contract with Cygnus to develop more comprehensive long-term security strategies. The rapid evolution of information technology has opened the doors of communication while leaving many sites vulnerable to break-ins. The Computer Emergency Response Team (CERT) reported last week that intruders had captured access information for tens of thousands of systems across the Internet. CERT advised all Internet users to change passwords, but this is not enough to prevent this type of break-in in the future. "This security vulnerability has been there for a long time, but the crackers have only taken advantage of it in the past year," said Michael Tiemann, president of Cygnus Support. "It's well past time to solid countermeasures. Kerberos is the only protection that's freely redistributable, software-only, well supported and ready for use today." CNS prevents passwords from being sent over the Internet in clear text. Kerberos uses DES encryption to validate the user's password on a local machine, rather than sending it across the net to a remote machine. This prevents the password from being captured off the network and used by crackers. CNS provides network-level security and eliminates the single largest risk that Internet users face today. Cygnus Network Security software is offered free of charge over the Internet, and is available by calling Cygnus Support at 1 800 CYGNUS-1 or +1 415 903 1400. Due to U.S. export policy, Kerberos is only available in the United States and Canada at this time. After calling Cygnus Support and verifying their location, users will be told where on the Internet to download the software. CNS includes installation notes, complete source and binary code, and preliminary documentation. The Internet release is provided as-is and without support; users who want help with installation or use must contract with Cygnus for it. CNS binaries are provided for these Unix platforms: SPARC (both OS's), DECstation, HP 700, and Sun-3. CNS is not currently available for PC's or Macintosh. Other platforms are under development. Commercial support for Cygnus Network Security is available from Cygnus Support. Cygnus offers installation support, fast maintenance response, printed documentation, periodic releases, and custom development work, including ports of CNS to specific platforms. Customers need not be on the Internet to use Cygnus Network Security support. Prices start at $5000 and vary depending on the number of users supported. Cygnus Support was founded in 1989 to provide commercial support for sourceware. Sourceware is supported, centrally managed software whose source code is openly available. Cygnus provides a full range of products and services for software developers, including site support, custom development, and open systems solutions, in North American, Europe, and Asia. The company is based in Mountain View, Calif., with an office in Cambridge, Mass. To get copies of the software, call +1 800 CYGNUS 1 or +1 415 903 1400, and say you want the free Kerberos software. Press contacts: Erin McCormick Terri Thatcher, Cunningham Communication Cygnus Support +1 408 982 0400 +1 415 903 1414 ------------------------------ Date: Fri, 11 Feb 1994 14:09:16 -0500 (EST) From: denning@cs.cosc.georgetown.edu (Dorothy Denning) Subject: Re: Campaign and Petition Against Clipper (RISKS-15.48 and 15.50) The following comments are in response to responses posted in RISKS-15.50 on my earlier comments in RISKS-15.48: >From Marc Rotenberg: > > The NSA is responsible for foreign signal interception. It has no legal > authority to conduct wire surveillance. What are the NSA's "national > security" interests in domestic wire surveillance? I do not believe that NSA has any particular interest in domestic wire surveillance. I expect their concern is that if a product with a very strong algorithm such as SKIPJACK were to be manufactured without keys being escrowed, then such products would be very attractive on the foreign black market (presumably, such products would not be exportable) where they could interfere with foreign intelligence. > The FBI made certain claims that cryptography was impeding criminal > investigation conducted by wiretap. CPSR investigated the FBI's claims by > filing a Freedom of Information Act suit to obtain the relevant documents. > The documents provided to us by the Department of Justice revealed that none > of the FBI field officers had encountered any obstacles. The Department of > Justice has just informed us that they provided to us all relevant documents > concerning the Clipper proposal. In testimony before the Computer Systems Security and Privacy Advisory Board (CSSPAB) at NIST, James Kallstrom of the FBI said that encryption was stymying the effort in more than three but less than ten of ongoing cases. The FBI does not give details of ongoing investigations, so this information would not be available through FOIA. > There is one reported case where cryptography made it difficult for law > enforcement to obtain evidence. That case concerned reading the contents of a > file on a hard disk after it was seized. > > If this is the problem that the Clipper proposal is intended to solve, then > the key escrow scheme must be extended to every single encrypted file -- not > just encrypted communications -- everywhere in the world. I've heard of 3 cases now where encrypted files could not be decrypted, but law enforcers seem to be much more concerned about communications than stored files. Clipper does not address file encryption. > An FBI legislative proposal now under consideration at the White House would > mandate a Clipper-like scheme. That proposal is backed by fines up to $10,000 > per day and jail time. Everything I've seen has said Clipper is voluntary. Quoting from the standard: "This standard does not mandate the use of escrowed encryption devices by Federal government agencies, the private sector or other levels of government." Dept. of Commerce, NIST, Docket No. 930659-4017, RIN 063-AB19, Approval of FIPS 185, Escrowed Encryption Standard (EES). > > I support this objective. Unfortunately, it is not > > possible for most of us to be fully informed of the > > national security implications of uncontrolled > > encryption. For very legitimate reasons, these cannot > > be fully discussed and debated in a public forum. > > This assertion has never been supported by evidence. It has been used simply > to stifle criticism. Certain information relating to foreign intelligence operations is classified. Are you saying that decisions should not be based on classified information or that foreign intelligence information should not be classified? > CPSR did not participate in the inter-agency policy review. Our position from > the very beginning is that these decisions must be made openly. As part of the inter-agency review, the CSSPAB was asked to sponsor hearings on the proposal. These were held in June. The testimony that was presented was given to the government. Marc gave a presentation at those hearings, as did David Banisar of CPSR. Several people in the government who have been participating in the inter-agency review were present at the hearings. There have been several other forums as well, including one sponsored by CPSR last June. Again, several people participating in the inter-agency review were present. > > In the absence of understanding > > the national security issues, I believe we need to > > exercise some caution in believing that we can > > understand the full implications of encryption on society. > > This premise, if accepted, would mean that people in the United States would > have no right to express political views when the government claimed "national > security." Certainly, there are matters of national security that must be I did not mean to suggest that people should not express their views. Being cautious is different from being silent. >From George Talbot: > > Second, law enforcement needs to get a court order to intercept phone > communications. I know of no such need to get a court order to intercept > communications on a high speed network w.r.t. Capstone. The current > administration proposal does not require a court order to get the escrowed > keys themselves. You need a court order to intercept any electronic communications, including those on high speed nets. You need a court order to get keys. Although the court order is not given to the escrow agents (to protect the identity of those under investigation), certification that one was obtained must be presented to the escrow agents. In addition, this certification must be confirmed by an attorney associated with the U.S. Attorney's office (for a Title III federal wiretap) or an attorney associated with the DOJ Office of Intelligence Policy and Review (for a FISA wiretap). For a local wiretap, the certification must be submitted by the principal prosecuting attorney of the state or political subdivision thereof. Fred Cohen wrote: > > >Hundreds of people is hardly overwhelming in a population of 250 million ... > > Do you claim to believe that the great silent majority is in favor of Clipper? No I do not. I was merely attempting to point out what I believed was RISKy logic. > > In the light of 5,000 years of cryptographic history where experts claimed > that systems were very strong only to find them broken soon after, I find it > hard to trust the hand picked committee of 5 so-called experts who are given > money and time to pass judgement on a technology that is so weak that they are > afraid to expose it to the light of day. If it is so strong, why not let the > rest of the world review it? The German experts said the same thing about We were not paid. The main reason for not making the algorithm public is that one could build inter-operable products that bypassed key escrow, but that took advantage of the very strong algorithm. > > Why is it that you think you understand more about the implications of > cryptography on national security than the rest of us? This elitist crap has > got to end. It is bad for our country to have elitists who believe they know > more than the rest of us dictating how we will live our lives. It is bad for > our country that the esteemed members of this forum do not have access to your > rational in order to openly discuss your points of view. It is bad for our > country that professors at universities tell their students and the public not > to think about the issues, but to trust that the professors know best. If you > want to serve the national interest, get the debate out in the open! > I did not mean to suggest that I understood the national security issues. I do not. Nor did I mean to suggest that people should not think or talk about the issues. Dorothy Denning ------------------------------ Date: 11 Feb 1994 14:52:03 GMT From: mjr@tis.com (Marcus J. Ranum) Subject: Re: Campaign and Petition Against Clipper (Kuenning, RISKS-15.50) Geoff Kuenning writes, with respect to NSA: >Personally, I don't see why I should trust any person or agency that is so >secretive. This is the same logic that many fear would be applied by law enforcement against people using non-approved non-clipper crypto: "if they aren't using clipper, they must have something to hide." Funny how the better swords tend to be double-edged. mjr. ------------------------------ Date: Thu, 10 Feb 1994 19:33:44 -0500 From: Carl Ellison Subject: Re: Denning's Clipper defense (RISKS-15.48) Prof. Denning has issued a defense of the Clipper proposal (which she advocated in a CACM article long before the initiative was announced). Her specifics are easy enough to refute and I'm sure others will do so. However, she closes with an idea so radical that it shocked me. Her idea that we citizens need a security clearance in order to enter the debate over whether or not we should give up a right we've had for all time (to make, use, disseminate, ..., our own strong cryptography, interfering with the government's ability to spy on us) is so radically off base that the technical debate pales by comparison. My grade-school social studies teacher is doubtless spinning in her grave. On this point, I would like to hear from newly freed members of the Eastern block. - Carl Ellison ------------------------------ Date: Thu, 10 Feb 1994 11:43:03 -0500 (EST) From: "Paul R. Coen" Subject: Re: Campaign and Petition Against Clipper This is a reply to Dorothy Denning's message in Risks 15.48: >... A telephone system >for purposes of this standard is limited to a system which is circuit switched >and operating at data rates of standard commercial modems over analog voice >circuits or which uses basic-rate ISDN or a similar grade wireless service." The wire running to your house will be part of the basic telephone system, just as it is now. And with "standard commercial modems" becoming much faster in the next year or so, I expect them to last longer. As far as the "analog" part goes, they're trying to take care of that, too. >The standard will not make it any easier to tap phones, let alone >computer networks. No, but the Digital Telephony requirements will -- more on that later. >Law enforcers still need to get a court order just to intercept the >communications in the first place, Law enforcement does. Those with national security concerns have a much less stringent procedure, if I'm not mistaken. I think it's a bit more than throwning a brick in the air and chanting "National Security" three times, but not much. And if someone overseas is dumb enough to use Clipper, it's pretty easy as well. >The standard will make it much harder for anyone to conduct illegal taps, >including the government. I'll buy that up through the "including the government" part. You can't prove that the escrow system cannot be compromised. And the DOJ stated that if the procedures are not followed, it will not be grounds to throw out the evidence. >Keys are escrowed so that if someone uses this technology, they cannot use it >against national interests. So it's for our own good? >As near as I know, neither CPSR nor any other group has conducted any >systematic poll of industry, professional societies, or the public. While >many people have voiced opposition, there are many more organizations and >people who have been silent on this issue. I thought the NCSA did a survey of IS professionals, and found that they opposed Clipper by 260 to one. I don't know how systematic or not that survey was, however. Perhaps you or someone else has more information. >The 1987 Computer Security Act states that NIST "shall draw on the technical >advice and assistance (including work products) of the National Security >Agency." Advice is one thing. However, it does seem that the NSA is capable of either officially or unofficially scrapping any crypto scheme it doesn't like -- for any reason. >The standard is voluntary -- even for the government. Do you think that will last? I can't see how it is going to avoid becoming either a requirement or a de facto requirement. It's really doomed otherwise. Or are they going to make it a crime to encrypt communications for the purpose of criminal activity with something other than Clipper? >For very legitimate reasons, these cannot be fully discussed and debated in >a public forum. Convenient, isn't it? >Unfortunately, it is not possible for most of us to be fully informed of the >national security implications of uncontrolled encryption. We already have uncontrolled encryption outside of the United States. Folks in other countries are just as clever as we are, and there are a lot of articles about encryption in general out there. So what are we doing here? In order to insure that some folks don't misuse the technology, there's a built-in feature for decoding the communications. The FBI knows full well that only "dumb criminals" are going to use Clipper. So what does that mean? In order to protect us, the government wants us to use an encryption technology that they can unlock -- a technology that none of the "real threats" are using? >It is even difficult to talk about the full implications of encryption on >law enforcement. Why? I think many of us have a pretty good grasp of the issue. And I think that if you look at the number of wiretaps and the number of cases where encryption technology was a problem, you'll find that few really made a difference in a case. Wiretaps are not that useful in many ways. Informants, financial records, physical evidence, and "bugs," either planted on people or in locations are far more useful. >The Feb. 4 decision was made following an inter-agency policy review, >headed by the National Security Council And we all know the extensive confirmation process that appointees to the NSC goes through in the Senate, thus giving the legislative branch a measure of oversight. Oh, wait, that must be in some other reality. Sorry. This is the reality where more and more tasks have been shunted over to "groups" and "councils" outside of the normal channels of oversight. >considerable input from industry, CPSR, EFF, and individuals as well as from >law enforcement and intelligence agencies. And surprisingly enough, the government decided to place the government's priorities first. >In the absence of understanding the national security issues, I believe we >need to exercise some caution in believing that we can understand the full >implications of encryption on society. "Trust the government." No thank you. Various agencies and departments have done little to earn that trust, and have shown a willingness to violate the Constitution for "greater interests" that turned out to not be so great. >Interagency Working Group on Encryption and Telecommunications, chaired by the >White House Office of Science and Technology Policy and National Security >Council, with representatives from Commerce, Justice, State, Treasury, FBI, >NSA, OMB, and the National Economic Council. Ah, yes. The IWGET. Chaired by whom? Oh, I see. No oversight, no accountability. >The group is to work with industry and public interest groups to develop >new encryption technologies and to review and refine encryption policy. Oh, and also to resurrect the Digital Telephony issue. You forgot that one. >From the press release: In addition, the working group will coordinate Administration policies regarding digital telephony. As more and more telephone companies install high-speed, digital communications links, it becomes more and more difficult for law enforcement agencies to conduct wiretaps. The working group will work with industry to ensure that new digital telecommunications systems are designed in a way that ensures that do not prevent court authorized wiretaps. I'm really having a hard time with Clipper. Depending on which spin you look at, it's either a totally pointless, massive waste of time and money that nobody in their right mind will adopt, or else it's an Orwellian plot to push an encryption technology that Uncle can break. Neither view is really attractive. I'd actually bet more on the first. Or is this whole issue a smokescreen? Is this just an attempt to try to co-opt the issue of liberalization of encryption regulations? Or is it an attempt to make the digital telephony proposal more palatable? Paul Coen, Drew University Academic Technology | pcoen@drunivac.drew.edu ------------------------------ Date: Thu, 10 Feb 1994 22:45:12 CST From: roy@sendai.cybrspc.mn.org (Roy M. Silvernail) Subject: Re: Notes on key escrow meeting with NSA (Blaze, RISKS-15.48) > The LEAF field contains 80 bits for the traffic key, encrypted via the unit > key in "~a unique mode ~", 32 bits for the unit id, and a 16 bit > checksum of some sort. (We didn't waste our breath asking what the checksum > algorithm was.) This is all encrypted under the family key using "~another > mode ~". One of my concerns from the beginning of the Clipper/Capstone proposal was that the LEAF would not be protected to the same extent as the primary traffic. This paragraph confirms that the LEAF is encrypted at least differently. The RISK here is that the session keys may be vulnerable to a less rigorous cryptographic attack than the traffic itself. So it may not be necessary to even go through the dance with the escrow agencies to compromise a Clipper/Capstone chip. Of course, the Skipjack algorithm would still be required for decrypting the traffic, but it would still appear that this is a vulnerability. I wish this point had come out earlier. Roy M. Silvernail roy@sendai.cybrspc.mn.org ------------------------------ Date: Fri, 11 Feb 94 12:03:08 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Coincidences "Once is happenstance, twice is coincidence, three times is enemy action" _You Only Live Twice_ by Ian Fleming On February 3rd, the CERT issued a warning concerning password breaking sniffers that had compromised thousands of passwords on the Internet. This was picked up by thousands of newspapers. One line read "The best long term solution...is to reduce the transmission of reusable passwords in clear-text over the network." I am told that this problem had been known by experts for quite some time before the alert. On February 4th, the administration reaffirmed the Clipper/Capstone initiative. Now I am waiting for the announcement of a "Capstone Ethernet Card" that will protect "Information Superhighway" users from such sniffers. Number three ? Padgett ------------------------------ Date: Fri, 11 Feb 94 14:03:27 -0800 From: Li Gong Subject: Re: Verify your backups tsm@cs.brown.edu (Timothy Miller) suggested in RISKS DIGEST 15.49 that lost files (because of failed backups) could be restored from the many mirror sites. Professor Jerome Saltzer of MIT argued in a paper at the SIGOPS European Workshop (1990) that large scale replication may indeed eliminate the need for the kind of backup being done today. See ACM Operating Systems Review 25(1):81-82 for details. Li Gong, SRI International, Computer Science Lab, Menlo Park, CA 94025, USA ------------------------------ Date: Fri, 11 Feb 94 17:17:17 EST From: Morgan Price Subject: Electronic Keys vs. The Old Kind (Kaiser, RISKS-15.47) > An electronic key with a chip in its tip is to be marketed by the > locksmiths, Chubb Security of Sunbury-on-Thames. The key, called > Eloctro, has a tiny silicon chip which stores a unique number > ranging from 10 to 70 000 billion. >Several rather evident risks there. But compared to the technology it replaces, I think not. There's a lot of trained locksmiths, and a much smaller number of hackers with oscilloscopes. -- Morgan Price ------------------------------ Date: Fri, 11 Feb 1994 13:38:11 -0500 (EST) From: Paul Robinson Subject: New List on Computer/Telephone Problems/Bugs/Viruses/Dangers This is to announce the creation of a list for the public disclosure of bugs, system problems, viruses, and any other conditions in a computer system that people should be aware of so they can fix the problem. It is also appropriate to report security holes, dangerous conditions in PBXs, cellular and wire telephone systems, and other computer-controlled devices. Also reports of things such as default accounts and passwords on systems that should be changed, etc. The focus will be on reporting clear descriptions of problems including how to generate them. The idea being that this will alert people to the nature of certain problems that they might be unaware of. Reproducing these conditions lets others know what is being done, and can allow people to post solutions on how to block them. The purpose in creating this list is that currently, the only means currently available for reporting discovered security holes in computer systems and possibly other areas is via the Computer Emergency Research Team (CERT) out of Carnegie Mellon University. The problem with CERT reporting is that the reports generally tend to be done in secrecy, and it fails to let system administrators and others know about what is happening so that these things can be fixed. In short, CERT acts like a black hole and takes too long to publicize problems until lots of places get hit because they didn't know about it. Some people feel that reports should not be publicized because potential reports might become available to "the bad guys." Well, the truth of the matter is that "the bad guys" trade their discoveries around all the time; the current use of secrecy is only hurting "the good guys" who want to protect their systems. This list has just been created, and pending creation of an automated processor will be temporarily moderated since my current equipment does not yet tell me what address the message is sent to. This will be changed in the next two weeks. There will, however, be two addresses. The general list will be PROBLEMS@TDR.COM which is used to post a report to the list. To subscribe to the list, use PROBLEMS-REQUEST@TDR.COM Currently, both addresses are moderated. This will change shortly as I upgrade the software on my system. Persons wishing to make a report but not be identified should state so in the text of their message. In the future, they will do so by using the -request address which will come to me directly. Persons wanting to receive this service by facsimile should contact me for details. All messages requesting subscriptions or posting information will be acknowledged. Please pass this announcement around. It is my intent to set this up such that people can publicly report known bugs, viruses and problems in clear detail so everyone knows about them and can encourage much faster response to these problems than is currently available. It may even embarrass some manufacturers into making fixes sooner when their errors are glaringly exposed in public. Paul Robinson - Paul@TDR.COM [I presume that RISKS will try to avoid duplication of detailed discussions with PROBLEMS, but may provide summary information and pointers to issues, as appropriate. PGN] ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. PLEASE read it as a newsgroup if possible and convenient for you. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line; others may be ignored! Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially .UUCP folks. If you cannot read RISKS locally as a newsgroup (e.g., comp.risks), or you need help, send requests to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS"; UNSUBSCRIBE RISKS if needed. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousYourName CD RISKS:GET RISKS-i.j" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. 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 risks-request@CSL.SRI.COM . 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. ------------------------------ End of RISKS-FORUM Digest 15.52 ************************