Crypto-Gram

April 15, 2000

by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
schneier@schneier.com
http://www.counterpane.com

A free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.

Back issues are available at http://www.schneier.com. To subscribe or unsubscribe, see below.

Copyright (c) 2000 by Counterpane Internet Security, Inc.

In this issue:

AES News

The Advanced Encryption Standard (AES) is the forthcoming encryption standard that will replace the aging DES. In 1996, the National Institute of Standards and Technology (NIST) initiated this program. In 1997, they sent out a call for algorithms. Fifteen candidates were accepted in 1998, whittled down to five in 1999. This past week was the Third AES Candidate Conference in New York. Attendees presented 23 papers (in addition to the 7 AES-related papers presented at Fast Software Encryption earlier in the week) and 12 informal talks (more papers are on the AES website), as NIST prepares to make a final decision later this year.

Several of the algorithms took a beating cryptographically. RC6 was wounded most seriously: two groups were able to break 15 out of 20 rounds faster than brute force. Rijndael fared somewhat better: 7 rounds broken out of 10/12/14 rounds. Several attacks were presented against MARS, the most interesting breaking 11 of 16 rounds of the cryptographic core. Serpent and Twofish did best: the most severe Serpent attack broke 9 of 32 rounds, and no new Twofish attacks were presented. (Lars Knudsen presented an attack at the FSE rump session, which he retracted as unworkable two days later. Our team also showed that an attack on reduced-round Twofish we presented earlier did not actually work.)

It’s important to look at these results in context. None of these attacks against reduced-round variants of the algorithms are realistic, in that they could be used to recover plaintext in any reasonable amount of time. They are all “academic” attacks, since they all show design weaknesses of the ciphers. If you were using these algorithms to keep secrets, none of these attacks would cause you to lose sleep at night. If you’re trying to select one of five algorithms as a standard, all of these attacks are very interesting.

As the NSA saying goes: “Attacks always get better; they never get worse.” When choosing between different algorithms, it’s smarter to pick the one that has the fewest and least severe attacks. (This assumes, of course, that all other considerations are equal.) The worry isn’t that someone else discovers another unrealistic attack against one of the ciphers, but that someone turns one of those unrealistic attacks into a realistic one. It’s smart to give yourself as large a security margin as possible.

Many papers discussed performance of the various algorithms. If there’s anything I learned, it’s that you can define “performance” in all sorts of ways to prove all sorts of things. This is what the trends were:

In software, Rijndael and Twofish are fastest. RC6 and MARS are also fast, on the few platforms that have fast multiplies and data-dependent rotates. They’re slow on smart cards, ARM chips, and the new Intel chips (Itanium and beyond). They’re fast on Pentium Pro, Pentium II, and Pentium III. Serpent is very slow everywere.

In hardware, Rijndael and Serpent are fastest. Twofish is good. RC6 is poor, and MARS is terrible.

The only two algorithms that had such implementation problems that I would categorically eliminate them were Mars and RC6. MARS is so bad in hardware that it would be a disaster for Internet applications, and RC6 is close. And both algorithms just don’t fit on small smart cards. (The RC6 team made a comment about being suitable for cheap—$5—smart cards. I am talking about $0.25 smart cards.)

I would increase the number of rounds in Rijndael to give it a safety margin similar to the others. Either Serpent, Twofish, and 18-round Rijndael would make a good standard, but I think that Twofish gives the best security to performance trade-off of the three, and has the most implementation flexibility. So I support Twofish for AES.

The deadline for comments is May 15. I urge you to comment. As many of the papers and comments indicate, this decision is more about suitability than security. NIST needs to know what is important to you: efficiency on cheap 8-bit smart cards, key agility in hardware, bulk encryption speed, gate count in hardware, etc. If you like the idea of multiple algorithms, tell them. If you don’t, tell them. Once NIST chooses an AES we’re all going to be stuck with it; customers will demand that products be “AES compatible.” Now’s your chance to influence how onerous that demand will be.

