CRYPTO-GRAM, April 15, 2000

[Bruce Schneier <schneier@counterpane.com>]

[: hacktivism :]

                  CRYPTO-GRAM

                April 15, 2000

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneier@counterpane.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.counterpane.com.  To subscribe or 
unsubscribe, see below.


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


** *** ***** ******* *********** *************

In this issue:
      AES News
      The French Banking Card Hack
      Counterpane -- Featured Research
      News
      Counterpane Internet Security News
      The Doghouse: Cyber Security Information Act
      Microsoft Active Setup "Backdoor"
      The Uniform Computer Information Transactions Act (UCITA)
      Comments from Readers


** *** ***** ******* *********** *************

         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.counterpane.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/0315/fin18.htm>

There's a Reuters story:
<http://abcnews.go.com:80/sections/tech/DailyNews/smartcard000315.html>

And two earlier stories about Humpich:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2428429,00.html>
<http://www.zdnet.com/zdnn/stories/bursts/0,7407,2452848,00.html>

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


** *** ***** ******* *********** *************

        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.counterpane.com/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/000331D072>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2487024,00.html>
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/final-injunction.html>
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/0,1151,13533,00.html>

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/anti-shoplifting-device.htm>

 >>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?REQUNIQ=953519311&6004REQEVENT=&REQINT1= 
36413&REQSTR1=newsnow>

A more balanced article on open-source security vs. closed-source:
<http://www.zdnet.com/pcweek/stories/news/0,4153,2473335,00.html>

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/index.html>

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>

Someone's built a 7-qubit quantum computer.  Any RSA moduli less than three 
bits should watch out.
<http://www.wired.com/news/technology/0,1282,35121,00.html>

An HTML virus that plagues WebTV:
<http://www.zdnet.com/enterprise/stories/security/news/0,7922,2470827,00.html>
<http://www.wired.com/news/technology/0,1282,35045,00.html>

MI5 laptop stolen (with government secrets):
<http://www.zdnet.co.uk/news/2000/11/ns-14318.html>
And a few days later...MI6 laptop stolen (also with government secrets):
<http://news2.thls.bbc.co.uk/hi/english/uk/newsid_693000/693011.stm>
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/000331D076>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2487101,00.html>

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/fea13.htm>

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/0,4586,2486464,00.html>

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/0,4586,2462008,00.html?chkpt=zdnntop>

The demand for round-the-clock security services:
<http://www.zdnet.com/pcweek/stories/news/0,4153,2471184,00.html>

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/0,4586,2523596,00.htm>

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/encryption_lawsuit_1.html>
Actual opinion:
<http://pacer.ca6.uscourts.gov/cgi-bin/getopn.pl?OPINION=00a0117p.06>

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/3877481.html>

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?id=13>

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

Intel is open-sourcing their CDSA (Common Data Security Architecture) software:
<http://www.zdnet.com/enterprise/stories/main/0,10228,2523586,00.html>


** *** ***** ******* *********** *************


       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/daviva_058.pdf>


** *** ***** ******* *********** *************

       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/0,4153,2448411,00.html>
<http://www.computerworld.com/home/print.nsf/all/000224EF5A>

A November 1999 fix to Microsoft's Active Setup Control:
<http://www.microsoft.com/technet/security/bulletin/ms99-048.asp>
<http://www.microsoft.com/technet/security/bulletin/fq99-048.asp>

A little on Active Setup, some of it outdated:
<http://msdn.microsoft.com/library/periodic/period98/vbpj0798.htm>
<http://msdn.microsoft.com/workshop/components/downcode.asp>
<http://msdn.microsoft.com/library/techart/msdn_signmark.htm>
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/A6866-2000Mar14.html>

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


** *** ***** ******* *********** *************

              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/firewalls.html.

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.counterpane.com/crypto-gram.html> or send a 
blank message to <crypto-gram-subscribe@chaparraltree.com>.  To 
unsubscribe, visit <http://www.counterpane.com/unsubform.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 24x7 expert-assisted network security.

<http://www.counterpane.com>

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


[: hacktivism :]
[: for unsubscribe instructions or list info consult the list FAQ :]
[: http://hacktivism.tao.ca/ :]