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.

Comments

Innovation, Standards and Protocols

[jd]

There is an important aspect to innovation. And that is that Social Protocol (not yet an RFC) should be followed. Social Protocol dictates that the following communication takes place:

• The Innovater should tell the truth, the whole truth, and nothing but the truth about their proposed innovation.
• Standards-compliant software -should- be. Otherwise, it isn't.
• Proprietary extensions designed to destroy an existing market deserve to be placed on Devil's Island.
• "Extensions" which genuinely extend should be released under the same licence/terms as the original protocol, resulting in adoption of the useful and the discard of the useless.
• NASA's manned Mars mission should incorporate Microsoft's entire legal team. This will save on the need for fuel for the return journey.

Re:This might be interesting

[CountZer0]

I'll answer your second question first:

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 /. 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.

Re:This might be interesting

[IntlHarvester]

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.
--

Re:This is the way to do it

[Katravax]

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.