NIST AES website:
<http://www.nist.gov/aes>

For the record, I am one of the creators of Twofish:
<http://www.schneier.com/twofish.html>

The French Banking Card Hack

This is a cool security story, filled with interesting twists and turns. Many of the morals are things that I have been preaching about for a long time. Read about it.

The story in the Irish Times is the best:
<http://www.ireland.com:80/newspaper/finance/2000/…>

There’s a Reuters story:
<http://abcnews.go.com:80/sections/tech/DailyNews/…>

And two earlier stories about Humpich:
<http://www.zdnet.com/zdnn/stories/news/…>
<http://www.zdnet.com/zdnn/stories/bursts/…>

More coverage of the story:
<http://interactive.wsj.com/articles/…> (subscription required)
<http://www.currents.net/newstoday/00/03/11/news4.html>
<http://www.wired.com/news/technology/…>

Counterpane—Featured Research

“MARS Attacks! Preliminary Cryptanalysis of Reduced-Round MARS Variants”

J. Kelsey and B. Schneier, Third AES Candidate Conference, 2000, to appear

In this paper, we discuss ways to attack various reduced-round variants of MARS. We consider cryptanalysis of two reduced-round variants of MARS: MARS with the full mixing layers but fewer core rounds, and MARS with each of the four kinds of rounds reduced by the same amount. We develop some new techniques for attacking both of these MARS variants. Our best attacks break MARS with full mixing and five core rounds (21 rounds total), and MARS symmetrically reduced to twelve rounds (3 of each kind of round).

<http://www.schneier.com/paper-mars-attacks.html>

News

Some enterprising hackers broke the security in Cyber Patrol. For their good work, they were sued by the software publisher for illegal reverse engineering under the Digital Millennium Copyright Act (DMCA):
<http://www.wired.com/news/politics/0,1283,35038,00.html> Then they agreed to give up their rights to their hack and to never speak of it again:
<http://www.computerworld.com/home/print.nsf/all/…>
<http://www.zdnet.com/zdnn/stories/news/…>
The judge ruled that anyone who mirrored the hack needs to remove the information from their site:
<http://www.wired.com/news/politics/0,1283,35244,00.html>
<http://www.wired.com/news/business/0,1367,35258,00.html>
<http://www.politechbot.com/cyberpatrol/…>
ACLU appeals:
<http://www.wired.com/news/business/0,1367,35464,00.html>
Prof. Lawrence Lessig of Harvard Law School discusses the issues:
<http://www.thestandard.com/article/display/…>

The E.U. is investigating ECHELON.
<http://www.wired.com/news/politics/0,1283,35048,00.html>

If you have ever wondered how the special anti-shoplifting tags you see on merchandise work, this article is a real eye-opener!
<http://www.howstuffworks.com/…>

From the Department of People Who Just Don’t Get It: an article that claims that Linux is insecure because it is open source. The funniest line is: “Security needs to be built into the architecture of the operating system. This cannot happen if your source code is publicly available.”
<http://www.silicon.com/public/door?…>

A more balanced article on open-source security vs. closed-source:
<http://www.zdnet.com/pcweek/stories/news/…>

L0phtcrack as a burglary tool? Commentary from Jennifer Granick, someone who is actually qualified to have an opinion on the matter:
<http://www.securityfocus.com/commentary/7>

Free cookie-cutting browser plug-in:
<http://www.cnn.com/2000/TECH/computing/03/21/idcide/…>

Using Firewall-1 as an intrusion-detection system:
<http://www.enteract.com/~lspitz/intrusion.html>

The Computer Security Institute has released their “Issues and Trends: 2000 CSI/FBI Computer Crime and Security Survey.” It’s worth reading; get yourself a copy.
<http://www.gocsi.com/prelea_000321.htm> [link moved to http://www.gocsi.com/prelea/000321.html

