Power Hacker 2003/Power_Hacker_2003.iso/E-zine/Magazines/crypto-gram/crypto-gram-0004.txt

Text File | 2002-05-27 | 37.6 KB | 809 lines

                  CRYPTO-GRAM

                April 15, 2000

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            [e-mail]
           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" <[e-mail]>
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" <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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: [e-mail].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: [e-mail]
Subject: Publishing exploits

In Crypto-Gram, Brian Bartholomew <[e-mail]> 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 <[e-mail]>.  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.