Slashdot Mirror
Kerberos Loophole May Be Closed/Apple Getting Kerberos
Paul Boutin writes "The Industry Standard talked to Kerberos' principal author and all-around ubergeek Clifford Neuman about his proposed rewrite of the IETF Kerberos standard (RFC 1510) to close the loophole Microsoft has been using to create a non-interoperable version. " It also looks like Apple will be bringing Kerberos to OSX, in partnership with MIT.
This would actually be a very bad idea. Regardless of whether or not Microsoft's claims of trade secret protection actually hold any water, their lawyers will happily continue to act as though they do. The result of this is that, if the Samba team went and implemented the PAC field using Microsoft's spec, they would be immediately sued for trade secret violation. The result: no updates to Samba for the next couple of years as all of their resources are sucked dry by MSFT's legal team.
In fact, even if they implemented the field through good old reverse engineering now, they'd still be in danger. Since the spec has been so widely distributed, if MSFT pressed a suit, the burden of proof would be on the Samba team's lawyers to either prove that the trade secret status was no longer applicable, or else prove that none of their programmers has been "tainted" by the spec.
It's been suggested before that MSFT actually released the spec in this way specifically to ensure that the Samba team would be unable to implement full interoperability. I certainly wouldn't put it past them.
Quantum mechanics: the dreams that stuff is made of.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The program refused to build the helpfile. It complained that the RTF was invalid.
Thinking that this was odd, I went to Microsoft Word 97, wrote the file there, saved it as RTF, and tried this brand new file in the same Microsoft-produced helpfile creator.
AGAIN the program complained that the RTF was invalid.
So I moved to my Linux box, fired up Applix 4.3.7, typed in the file, saved it as RTF, moved it to the Windows box, and tried again -- this time with an RTF file produced in a NON-Microsoft product.
The helpfile built without a single complaint!
DFL
Never send a human to do a machine's job.
I'll answer your second question first:
/. because all MS is claiming is copyright infringement. I do not know if these claims are true or false, but I do know that IF a MS document describing their usage of the "open" data field in Kerberos is copyrighted, it does not matter if the IETF changes the format of that field. The document would STILL be copyrighted.
The IETF is in control of the Kerberos specification completely. The old specification just happened to have a "blank check" in it. Basically, there is a data field in the (current) Kerberos specification that is defined simply as "insert data here" with no specific controls over the format of the data used, nor its purpose. This "open" data field has been unused in current Kerberos implimentations, because no vendors saw a need for it. Therefore there is no defacto standard for what data can be put in this field. Microsoft decided it would use that field for Windows NT 5 authentication information, so that they could "imbed" Windows authentication into Kerberos (one could argue that they are only using Kerberos as a "wrapper" for their normal NT authentication, and as such, they don't really use Kerberos anyway...) What the IETF is now proposing, is an "official" definition of what can go into this "open" data field. Of course, the new specification will define the data field in such a way that Microsoft's current "implimentation" of Kerberos will no longer conform to the specification. The IETF can only do this because it is completely in control of the Kerberos specification already.
As for the first question, it has no effect at all against the recent legal action MS pulled against
A long time ago, Apple had an alliance with Netscape (then still a stellarly successful browser company). Then MS invested $100m in Apple, and consequently Apple dropped Netscape and standardised on MSIE.
Now that Apple are adopting Kerberos, what's to say that it will not be proprietary Microsoft Kerberos? If MS could get Apple to support their fork of Kerberos, it'd make it more likely to win the standards battle. (And official standards mean little in the fast-moving IT game; witness what happened to HTML 3.0.)
When a specification is updated, a new RFC is posted. If a new RFC was written for Kerberos v6 (or whatever Clifford Neuman wants to call it), Microsoft could still (rightfully) claim full compliance with the original Kerberos specification (RFC 1510).
My personal take on this is that it's sour grapes. It appears to me that the other commercial Kerberos implementations are not fully compatible with MIT v5 either, and probably for the same or similar reasons, and where's the righteous indignation about those?
CyberSafe's TrustBroker (Acrobat Reader needed) indicates in it's FAQ that it's compatible "at the protocol layer", and strongly implies that there are interoperability problems or limitations.
DCE Kerberos is not interoperable with MIT's implementation. I don't see anyone screaming about that.
I'd like to see a reasonable discourse on this issue, without all the "Evil Micro$oft" rhetoric. Should standards all be written in such a way that no one is free to innovate?
Here's a side note. Regardless of what OS you use, don't you advocate the spread of Kerberos as an authentication protocol standard? If so, you should probably be grateful. I'll bet more computers have been running Kerberos since February than have ever run it before.
People aren't even seeing the more serious issue here. If Microsoft implements these so-called Kerberos extensions, reverse engineering them is not what we want to be doing (regardless of legality).
Getting the IETF to make the standard more rigid is a better course of action. It forces Microsoft to adhere to certain rules if they want to claim Kerberos interoperability.
If we start the reverse engineering game with Microsoft, they will have achieved their goal -- defacto control of the Kerberos standard. They will have the ability to modify their extensions at will, thus forcing anyone who requires interoperability (e.g. Samba) to scramble to catch up.
Once Microsoft has you playing catch-up, you're right where they want you. See Netscape for details.
Best regards,
SEAL
is this going to influence the recent legal actions Microsoft pulled against /.
How 'bout this -- Who Cares!
Face it -- this whole slashdot copyright-infringement thing is just a sideshow engineered by Microsoft to distract you guys away from the big issues -- whether or not you will ever get a Unix server that interoperates with your Win2000 MS-RPC clients.
Instead of rebelling against Microsoft by violating their copyrights, someone out there should rebel by using Microsoft's published information to extend Samba and MIT Kerberos to support MS's extensions. Then you can fight the real legal battle over whether or not MS can release a public 'trade secret' and whether they can use a click-wrap license to restrict what you do with information. If you win those fights, Slashdot can remove MS documents all day long, and it won't matter one bit.
Maybe Slashdot will win, and can keep the information on their server. Not much consolation when your Samba/Linux box gets replaced by one running Windows 2000. Just make sure that you are fighting the correct fight and you are keeping your eye on the most important issues at hand.
--
Business. Numbers. Money. People. Computer World.
I spoke recently to a co-worker who has known several key MS sales managers over the years, and he says he remembers when this flap came up over not adding NFS support into NT as early as NT 3.1 (which was the 1.0 release of NT). Lots of Unix shops were asking for NFS support so they could continue to access thier currently shared data on NFS while using NT as a client machine. It also seemed logical to my co-worker, and he asked the MS folks he knew why wouldn't they do it? Of course they were capable of it; they have some excellent programmers.
The response was that it wasn't about the feature, it was about forcing the customer to make a choice: Unix or NT? There were even early-on third-party products to provide NFS support for an NT user, but a properly-placed MS sales rep could ask the right person "Come on... this third party product cost $280 per client and the entire client OS only costs $80. Is it really worth it just to use NFS? Wouldn't it make more financial sense just to use file shares via NT?" and thus the beginning of the end for Unix in that shop, whereas if the NFS support had been provided, NT and Unix would have been side-by-side and maybe NT would "lose" at some point in the future.
So is it about standards for MS? Absolutely not. POP3 clients (including mine) all over the world broke with the initial implementation of POP3 by Exchange (one too many carriage returns) when accessing an Exchange server. I mean good grief, it was POP--not exactly hard to get right. It's about sales, and forcing the customer to make a choice. And we all know that when you compare the "back of the box" of an MS product to one of its competitor's products, especially when the person comparing is a PHB, the MS product will win.
Could MS make its Kerberos work with Unix implementations? Absolutely. But the question they're really forcing PHB customers (the ones with the checkbooks) to answer is "Do we like our Unix boxes better overall enough to stand by them over this one little thing" as it will seem to them to be a minor incompatibility. And the client OSwill interoperate correctly, of course... and they've taken away another piece of attractiveness that Unix might hold to a PHB.
---
:>
It also looks like Mac will be bringing Kerberos to OSX, in partnership with MIT.
---
Mac? Who is Mac?
By chance do you mean Apple?
No offense, but you PC guys always get that wrong. It's as bad as saying that a given OS was written by "Linux Torvalds".
- Jeff A. Campbell
- VelociNews (http://www.velocinews.com)
- Jeff