Someone’s built a 7-qubit quantum computer. Any RSA moduli less than three bits should watch out.
<http://www.wired.com/news/technology/…>

An HTML virus that plagues WebTV:
<http://www.zdnet.com/enterprise/stories/security/…> [link dead; try http://chkpt.zdnet.com/chkpt/xlink100/http://…
<http://www.wired.com/news/technology/…>

MI5 laptop stolen (with government secrets):
<http://www.zdnet.co.uk/news/2000/11/ns-14318.html> [link moved to http://news.zdnet.co.uk/story/0,,s2077931,00.html]
And a few days later…MI6 laptop stolen (also with government secrets):
<http://news2.thls.bbc.co.uk/hi/english/uk/…> What is it with the British Intelligence? I hope, at the very least, that they encrypt their hard drives.

Stephen King published his latest novella electronically. The security protections were broken within two days, and unprotected copies were available on the Internet. This should not surprise anyone. (The other interesting factoid is that apparently despite the widespread piracy, the experiment can was a rousing success. He could have expected to make about $10,000 selling it to Playboy; early reports are that he made about $450,000 in e-book sales.)
<http://www.ebooknet.com/story.jsp?id=1671>
<http://www.computerworld.com/home/print.nsf/all/…>
<http://www.zdnet.com/zdnn/stories/news/…>

Hacking tools for Palm Pilots from the L0pht:
<http://www.l0pht.com/~kingpin/pilot.html>

Invisible Ink:
<http://ruddick.com/tim/RAP/rap.html>

A nice overview of Sarah Flannery and the Cayley-Purser algorithm’s rise and fall, including her reactions to its demise and what she’s doing now.
<http://www.ireland.com/newspaper/features/2000/0318/…>

The FBI says that cybercrime has doubled. My guess is that the reporting of it has doubled, as network administrators are more aware of the dangers. It looks like the FBI is jockeying for more money and more power.
<http://www.zdnet.com/zdnn/stories/news/…>

The effects of complexity on security: This is a good example of hidden interactions between systems. It seems that the security in Internet Explorer 5.0 can interact with Windows 2000 to completely lock up the system.
<http://www.zdnet.com/zdnn/stories/news/…>

The demand for round-the-clock security services:
<http://www.zdnet.com/pcweek/stories/news/…>

An elliptic-curve public-key challenge is broken. Certicom is crowing about how this shows that elliptic curves are much stronger than RSA. Honestly, I’m not sure how it shows that.
<http://cristal.inria.fr/~harley/ecdl/>

Risks of Digital Signatures:
<http://www.zdnet.com/zdnn/stories/news/…>

The Sixth Circuit Court of Appeals reverses the Junger decision, affirming that source code is speech. Now we have two circuit courts saying this.
<http://www.wired.com/news/politics/0,1283,35425,00.html>
<http://dailynews.yahoo.com/h/ap/20000404/tc/…>
Actual opinion:
<http://pacer.ca6.uscourts.gov/cgi-bin/getopn.pl?…>

Enigma machine is stolen:
<http://www.wired.com/news/politics/0,1283,35409,00.html>
<http://www.wired.com/news/politics/0,1283,35433,00.html>
Some news reports claimed it was one of three in the world. This is wrong; it was one of three at Bletchley Park.

Canada is thinking about tightening its crypto export controls, to bring it more in line with the U.S.
<http://www.ottawacitizen.com/national/000405/…>

Tools and methodologies of script kiddies. Good article on the importance of reading and interpreting audit logs.
<http://rootprompt.org/article.php3?article=159>
<http://rootprompt.org/article.php3?article=167>
<http://rootprompt.org/article.php3?article=186>
<http://rootprompt.org/article.php3?article=210>

Good commentary by David Banisar on the FBI’s plans to watch us all:
<http://www.securityfocus.com/templates/article.html?…>

Cartoon:
<http://metalab.unc.edu/Dave/Dr-Fun/df200004/…>

