From: William Knowles (wkC4I.ORG)
Date: Tue May 02 2000 - 16:08:37 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[From: Bruce Schneier <schneiercounterpane.com>]

                  CRYPTO-GRAM

                April 15, 2000

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneiercounterpane.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" <jjawallace.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" <andrewcryptonym.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 <bcnisi.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.rexsap-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_Otwayampbanking.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: selunehushmail.com
Subject: Publishing exploits

In Crypto-Gram, Brian Bartholomew <bbwv.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-subscribechaparraltree.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.

ISN is sponsored by SecurityFocus.com
---
To unsubscribe email LISTSERVSecurityFocus.com with a message body of
"SIGNOFF ISN".

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]