[iwar] [fc:Why.Microsoft's.Open.HailStorm.promises.flatter.to.deceive]

From: Fred Cohen (fc@all.net)
Date: 2001-09-20 20:56:22


Return-Path: <sentto-279987-2147-1001044576-fc=all.net@returns.onelist.com>
Delivered-To: fc@all.net
Received: from 204.181.12.215 by localhost with POP3 (fetchmail-5.1.0) for fc@localhost (single-drop); Thu, 20 Sep 2001 20:57:10 -0700 (PDT)
Received: (qmail 11337 invoked by uid 510); 21 Sep 2001 03:56:45 -0000
Received: from n9.groups.yahoo.com (216.115.96.59) by 204.181.12.215 with SMTP; 21 Sep 2001 03:56:45 -0000
X-eGroups-Return: sentto-279987-2147-1001044576-fc=all.net@returns.onelist.com
Received: from [10.1.1.223] by fl.egroups.com with NNFMP; 21 Sep 2001 03:56:24 -0000
X-Sender: fc@big.all.net
X-Apparently-To: iwar@onelist.com
Received: (EGP: mail-7_3_2_2); 21 Sep 2001 03:56:15 -0000
Received: (qmail 74107 invoked from network); 21 Sep 2001 03:56:15 -0000
Received: from unknown (10.1.10.27) by 10.1.1.223 with QMQP; 21 Sep 2001 03:56:15 -0000
Received: from unknown (HELO big.all.net) (65.0.156.78) by mta2 with SMTP; 21 Sep 2001 03:56:23 -0000
Received: (from fc@localhost) by big.all.net (8.9.3/8.7.3) id UAA06924 for iwar@onelist.com; Thu, 20 Sep 2001 20:56:22 -0700
Message-Id: <200109210356.UAA06924@big.all.net>
To: iwar@onelist.com (Information Warfare Mailing List)
Organization: I'm not allowed to say
X-Mailer: don't even ask
X-Mailer: ELM [version 2.5 PL1]
From: Fred Cohen <fc@all.net>
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Delivered-To: mailing list iwar@yahoogroups.com
Precedence: bulk
List-Unsubscribe: <mailto:iwar-unsubscribe@yahoogroups.com>
Date: Thu, 20 Sep 2001 20:56:22 -0700 (PDT)
Reply-To: iwar@yahoogroups.com
Subject: [iwar] [fc:Why.Microsoft's.Open.HailStorm.promises.flatter.to.deceive]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit

Why Microsoft's Open HailStorm promises flatter to deceive

By Andrew Orlowski in San Francisco

Posted: 21/09/2001 at 00:20 GMT

Today's Hailstorm announcement was cultivated to gain maximum favourable
publicity for Microsoft, but Redmond's concessions amount to nothing it
hasn't already conceded, in one from or another. 

In fact, seasoned watchers including Jeremy Allison - co-lead of the
SAMBA project - interpret the "concessions" as extending the requirement
for Microsoft's partners to include proprietary technology in their .NET
compliant web services. 

So what was new, today?

Microsoft promised to include the 'industry standard' Kerberos 5
protocol in Hailstorm, and HailStorm is now officially monikered ".Net
My Services", if you .please.  Microsoft also said it would open
authentication to third party brokers. 

A pre-briefed David Coursey at ZDNet was beside himself with joy.  It
was a "stunning" announcement, he opined.  The news that "Passport and
other 'federated' services would accept Kerberos 'tickets' supplied by
the others," he said, was "good news for Microsoft, the industry, and
consumers". 

Alas, there's a world of difference between authentication and
authorization, and that's at the nub of understanding today's
announcement. 

An authentication server takes a user name and password, and raises a
simple yes/no flag whether the combination fits or not.  Authorization
actually gives the user rights to the services on offer.  Authorization
allows you to use printer Y, or access files from X, or not, and if
you're beginning to think that web services without authorization rights
are essentially meaningless, then collect $50 and pass go, because
you're right on the button. 

Not only has this distinction - between authentication and authorization
- plagued the tech community for years, but it's one that's already been
exploited by The Beast, which has leapt into the open wound with its own
proprietary implementation of Kerberos, which is the years-old open
standard for authentication. 

Here's how. 

The Kerberos protocol specifies authentication clearly and simply: you
go to a Kerberos server, and get a ticket.  The ticket is then presented
to an authorization server, which returns it with various access rights
allowed.  But the Kerberos protocol doesn't cover authorization itself. 
This isn't an open standard, and in fact no one can agree on a single
way to do it, although everyone agrees not to bugger up the Kerberos
ticket with machine-specific details.  And so authorization evolved as a
DCE (Distributed Computing Environment) standard.  When we say that no
one has buggered up the ticket, there is, as you might guess, one
exception... 

"There's no common represenation of a 'user' across all systems, sure,
but the idea was that you don't pollute the Kerberos ticket with that
local system's idea of what a user is," explains Allison. 

"Microsoft's implementation of Kerberos actually wraps the authorization
in the ticket," he says. 

"They subverted it and put inside a standard ticket.  The result was
that only tickets issued on Windows 2000 machines could be useful on
other Windows 2000 machines, without a lot of a manual mapping, which is
a massive pain and is so tedious that no one is ever going to do it."

Readers with long memories will remember the furore when Microsoft
documented its Kerberos implementation, and then sent its legal
mujahaddin round to our friends at Slashdot who hosted postings
containing the details of this 'open' implementation. 

In short, it's hard to do authorization between a Windows server and a
non-Windows server, and that seems to be the way Redmond likes it. 
Nothing in today's announcements changes this in any way, in fact it
confirms the Redmond-centric way of doing business on .NET. 

Allison summarizes the politics like this:-

"They're very clever.  They know the smallest amount of control they
need to leverage monopoly.  If you have a server that does
authentication and authorization, then you have the equivalent of a
Windows Primary Domain Controller, and that's their terror," he says. 

"Once someone usurps the PDC they can provide the equivalent of an
Active Directory service on Linux," he says, at a fraction of the cost. 

"They've won the client but no one likes using their servers.  Because
they're shit."

And so it returns to the commodity protocols argument, as revealed in
the Halloween memos and repeated ad infinitum.  Mind you, given the
positive spin that the wires have already put on this move, it's halfway
to success. 

We put a call into Sun, and got this response:-

"Sun believes that many companies should be authenticators, therefore
providing open competition for businesses and consumers."

"In the coming weeks, Sun, along with partners such as banks and
insurance companies, will offer their own authentication services.  It
is not, however, our policy to disclose these discussions until there
are appropriate and mutually agreed upon details to announce.  We have
no formal statement at this time."

Hmm.  That suggests they're still fixed on the authentication
distraction, not the authorization end-run.  Hopefully some one can lend
them a clue. 

Microsoft had not returned our calls at press time. 

From the we-told-you-so-Dept:-

"Microsoft's holier-than-thou standards pitch for .Net could be
undermined by its insistence on using its own, non-standard version of
Kerberos" - The Register, 27 March 2001. 

That's not us, by the way - think of us as straw-sucking hayseeds who
don't have a clue, and definitely don't get pre-briefed by the corporate
PR machinery - but instead cock a hat to the prescient Mat Hanrahan at
analysts Bloor Research.  We were just dumb enough to be standing around
at the time.  Honest.  ®

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!
http://us.click.yahoo.com/JNm9_D/33_CAA/yigFAA/kgFolB/TM
---------------------------------------------------------------------~->

------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



This archive was generated by hypermail 2.1.2 : 2001-09-29 21:08:46 PDT