Intel is open-sourcing their CDSA (Common Data Security Architecture) software:
<http://www.zdnet.com/enterprise/stories/main/…>

The Doghouse: Cyber Security Information Act

This bill—HR 4246—shields information about network insecurities, transferred from industry to the government, from Freedom of Information Act requests. This kind of thinking flies in the face of the full-disclosure movement that has resulted in thousands of security bugs being fixed over the past several years, and moves us back to a world of manufacturers keeping vulernabilities secret and not bothering to fix them. It also facilitates a government database of security vulnerabilities, that they can use to invade citizens’ privacy. It also will make it much harder to design open security standards; government agencies will be much more likely to say things like: “You should design it this way, but we can’t tell you why.” Historically, public disclosure has proven to be the best way to increase security. Laws that reverse that trend are a bad idea.

Essay on the topic:
<http://www.securityfocus.com/news/17>

The bill itself:
<http://www.cdt.org/legislation/106th/access/…>

Microsoft Active Setup “Backdoor”

When you install the Microsoft Internet Explorer browser 4.0 or higher on Windows, you automatically get something called “Active Setup,” a Microsoft-signed ActiveX control. This control is designed to automatically install and update software, including IE. It does so by reading installation instructions and installable parts from a signed CAB (archive) file. A user-configurable setting in MSIE determines if a user confirmation dialog occurs for each remotely initiated Active Setup install. In other words, if you choose, you are always warned before Active Setup does something.

This is somewhat scary, but straightforward. However, Juan Carlos Garcia Cuartango discovered something strange. If the CAB is signed by Microsoft itself, rather than a third-party Microsoft-certified signer, then the user-confirmation setting is ignored. Such CABs elicit no confirmation dialog—the software is ALWAYS installed. That is, Microsoft-signed Active Setup installs can’t be declined or confirmed, and they can occur silently and secretly.

This is very scary, but it gets worse. Any signer can instruct Active Setup to install parts from valid Microsoft-signed CABs, and it will happily comply, regardless of where those instructions come from. Anyone can instruct Active Setup to mix parts (data, executable, even DLLs) from any CAB previously signed by Microsoft. Active Setup will comply, acting quietly and without confirmation, just as if the instructions came from Microsoft. It only seems to matter that the parts and the install-instructions are signed, not that they are from different origins or are signed by different signers. It’s as if you made a new message by piecing together words and phrases from a series of signed messages, and the result appeared to be signed because all its original parts were signed. Given the research on Java applets that demonstrate how individually secure applets can interact to yield insecure results, this is a problem.

Fixes: It’s not enough for the installed parts to be signed. It’s not even enough for the instructions driving the install to be signed. It’s the combination that counts, so it’s the combination that must be signed. But even that isn’t enough. The Active Setup Control should only install things that it has signed permission for FROM THE ORIGIN. For example, if some signer wants to install a Microsoft component from another CAB, then that signer must have a signed statement from Microsoft that the component can be independently installed by that specific signer for that specific purpose. In short, to install any component from another CAB requires the explicit permission of that CAB’s signer.

Juan Carlos Garcia Cuartango’s Web page:
<http://www.angelfire.com/ab/juan123/iengine.html>

News articles about Cuartango’s discovery:
<http://www.wired.com/news/print/0,1294,34474,00.html>
<http://www.zdnet.com/pcweek/stories/news/…>
<http://www.computerworld.com/home/print.nsf/all/…>

A November 1999 fix to Microsoft’s Active Setup Control:
<http://www.microsoft.com/technet/security/bulletin/…>
<http://www.microsoft.com/technet/security/bulletin/…>

A little on Active Setup, some of it outdated:
<http://msdn.microsoft.com/library/periodic/period98/…>
<http://msdn.microsoft.com/workshop/components/…>
<http://msdn.microsoft.com/library/techart/…>
My favorite quote is from the third URL: “If security is set to none, everything just works.” That’s good to know.

