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