How to Create a Silent, Minimal Install of Microsoft IE5:
<http://www.helpfulsolutions.com/Silent_IE5_Install.htm>

This article was written with Gregory Guerin.

Counterpane Internet Security News

Bruce Schneier is speaking at TISC (The Internet Security Conference) in San Jose, CA on 27 April 2000:
http://tisc.corecom.com/

Bruce Schneier is “speaking” at the on-line ForBusiness 2000 conference:
http://www.forbusiness2000.com/

Bruce Schneier is speaking at Network World + Interop in Las Vegas on 9 May 2000:
http://www.zdevents.com/interop/

Counterpane is hiring; see our job listings at:
http://www.counterpane.com/jobs.html

The Uniform Computer Information Transactions Act (UCITA)

Virginia Gov. James S. Gilmore III signed the UCITA, and it is now law in Virginia. The Maryland legislature overwhelmingly passed the bill, and it is on its way to become law in that state.

I put this horrible piece of legislation in the Doghouse last month, but it’s worth revisiting one portion of the act that particularly affects computer security.

As part of the UCITA, software manufacturers have the right to remotely disable software if the users do not abide by the license agreement. (If they don’t pay for the software, for example.) As a computer-security professional, I think this is insane.

What it means is that manufacturers can put a back door into their products. By sending some kind of code over the Internet, they can remotely turn off their products (or, presumably, certain features of their products). The naive conceit here is that only the manufacturer will ever know this disable code, and that hackers will never figure the codes out and post them on the Internet.

This is, of course, ridiculous. Such tools will be written and will be disseminated.

Once these tools are, it will be easy for malicious hackers to disable peoples’ computers, just for fun. This kind of hacking will make Back Orifice look mild.

Cryptography can protect against this kind of attack—the codes could be digitally signed by the manufacturer, and the software wouldn’t contain the signature key—but in order for this to work the entire system has to be implemented perfectly. Given the industry’s track record at implementing cryptography, I don’t have high hopes. Putting a back door in software products is just asking for trouble, no matter what kinds of controls you try to put into place.

The UCITA is a bad law, and this is just the most egregious provision. It’s wandering around the legislatures of most states. I urge everyone to urge everyone involved not to pass it.

Virginia:
<http://www.washingtonpost.com/wp-dyn/articles/…>

Maryland:
<http://www.idg.net/idgns/2000/03/29/…>

Comments from Readers

From: “John J. Adelsberger III” <jja wallace.lusars.net>
Subject: Security and complexity

> Real systems show no signs of becoming less complex.
> complex. In fact, they are becoming more complex
> faster and faster. Microsoft Windows is a poster
> child for this trend to complexity.

It is common to pick on Microsoft, but it would be fairer to pick on the entire commercial world. Security, to a company that is trying to make money, is a PR issue, and only becomes a technical issue if and when bad PR is the alternative. The reason is obvious; security costs lots of money to do right, and to most customers, the appearance is as good as the genuine article, not because they really don’t care, but because they have no way of knowing the difference. I cannot blame the companies for doing what they are meant to do; the fact that so many people refuse to admit the facts to themselves is more troubling.

> The other choice is to slow down, to simplify,
> and to try to add security.

OpenBSD does this. I am unaware of any other group whose workings are publicly viewable that does so, which is regrettable, because I would prefer not to have this appear as an OpenBSD plug; rather, my purpose is to point out that not only is this approach feasible, but it is being done.

Note also that the attitude is much more mainstream than the skills or the stamina to act on it in practice. There are security groups associated with every product of any significance, but most of them, well intentioned and eager as they may be, talk a lot and don’t do much. This is too bad, because if more of them did, it wouldn’t be too long before consumers began to understand the value this can provide, albeit without any real understanding of the means by which it is accomplished.

By the way, consumer understanding is not one big thing. Understanding a product is different from understanding what it does, how, and how well. Consumers do not have to be experts on security or reliability; what is needed is reasonably objective third party information on these subjects, such as people like yourself can provide. Notice that cars known for safety, reliability, and fuel economy are the best sellers, despite the fact that most customers don’t pay too much attention to the actual mileage they get and have no real way to evaluate for themselves the safety or reliability of such a complex product. Of course, the dissemination infrastructure takes time to develop and more time to rid itself of bozo wannabes, but this is the direction in which to head.

From: “Andrew D. Fernandes” <andrew cryptonym.com>
Subject: Simple vs Complex

My mathematical background is in the area of “dynamical systems”, more popularly known as “chaos theory”. One of the tenets of research in dynamical systems is that “simple systems can have very complex dynamics”. How does that tenet affect the conclusions of your essay?

Simply put, you are confusing a ‘simple’ system (a system that is easy to describe), with the ‘simple’ dynamical behaviour of the system. In other words, the system may be easy to describe, but the behaviour may be very difficult to describe. The converse is also true: a system with a very complex description may have very simple dynamical behaviour.

For instance, the usual example is the iterative map x[n+1] = -alpha*x[n]*(x[n]-1), for 0 <= x <= 1, 0 <= alpha <= 4. This is a “simple” system, in that it is easy to describe. But the dynamics of the system are very complex. Hundreds of research papers have been written to describe and understand the sequence of x[0], x[1], x[2], … and more come every day. In fact, the behaviour of this quadratic map is complicated enough to be the cornerstone of modern “chaos theory”!

In the context of security, our “system” is a Java applet, an ActiveX control, a Word macro, an SSL setup, or an IPSec session. Then our “dynamical behaviour” is a measure of the security of the system. We can simplify the security properties of the system as much as we like, but the overall dynamics of the security can be, and probably will be, very complex.

So, although I agree that only simple systems can be secure, I disagree that you can build systems with simple behaviour by using systems that are easy to describe. You’re fooling yourself: the tiniest change to a simple system can make its dynamics hideously complicated. In the quadratic map, very small changes to alpha make enormous changes on how the system behaves.

In reality, you can build secure complex systems by ensuring that the dynamics of the security properties of the system remain simple. That goal is related, but definitely not identical, to the goal of building a system with a simple description. To build complex systems with simple behaviour, you need to modularize not just the system, but the system’s behaviour… but discussing how to do that, in either an abstract mathematical or pragmatic programming point of view, is beyond the scope of this note.

From: Clifford Neuman <bcn isi.edu>
Subject: Microsoft Kerberos

There have been many articles and much commentary faulting Microsoft for extending the Kerberos standard in ways that are purportedly incompatible with existing implementations. Such commentary also attributes to Microsoft the motives of forcing the use of their Kerberos implementations by anyone wanting to inter-operate with Win2K. Though Microsoft has been dragging its feet publishing the details of the contents of the authorization data and how they are using it, in my opinion, their extensions are consistent with the Kerberos Internet draft, and their use of the authorization data field is consistent with its original intent.

There is not currently a standard for representing group information in the authorization data field of Kerberos tickets, so I can’t fault Microsoft for developing their own. As part of the design and release of the authorization components of Win2K, they registered identifiers for their authorization data elements, and discussed the high level architectural issues of their use with myself and others in the Kerberos community. This is highlighted by the fact that their early design called for an interpretation of the authorization data field that was inconsistent with its defined use and intent. After discussion (and before they implemented), we worked out an extension that 1) preserved the original intent, 2) significantly improved the usability of the authorization data field for authorization by anybody, not just Microsoft, and 3) is specified in the current Internet draft revising the Kerberos specification.

Regarding the security of Microsoft’s Kerberos implementation, I am not aware of any protocol changes that have been made that affect the security of Kerberos. I do have some concerns about the storage of KDC keying material in active directory, but that is an implementation and not a protocol issue, and Microsoft claims to have taken steps in the design to prevent access to the keys by other than the KDC. I have not looked in detail at these steps, however.

Regarding some of the naming issues, I think that there were some interoperability issues caused by differences in naming, but I also believe that Microsoft issued fixes to address this incompatibility. Similar problems arose with interoperability between DCE and raw Kerberos, and it doesn’t surprise me that reaching full interoperability in light of the inherent naming differences in other parts of the system might take several revisions to work out.

Regarding name canonicalization, the changes Microsoft is making address some security relevant limitations that Kerberos has had regarding the mapping of server names to principal names (this is something that Kerberos was never originally intended to address). The Microsoft proposals in this area have been submitted in the context of the IETF, and I am confident that the changes will be reflected in standards track documents.

More generally on the interoperability front, Microsoft has worked closely with CyberSafe to demonstrate interoperability for user authentication by CyberSafe’s customers using existing CyberSafe KDCs on non Win2K platforms.

I have found the individuals at Microsoft who have been working on Kerberos have contributed positively to the standards process in the IETF. These individuals want true interoperability, and have acted in good faith. The use of the authorization data field IS consistent with both the letter and intent Kerberos specifications, and I am happy to see some of the authorization ideas for which the authorization data field was intended to be gaining widespread use. However, I do fault Microsoft for not yet publishing the details of their use of the authorization data field as they have repeatedly promised, and I hope that the community and the press will continue to pressure them to publish the specification as an informational RFC.

From: Martin Rex <martin.rex sap-ag.de>
Subject: Microsoft Kerberos

I do not agree with most of the complaints about Microsoft’s Kerberos implementation in Windows 2000. I have been looking at and testing with Microsoft’s W2K Kerberos quite a bit and here are my findings:

– I haven’t noticed interoperability problems with MIT Kerberos 5 v1.0.5. One may not be able to access W2K file shares or services with tickets from a non-Microsoft KDC, but that’s not a problem of the authentication, but of the ACLs which the Microsoft services use to grant access to these resources. Applications that rely on name-based authentication will work on W2K as one would expect, and W2K-based clients can access applications on Unix that grant access via name-based authentication.

– MS W2K Kerberos IS compliant to rfc1964 (the Kerberos5 gssapi mechanism). With a suitable SSPI-wrapper (which I’ve written and which my company is going to give away for free), a portable GSS-API aware application will not notice any differences between a Microsoft W2K Kerberos and an MIT Kerberos 5. There may be a tiny cosmetic issue regarding “service names”. However these are messy and non-standard across all existing Kerberi.

– the normal “name-based” authentication will work just fine with W2K clients when talking to applications on Unix, provided that one is using the GSS-API. I wrote the W2K Kerberos SSP wrapper for exactly this purpose.

– the (admittedly still undocumented) extension with the authorization data is necessary to permit the enforcement of POSIX ACLs by the TCB, which is how applications on Microsoft Windows NT platforms should do authorization according to Microsoft (keyword: Impersonation). Microsoft is not the first to implement POSIX ACLs, DCE did that a while ago. Although they used an additional ticket (a PTGT), the effect is the same. Both, DCE and W2K Kerberos still support the traditional name-based authentication. Personally, I dislike Impersonation, because that means that a low-privileged Server will get a boost in permissions simply when an (domain-)admin connects. Combine that with automatic delegation (which may have happened with W2K), then connecting to other machines on the network becomes a serious security problem.

– the one serious problem with name-based authentication in W2K Kerberos is, that the administrative Tools, when a user with a certain logon name leaves, do not prevent the administrator to immediately reissue this logon name for a new user. This may cause problems with the ACLs of applications that perform name-based authentication. On Microsoft Windows NT platforms, ACLs contain UUIDs and/or SIDs, not names. There seems to be the tradition with POSIX ACLs that you orphan ACL entries on a regular basis and don’t care about it.

From: Joe_Otway ampbanking.com.a
Subject: Security by obscurity

I know you are a big fan of the security by obscurity approach so I thought you would be interested in this reference to Cisco’s PIX that I came across in http://208.201.97.5/ref/hottopics/security/….

The article by Brian Robinson is about Firewalls and goes on to say…

“Unlike Windows NT or Unix-based firewalls, the PIX was built from scratch, and the source code is closely guarded,” said Eric Woznysmith, a consultant systems engineer in security network management with Cisco’s federal operations. “Only a dozen or so people around the world have seen it. There have been no known break-ins through PIX firewalls.”

The PIX firewall is used throughout the government, particularly in intelligence and law enforcement agencies, Woznysmith said, and is “heavily used” within DOD. Given its success, he said, Cisco expects more vendors to offer their own proprietary boxes.

From: selune hushmail.com
Subject: Publishing exploits

In Crypto-Gram, Brian Bartholomew <bb@wv.com> wrote:
>I prefer the following approach: announce existence of
>vulnerability and promise a kiddy script in a month;
>wait a month for vendor to react; publish kiddy script.

I agree with the first part of the mail, a month seems a good delay before publishing a kiddy script, it lets enough time for the vendor to react. Where I can’t agree is here :

>Publishing is *very important* in these cases so the
>stakeholders know to reduce their trust in these systems.
>If air traffic control is vulnerable, tell me so I can
>stop taking airplanes!

First, there are the people who don’t have the information, for different reasons (no computer, hollidays, …) or who are obliged to use the airplanes (inter-continental business travel). So you will avoid airplanes, but some won’t (and not because of non disclosure) and are still at risk.

If air traffic is vulnerable, it’s not about stopping all airplanes that use this system, because this is impossible. It’s about letting time to system administrators/vendors to produce a fix. Here, you’re playing with people life, because of what YOU do. The example you told about doesn’t have anything in common with this one except for a technological failure. But for your example, as you wrote, it’s a non-life-safety version.

If I buy a car, and there is a critical problem with the braking system, I would like to know it, because it’s a life-safety problem, whether other people know it or not. But with the air traffic system, by publishing this vulnerability, you take the risk on other people life.

Yes, I’m for publishing vulnerabilities, but only if two conditions are here :

– It’s not life-critical
– I’ve first warned the vendor of it, and let time for him to fix it (let’s say, 2 weeks before alerting more people) and, if the vendor doesn’t care, even after publishing it, it could be ok to publish a kiddy script (let’s say after another month)

Moreover, you wrote this :

>This is gun control: “Don’t punish murder, ban the gun
>instead! Exploits are an evil instrumentality ! Exploits
>help a good boy go bad!” The right answer is: Humans are
>held responsible for their behavior. Guns, bricks, and >exploits are just tools.

Here again, I strongly disagree. The H-bomb may be just a tool, but it’s not freely distributed. Why? Because some people are just too crazy to let them play with it. We don’t want to take the risk of these people having it, so we try as hard as we can to ban this weapon, and so it is a criminal offense to own one H bomb. As in the computer security field, it’s about balancing risks vs benefices.

CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.

To subscribe, visit <http://www.schneier.com/crypto-gram.html> or send a blank message to <crypto-gram-subscribe@chaparraltree.com>. To unsubscribe, visit <http://www.schneier.com/crypto-gram-faq.html>. Back issues are available on <http://www.counterpane.com>.

Please feel free to forward CRYPTO-GRAM to colleagues and friends who will find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.

CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO of Counterpane Internet Security Inc., the author of “Applied Cryptography,” and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a frequent writer and lecturer on computer security and cryptography.

Counterpane Internet Security, Inc. is a Managed Security Monitoring company dedicated to providing 24×7 expert-assisted network security.

<http://www.counterpane.com>

Copyright (c) 2000 by Counterpane Internet Security, Inc.

Sidebar photo of Bruce Schneier by Joe MacInnis.