Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Microsoft

Kerberos Loophole May Be Closed/Apple Getting Kerberos 116

Posted by Hemos from the should-do-it dept.
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 discussion has been archived. No new comments can be posted.

Kerberos Loophole May Be Closed More

Kerberos Loophole May Be Closed

Comments Filter:
  • Does anyone else see a similarity between this and the RIAA/mp3 war? In each case, you have an entrenched old-school industry trying to use stale tactics (lawsuits, etc.) to shut down the subversive new-school methods. In both cases, even though their might is formidible, it seems obvious to me that their doomed in the long run. They don't "get it" because they're so stuck in their traditional thought prices^H^H^H^H^H^H processes.

    You know what kinda scares me? That Microsoft or the RIAA will "get it." Let me paint you a picture:

    MS Linux: Microsoft produces their own distro.

    No, not their old "embrace and extend" strategy. In this scenario, Darth Bill repents and returns to the good side of the Source. Microsoft mines their proprietary code and programmers skills and begin a truly killer development cycle. They were already leaning towards "rentable apps." Selling the service for their own distro would be pretty similar.

    Think about it. They have the dinero and organizational structure to make serious progress on the areas that many "community" distros are struggling with (GUI for lusers, etc). They're experts at making things look attractive to customers. Red Hat has a few years on them, but once Microsoft got up to speed, they could quickly catch up. They could leverage their vendor relationships and brand name ("Your customers want Linux? We can give you MS Linux!").

    I know it's hard to avoid thinking that this would just be a ploy and MS would pull a bait-and-switch later, but I'm afraid that they wouldn't. If they can remake their corporate image at the same time by "playing nice," the may not be doomed as we might hope.

    I'm not pro-MS. I'm not flamebait-ing. I'm 95% sure that MS is too stuck in their mindset to ever go this route, but I can't help but wonder about the possibility.

    Damon

    Work as if you don't need the money,
    Love as if you've never been hurt, and
    Dance as if no one's watching.

  • Remember the Berlin wall? (Score:3)

    by Glowing Fish ( 155236 ) on Saturday May 20, 2000 @09:09AM (#1059538) Homepage

    Probably most of you are old enough to remember thefall of cuommunism...how the monolithic beast that was the bogey man of the 2nd half of the 20th century fell in a week (or so it seems). Once one country rebelled, everyone saw that there was nothing behind communism and it fell in a week.

    As long as Slashdot continues to stand up to Micro$oft, it will enable everyone to stand up to them. So keep up with it.

  • Re:This might be interesting (Score:4)

    by Captn Pepe ( 139650 ) on Saturday May 20, 2000 @06:25AM (#1059539)
    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.

    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.

  • 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.
  • Fuck Microsoft.

    If you do, please use contraceptives. The last thing we need right now are a bunch of baby bastard Microsofts.

  • Re:Couple of things... (Score:1)

    by Anonymous Coward
    "1. Why does MS mutate this protocol instead of developing something completely propriety and depreciate Kerberos at all?" Kerberos has a pretty strong standing as an "enterprise" user authentication standard. By using a superset of the Kerberos that everyone else is using they can convince people to replace their UNIX Kerberos servers with Windows NT Kerberos servers. The NT servers will do everything that the old servers do (ie run kerberos) plus more (ie do NT authentication with the proprietary MS extension). "2. If Mac is doing an implementation, will they violate that bit where MS said that one may not implement the specifications?" I don't imagine that Apple would try to implement the Microsoft extensions, they would simply implement the standard version just like everyone else. The only reason they would have for implementing MS extensions would be to permit use of an OSX server as the kerberos server for an NT domain. That's a pretty weird argument to make -- go ahead and buy NT workstations, but use MacOS for the servers! That would be going head-to-head with MS for the enterprise server market, which is not something that Apple has historically been real interested in.
  • 'Scuse me, I am not a programmer and so understand very little behind the inner workings of most protocols.

    Question: Why couldn't the maintainer's of the Kerebos spec, along with the OSS community be bastardly, and implement a different authentication protocol within the undefined bit? To me, it seems doing so would break MS's propietary version and place them in a situation where they must either drop their own, propietary extension, or lock access to only Microsoft products.

    am I making sense at all or am I in error?

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

    The fact that it's specifically stated that they're working with MIT to develop this strongly implies that it'll be about as standard as it gets.

  • To me, it seems doing so would break MS's propietary version and place them in a situation where they must either drop their own, propietary extension, or lock access to only Microsoft products.

    Well, that's kind of what's going on. MS has found a way to make Kerberos clients accept their authority, without having to accept the authority of a Kerberos KDC (the master key server). So you have to have a Microsoft KDC that clues their boxes in, in order to use Kerberos in the mixed environment. They're wedging themselves into the controlling seat.

    That way they can come out with a new more-non-standard service that pulls more of the non-MS servers out. As it is, the marketing line will be "hey, you're implementing a Microsoft Active Directory anyway, why not replace those old servers while you're at it".

    To me, the MS lock-in is ok, if you sell it that way. It's lying about compatibility (or misleading about interoperability) that sets me off. MS is pitching to folks who, as you say, don't understand the protocol. They say "see? We support Kerberos. We'll play nice with your secure setup." But only if you let them be King of the Mountain.

  • If there's only one datafield used by MS to do the authentication thing, wouldn't this be quite easy to hack / reverse engeneer?

    Well, no. See, the common use of Kerberos (and the original standard) is for authentication only -- knowing that you're you. MS, in order to let you use their services, is asking the question "Ok, you're you, but what can you do?". They're embedding the answer (your ACL) in the Kerberos header, but that means that you can't use any other Kerberos servers to talk to a MS box, since none of them can generate that info in the first place. A "proper" implementation would issue a ticket from the MS data server with the ACLs embedded, or better yet handle it as a separate datum, rather than forcing you to use an MS Keyserver.

  • Micrsoft and its cronies love to use this 'innovate' word, but I don't think it means what they think it means. Maybe they're using MS Dictionary 1.0, I dunno.

    You mean... THIS one? :)

    http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp ?theisbn=031222222X [fatbrain.com]
  • No, actually it's not. It walks like Kerberos, but it doesn't quack like Kerberos. It permits Kerberos clients to authenticate using a Microsoft KDC, but it does not permit use of Microsoft services if you use another KDC. If it were Kerberos, it would.
  • Isn't the Samba team based in au? I thought Australia gave much better protection to reverse engineering than the US.
  • I've had the same questions about Apple's support for Java, especially since that was the hot issue when the Apple/M$ deal was announced. Since the details of the deal were private, I suspected that Apple might be required to use M$'s Java. (Of course, Apple is not allowed by Sun to use non-Sun-compatible Java. That would put Apple in a real bind.)

    As it turns out, Apple's current Java runtime is a variation on Sun's 1.1.8, and the OS X runtime will be Sun's HotSpot. IE on MacOS doesn't have it's own Java, rather it uses Apple/Sun's. Unfortunately, this makes IE better than Netscape for running applets.
  • That sounds like security to me. Why should Microsoft allow authentication to wobbly resources that could come from anywhere?

    Ignoring the hyperbole that follows that quote -- the cryptography prevents the authentication from coming from "just anywhere". Microsoft apps should roll over and trust the KDC -- that's what it's there for: why you set it up. The bit the MS server wants is your ACL, which is about permission, rather than authentication. The MS server should get it from a trusted source, if it's not going to hold onto it itself, rather than depend on an optional field. By making the field non-optional for MS servers, MS breaks the standard. DCE does too (IIRC), but they admit it. Breaking the standard is not wrong, but claiming you didn't, when you did, is. I'll sputter all day about that (apparently :-).

  • Comment removed based on user account deletion
  • "Some of the specific changes that they did were actually things I suggested on the Kerberos mailing list," he says. "So I don't know what sort of claims they are trying to make on this."

    Doesn't this imply that MS has no right to claim the "enhancements" as their own intellectual property if they were actually publicly displayed before MS made them available in their own version of Kerberos?

  • I don't see why this is MS's problem ... If Sun or another big Unix vendor wanted to sell file servers, they could have given away free Windows NFS clients. Your problem is that Sun, et al has never been interested in the file server market.

    BTW, Microsoft and Novell both charge 'seat licences', so even though the software is built-in you are still paying a couple hundred bucks per $80 client. Windows NFS drivers are in the same ballpark as what MS charges for an NT seat.
    --
  • This looks like a perfect example of "embrace and extend" turned around on Microsoft. Looks like the IETF has decided to embrace the unused data field, and extend it in a "different" direction.

    This is much sweeter than simply trying to get Microsoft for using the Kerberos name when their clients won't work with a server compliant to the published standard.
  • Okay, I admit I'm not a Kerberos expert, but I've looking into this issue some, and it appears to me that everyone is up in arms for all the wrong reasons.

    As I understand it: Microsoft took a field in Kerberos marked for "vendor-specific data" and used it for -- get ready for this -- vendor-specific data. (If that is wrong, please feel free to correct me.)

    So there is nothing wrong with Microsoft's Kerberos implementation. Getting mad at them for that is incorrect.

    However, Microsoft has done some things worth getting mad about: First, the vendor-specific data is in a closed, proprietary format, designed to lock-out non-Microsoft implementations; and second, they've threatened Slashdot for what are (IMO) silly reasons (the exact merits of their case have been debated to death elsewhere [slashdot.org]; let's not repeat all that here).

    We should be after MSFT to open up their protocols and compete fairly, and not after them for using a field in Kerberos for what it is designed for.

  • Some things I don't understand in this Kerberos case:

    1. Why does MS mutate this protocol instead of developing something completely propriety and depreciate Kerberos at all?

    2. If Mac is doing an implementation, will they violate that bit where MS said that one may not implement the specifications?

  • Clifford Neuman an ubergeek, think not. (Score:2)

    by Anonymous Coward
    Of all the ubergeeks, I would not have believed one to do AllAdvantage. Sheesh. See for yourself: http://home1.gte.net/bcn/recommendations/free.htm And the very link to (don't click): http://www.alladvantage.com/go.asp?refid=DJC-598 Would an ubergeek do AllAdvantage and try to take an opportunity to make money and refer herself, even though s/he is most likely to have enough money already....... No! Clifford Neuman, I pity you.
  • http://www.goat^H^H^H^Hmslinux.org [mslinux.org]
  • If there's only one datafield used by MS to do the authentication thing, wouldn't this be quite easy to hack / reverse engeneer?

  • Corel Linux and WPO4L will now ship with Bynari TradeServer which works with M$ Exchange. See below:

    From linuxpr [linuxpr.com]

    ================================================

    Bynari To Bundle Trade Products with Corel

    May 18th, 12:39 UTC

    Use of Debian and Corel Desktop Important to Strategy

    Dateline Dallas May 18, 2000 - Bynari Inc.'s Product Development Group announced that the Company will bundle TradeXCH with Corel 1.1 and Corel's Office2000 for Linux. TradeServer, due for release the week of May 23rd also requires Debian. The Product Development Group plans to bundle TradeServer and its LGPL product, Tradeclient with Corel's latest distribution.

    TradeXCH allows Linux desktop users to communicate with Windows users of Outlook through MS Exchange. The use of Corel 1.1 allows TradeXCH to function in a GNU/Linux distribution which speaks to Windows networks and UNIX NFS computers.

    "We feel this bundle gives enterprises a new choice," Bynari's Product Manager says. "Users have all the functionality of a robust productivity environment, a distribution which promotes corporate convergence and a tool to allows Windows users to communicate with and collaborate with Linux users in a way theu have become accustomed."

    Bynari will support the Corel-TradeXCH bundle with toll free call support in Canada and the United States.

    More extensive information about Bynari initiatives with Corel products will be released in the next week through Bynari's Marketing Director, Lary Freeman, who has led the Company's efforts in forming several strategic alliances.

    From the Office of the CEO, Bynari Inc.

    Bynari Inc.

    2512 Program Drive Suite 108

    Dallas, TX 75220

    1-800-241-1086

    1-214-350-5772

    info@bynari.com

    http://www.bynari.com

    ================================================

  • Well, I don't know if you are right, but hopefully the Samba/MIT people are talking to lawyers and getting an informed opinion about the whole thing.

    Meanwhile, the Linux advocacy crowd has been distracted by this Microsoft letter to Slashdot. My theory was that this fight was intentional on Microsoft's part (notice how the letter goes out of it's way to mention "DMCA" as many times as possible).

    If you can't legally reverse-engineer or copy the protocol, at the very least, you can forget about this whole /. thing and start lobbying MS to openly release the spec. Quite a few Slashdotters work at big Microsoft shops, and if, as a customer, you let them know that Unix interoperability is important, they might just listen.
    --
  • Actually, I bet most working versions of Kerberos don't touch that field in debate like MS does, and will be fully compatible with Kerberos v6 or whatever. Everyone could claim "v6" compatibility without changing a damn thing except MS.

    Finally, even if there are other Kerberos implementations that don't work exactly with the MIT version, THEY JUST DON'T FULLY IMPLEMENT THE STANDARD, THEY AREN'T TRYING TO CHANGE/COOPT THE STANDARD! (sorry to yell)

    I'm all for looking at the MS side of the situation, and not bashing them just because we hate them, but seriously: How many dumb ass monopolistic things do they have to do before such hatred is justified? Fool me once, shame on you, fool me twice......
  • They just extended the protocol. Extensions is adding additional functionality while keeping the rest in tact. That's what they did. Period.

    The fuzz is not about the MS implementation of the protocol part. It's about the extension part. While there is NO SPECIFICATION WHATSOEVER in the protocol specs that states that extensions should be open too, people here think MS HAS TO open up the extensionimplementation. of course they don't have to.

    The Mac implementation is just an implementation of the protocol. If Apple adds an extension to the protocol, using own developmentresults, why should that be a voilation of MS' proprietry? Only if Apple copied MS' extension specifications AND says it's Apple's property. Like Mercedes rips of Ford's secret enginedevelopment's secrets and says it's theirs. Yes this is the same thing.

    Now, all: stop whining like a spoiled kid and get to work. There is a kernel to release.
    --
  • NASA's manned Mars mission should incorporate Microsoft's entire legal team. This will save on the need for fuel for the return journey.

    Don't forget marketing....

  • Re:MSFT Kerberos != Kerberos (Score:3)

    by Darchmare ( 5387 ) on Saturday May 20, 2000 @06:51AM (#1059566)
    ---
    Why treat Microsoft differently than everyone else? (aside from the obvious)
    ---

    Erm, because of the obvious...



    - Jeff A. Campbell
    - VelociNews (http://www.velocinews.com [velocinews.com])
  • When establishing a new standard, trademark the name. This can be perfectly compliant with OSS.

    Write a 'nominal fee' ($1) license for Kerberos (tm) and "Kerberoid"(tm) (or some other word that describes Kerberos compatibility), and explicit terms under which the license is automatically issued upon receipt of payment. Then give the Trademark to EFF (or IETF - thought IETF is less likely to enforce, and may move more slowly on changes)

    It is not to late to trademark Kerberos, since the originator has clear a clear history of title and trade use on this trade name for this "product".

    If one requirement for licensing is 'interoperability' with a reference standard, then MSFT Kerberos becomes a litigable violation. A clever lawyer may find a way to make 'Kerberos compatible' a violation, though it would not be straightforward.
    _____________
  • It seems that Bynari says [tradexch.com] it will work:

    We developed TradeXCHTM because the computer industry needed a UNIX/Linux client for MSExchangeTM with Outlook functionality. TradeXCH bridges the gap between Outlook users and UNIX/Linux users allowing them to work together.

    Results...the entire enterprise communicates as one, scheduling and calendaring are enabled throughout, and global addressing becomes a reality.

    Bynari enhanced TradeClient and created TradeXCH. TradeClient now exists as a separate LGPL project in the Open Source community. Bynari's developers have made it a free software project.

    Bynari's TradeXCH fulfills the enterprise gap by enabling a number of messaging protocols to communicate so that various platforms can work together --the way systems designers intended.

    Currently, TradeXCH runs on X86 processor versions of Linux. You can request versions for IBM's AIX, Solaris X86 and Sparc, HP UNIX and Alpha True64 UNIX/Linux operating systems.

    You may want to consider TradeServerTM as a Linux migration path from Microsoft ExchangeTM. TradeServer combines the full funtionality and inter-operability of Bynari's TradeclientTM, as well as Microsoft's OutlookTM client, using standards based non-proprietary protocols.

    Features:

    TradeServer functionality includes the following:

    Interoperability with Outlook 2000, and earlier versions of Outlook A cost effective alternative to proprietary software solutions, resulting in a significant reduction of Total Cost of Ownersip (TCO).

    Stability and robustness of the Linux OS for a scalable, reliable platform suited for stand alone and distributed deployment models.

    Excellent scalability from stand alone installation to distributed deployments, with support for multiple databases, and one MILLION entries per database. X based configuration and administration tools, as well as a web based administration option, allows for a variety of methods for deployment and management

  • Funny RTF/Microsoft story (Score:4)

    by Dictator For Life ( 8829 ) on Saturday May 20, 2000 @10:06AM (#1059569) Homepage
    I was called upon to create a placeholder Windows help file for an application. Nothing fancy -- just a couple paragraphs and absolutely no special formatting to it at all. I created the source file in Microsoft Wordpad on Microsoft Win95 and added it to my helpfile project in a Microsoft-produced helpfile-creator.

    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!

  • and how is that relevant?

    and what the fuck is astroturf supposed to mean here?
  • What the hell is your fascination with GPL?

    why not make it totally free, or design a better license that doesn't do what RMS wants you to do.
  • Um, Unix Services for Unix (SFU) supports NFS.

    It's also a Microsoft product.
  • That should be Windows services for unix.
  • I'm not sure what the $100m investment was for, but it has certainly paid off, as it is worth over $300m now.

    Settlement of a long-standing patent-infringement suit concerning of certain parts of Microsoft's "ActiveX" technology lifted from Quicktime practically feature-by-feature. Apple promised to drop the suit, which they promptly did, in return for the stock investment.

    --B
  • RFC does not *exactly* mean something is a standard.
    It's just that, usually, software is derived from the RFC (or vice-versa) and it becomes an unofficial standard. Take IPv4. You could read the rfc that specifies IPv4 and find several things that are not implemented, and will never be implemented in the Internet today (or any private IP network, for that matter). Some fields that were never really used in IPv4 (TOS, for one..) are now being used in an unrelated manner to do QOS... it's great, it's innovative, i'ts a re-use...

    And lots of rfc's are never used for anything....

    So rather, we can summarize how things work in the world today by referencing a bunch of rfc's.

    Changing the kerberos spec by producing a new RFC... nothing stops MS from saying that they have implemented kerberos. Still.. why not fix it.
  • Your Quote:
    > It also looks like Mac will be bringing Kerberos to OSX, in partnership with MIT.

    What was accually typed
    > It also looks like Apple will be bringing Kerberos to OSX, in partnership with MIT.

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

    No offense taken...
    I suspect however your brain is playing a small trick on you...
    Swapping out Apple and replacing it with Mac.
    It's done to improve your reading skills...

    I've never seen this before....
    And it's not what was posted....

    No biggy :) Some times I get that and I have to slow down and read it again to be sure I'm seeing what I think I am seeing... 9 times out of 10.. I'm not...
    Not a big issue :) Just wouldn't want you going around correcting people for a mistake they did not make... could be very embaressing
  • ---
    I suspect however your brain is playing a small trick on you...
    Swapping out Apple and replacing it with Mac.
    ---

    Nope. Slashdot changed it (well, at least they're responsive!).

    ---
    Just wouldn't want you going around correcting people for a mistake they did not make... could be very embaressing
    ---

    BTW, you misspelled emb... *SMACK!*

    Nevermind. :>


    - Jeff A. Campbell
    - VelociNews (http://www.velocinews.com [velocinews.com])
  • It is a known fact that microsoft has robbed, pillaged and raped standards open to the community to enhance it's goals, they have taken code and put a proprietary spin to it making it their standard, allowing them to have complete control, it is a good thing that they are planning to clamp down kerbos, cause M$ is getting seriously out of hand.

  • This might be interesting (Score:3)

    by haggar ( 72771 ) on Saturday May 20, 2000 @05:30AM (#1059579) Homepage Journal
    Of course, the first question that comes to mind is: how is this going to influence the recent legal actions Microsoft pulled against /.

    The second is, why is the IETF not in control of Kerberos completely, how could it happen that Microsoft made proprietary extension to the protocol?

  • I think it is shameful that MSFT would use the "Kerberos" name for its own proprietary protocol. The more people know that the "MSFT" modifier produces a third entity when joined to "Kerberos" the better. If rewriting the standard will help, so be it. We must keep up the publicity that MSFT Kerberos is not Kerberos.

    MSFT Kerberos: a true bait-and-switch.

  • > The second is, why is the IETF not in control of Kerberos completely, how could it happen that Microsoft made proprietary extension to the protocol?

    It's simple to make proprietary extensions to a (formerly) open protocol. Just implement the standards and then change them ever so slightly so that they can break compatibility with standards compatible products. The IETF doesn't have enough money to sue Microsoft and stop them.

    Microsoft thinks they're above standards bodies and the law. This is nothing new. You've seen it before:

    Their proprietary changes in Internet Explorer that break with W3C standards for HTML.

    Their proprietary changes to LDAP in Active Directory.

    And their recent proprietary changes to XML in Internet Explorer 5.5.

    And I can go on . . .

    Microsoft will argue that they are trying to "improve" the standards, but their so called improvements are simply trivial changes to try and seize a standard. Or as many of us like to say: Embrace, Extend, Extinguish.

    Hopefully this time it's not too late.

  • Said it all. Is MicroSoft more concerned w/ saving face and staying compliant, or maintaining it's grip. That's really what the whole thing is about.
    Still, who thinks the leagal dept isn't already gearing up to find another loophole to put the windows logo in? There's always something....

    -Earthman

  • Then again blink and layer are in the W3c specs are they? And they didn't come from Microsoft ...
  • I can only think of two API's, or specs, if you will, that microsoft has found reason to make non-interopable

    Java, and this -

    Are there more examples of protocols, specifications, API's, whatever, that had standards for interoperability, but the Windows or Microsoft implementation fails to meet them ?

    Not that I doubt there are, I've just never really looked into it.
  • If I understand things correctly, they can extend it, but not make it incompatible. I know it's not GPL, but does the license require any extensions be open-sourced as well?

  • Hey they have a runaway link on that page. I don't think I have ever seen a link that long..

    Anyway, it's great that this is happening. I hope M$ suffers greatly because of this. Although I know they won't. Damn it. I really wish we could all get at them bad.

    Anyway, I also hope developers come out with a patch to kerberos to make unix versions capable of talking to the M$ versions.

  • No, this is the way to do it (isn't OSX==BSD?):


    1. Download kerberos source

    2. Unzip and untar

    3. make all, make install.


    What's so hard about that?


    Oh, we're not talking about the port? Oh well. ;)

  • "Kerberos Loophole May Close around Microsoft's Neck"

    heh

    Something tells me the bias may be on our side this time, folks :)
  • The point was not that they innovated and added wonderful new features to the protocol - the point is that they promised to be 100%compatible and they aren't.

  • Re:This might be interesting (Score:3)

    by Cyberdyne ( 104305 ) on Saturday May 20, 2000 @05:36AM (#1059590) Journal
    Of course, the first question that comes to mind is: how is this going to influence the recent legal actions Microsoft pulled against /.

    I would imagine it won't. Why would it? All this means is that - hopefully - Microsoft will have to change their implementation to be compliant with the new standard.

    The second is, why is the IETF not in control of Kerberos completely, how could it happen that Microsoft made proprietary extension to the protocol?

    They left in a `loophole' which basically said `implementation-specific bits can go here'. Microsoft then used that for all their implementation specific details - but didn't document what those details were.

  • Of course, the first question that comes to mind is: how is this going to influence the recent legal actions Microsoft pulled against /.

    I doubt it will make much of an impact there. At this point it looks like Microsoft is backing away from this due to the incredible amount of bad press they got. I expect for the whole situation to slowly fade away.

    The second is, why is the IETF not in control of Kerberos completely, how could it happen that Microsoft made proprietary extension to the protocol?

    IETF doesn't really have any legal powers. There is little to nothing keeping anyone from coming up with nonstandard implementations of, or proprietary extensions to, IETF protocols. Unfortunately, I don't think that there is any GPL-like provisions to IETF's licensing that requires any derivative works to be published under the same type of license. If bullying companies like Microsoft continue to abuse that, I'd suggest that IETF might have to change their policies.

    MIT might have more control over certain aspects of Kerberos, as it was people working for/with MIT originally that were the core designers of it. Unfortunately, I've heard that Microsoft has made significant donations to MIT over the past few years, so MIT may not be too likely to try to fight Microsoft.

  • Are there more examples of protocols, specifications, API's, whatever, that had standards for interoperability, but the Windows or Microsoft implementation fails to meet them ?

    Every piece of software that they don't make.
    ___

  • Change the standard so that if an implementation is compliant, it really does interoperate with other standards-compliant implementations. This is the correct solution. I sincerely hope this change to the standard works out. Microsoft then has two choices: keep its version and admit to the world that it cares more about extending its monopoly than providing solutions to its customers, or change its implementation to play nice with Unix. Either way is a win for the community.

    According to the article, Microsoft said, "It's not about free speech. We're not asking for people's comments to be pulled down." EXCUSE ME??? That's exactly what they were asking in their letter to Slashdot. Fuck Microsoft.

    -Nathan Whitehead

  • Re:This might be interesting (Score:5)

    by CountZer0 ( 60549 ) on Saturday May 20, 2000 @05:44AM (#1059594) Homepage
    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.
  • MS Herpes 1.0?

    ----
  • This is just more non-information, the same as the non-information that is continuously posted about HP OpenMail.

    The client and the server REQUIRE that LDAP and or POP3 be open! This requires the Admins to be willing to support Linux and other open systems.

    The exchange protocol is illegal to write against. Any company that tries to make a linux client that works with the exchange protocol will get sued into the ground.
  • Microsoft is wholly dependent on the authors of Kerberos. They need to be able to claim interoperability and that they are on the cutting edge, but depend on the sanction of their victims. I think its excellent that the authors of the Kerberos spec are withdrawing that permission - in a sense reminding Micros~1: "Kerberos is MINE, and I'm LETTING you use it".

  • Kerberos is about security. The IETF can make analyses and determinations about the security of its standard protocols. If the Microsoft implementation of the extension does not cooperate to work toward necessary security in Kerberos, IETF (and MIT) are right to point this out and route around it.

    Microsoft started this discussion by publishing the document on the web. Now it has to live with the consequences.

    As far as the relevance to the Slashdot case goes, I suppose you noted the hints that the implementation for the extension is not original, since it was already presented on the Kerberos mailing list by another?

  • yes, but which Kerberos? (Score:4)

    by acb ( 2797 ) on Saturday May 20, 2000 @07:51AM (#1059599) Homepage
    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.)

  • This won't work as expected. (Score:4)

    by ericfitz ( 59316 ) on Saturday May 20, 2000 @07:56AM (#1059600)
    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 [ietf.org]).

    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 [cybersafe.com] (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 [ima.com] 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.

  • You may want to consider TradeServerTM as a Linux migration path from Microsoft ExchangeTM. TradeServer combines the full funtionality and inter-operability of Bynari's TradeclientTM, as well as Microsoft's OutlookTM client, using standards based non-proprietary protocols.
    Sounds to me like they are NOT implimenting the Exchange protocol under GNU/Linux, but are instead making YAMC (Yet another Mail CLient) that talks to Exchange via non-proprietary protocols (ie: POP3 et al) So.... Whats so special about this? Not much... It sounds like they have an open source version of Outlook's "Net Folders" maybe... Outlook CAN be configured to share Scheduling information via POP3 instead of using Exchange Server's Free/Busy stuff... (In fact, thats the way I always configure it... Linux smtp/pop3 server, Outlook 98/2000 clients using Net Folders. No need for the big $$$ Exchange server)

    So, what is this program really? It seems to be an Outlook compatible client. That is a neat step in the right direction, but has NOTHING to do with Exchange.
  • Well Small Dick, it's really time to pull up stakes and move on to another job.

    Why not propose an alternative "Web Based Info System" based on Perl/PHP, Apache, MySQL, Linux. Demonstrate the cost savings and rapid development.

    Do have a spec on the Information System their are looking to build? I do development work for a large Ag Bank and the Navy. Recently my company has developed several Information system such as:

    Online Memo Logs including attachment uploading and dynamic conversion of to pdf formats, e-mail announcements, access scoping.

    FAQ and Helpdesk managers. Let helpdesk personell help themselves.

    Image archive w/ image resizing, quality adjustment and batch file upload.

    Operational and Maintenance logs. Multi-user input with file upload and time tracking and acount tracking.

    etc.

    We would be happy to give you code if think you could get a piece of the work.

  • that's a dangerous road (Score:4)

    by SEAL ( 88488 ) on Saturday May 20, 2000 @10:34AM (#1059603)
    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
  • You know what kinda scares me? That Microsoft or the RIAA will "get it."

    Well spoken!

    -jerdenn

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

    This is right on. MS did Apple a favor and implemented Appleshare/IP for Win2k server and Apple has completely ignored Novell NDS in OS X. It doesn't help that Novell walked away from Macs with Netware 5, but if you've got to support Macs and PCs and the server contract is up, what possible reason would you have for choosing Netware?

    Anyone who thinks that Apple isn't in bed with MS is living a fantasy life.

  • Of course some of us aren't all that happy when we see interoperability suffering, no matter who the culprit is. But when Microsoft does something like this, everyone becomes very wary, because they've shown they have the market clout and the disposition to try to force their stuff down everyone's throat. Sortof the difference between anyone worrying about lil' ol' ME buying a gun, vs. a violent criminal.

  • Yup, they are embedding their version of a UID and GID (called a TID?) into that field along with some other info. Apparently this is what TOG did with DCE Kerberos -- put the Unix UID/GID in the same field and use it for local authorization.

    Folks should actually read the illegal slashdot posting of the spec (for security review purposes, of course!) - what's in there is not all that complex, and could probably be clean roomed.
    --
  • Agreed. Reverse-engineering is NOT easy, is NOT a cut-and-dried 100% scientific process (it is just as much a black art as it is a science), and does NOT always give a 100% accurate solution. You can't test (usually) every possible combination of bits and every possible state and interaction of the system. You can often sort of try to figure out how it probably was designed and confirm/deny a hypothesis of that and keep refining it. Plus you often get any implementation bugs to carry over into your implementation.

    The upshot of this is that a reverse-engineered implementation may not work 100% and could not be trusted 100% (in many cases).

  • And maybe we won't be so cavalier about allowing implementation defined parts of specifications. Not just because of disclosure/reverse-engineering/legal issues, but also for general interoperability. Look at the C language and the portability problems. If we define specs more rigorously we can avoid a lot of problems.

    If we don't either a situation like this Microsoft Kerberos one occurs, or people can't trust the implementation defined parts for anything, or the are interoperability problems, or someone comes along with a tighter standard anyway.

  • at least he spelled "mac" in lowercase letters. :) a lot of slashdot posters would have said something like "It also looks like MAC will be bringing Kerberos to OSX".. -_-

    [explanation for anyone confused by my statement: "MAC" and "Mac" are not the same thing. A "mac" or a "Mac" is short for "Macintosh", which is a type of computer. An "MAC" is an adress hardwired into an ethernet card used for identification. i hope this clears things up a bit. Most Linux users should understand this already, since Unix-style file systems are case-sensitive and will allow files to coexist despite the fact that treated case-insensitive they have the same name.. i would be willing to bet though that there are some linux users out there who do call mac MAC, and i'd be willing to bet some of these people are the exact same people who bitch like crazy whenever anyone uses the phrase "x windows" in place of "x", even in contexts where "x" alone could also be construed to mean X the bot on undernet, X the anime, or X the san fransisco punk band.. i'm ranting now aren't i? sorry. i've had a bad day.. -_-]
  • It forces Microsoft to adhere to certain rules if they want to claim Kerberos interoperability.

    Really, it's too late for that. Microsoft forked Kerberos for very good reasons (standard Kerberos doesn't do what they want it to), and worked on it for several years. If they lose the right to call it "Kerberos", they will still use it, and frankly, most of their customers won't give a damn - they are far more worried about (missing) NDS interoperability. Kerberos is pretty obscure and not widely deployed in PC-space.
    --
  • It does MSFT no good to say they comply with the old version of Kerberos if everyone moves on to a non-extend-and-embrace version. Noone will buy it then.
  • Well, you may be wrong about M$ not suffering. While the actions that M$ took are fairly common in the software industry, their approach to slashdot attempting to squash commentary and acting like the Borg were unquestionably misguided. From a technical standpoint, M$ is no different than Sun, Oracle, or IBM in their approaches to standards. But when the company that everybody loves to hate responds in such an arrogant way on a community like slashdot, I think the damage is severe. I mean, M$ actually supported most of Kerberos while Apple had nothing -- so one could argue that M$ had better support of standards. But instead of getting Kudos for making an honest start at bringing Kerbie to people's PCs, they end up looking like the Antichrist. IMHO, the fact that they went with Kerbie at all is good, and they will be influenced to eventually make their stuff fully interoperable with UNIX (I know, I sound like the pundits claiming that constructive engagement is good for China's human rights). Now, they did not get Kerberos perfect on their first try and that may have something to do with greed, but the real damage to them is the "I hate Microsoft" dialogoue flying around groups like this everywhere. Do you think it is ever possible for them to win back the trust of the developer community when they do silly things like this??
  • For a moment, I was thinking of that other loophole [securityfocus.com] in Kerberos...
  • no stupid. micro$hit is forbidden from entering UNIX space by their contracts with SCO.

    I didn't know that! That actually makes me feel more relieved!

    Damon

    Work as if you don't need the money,
    Love as if you've never been hurt, and
    Dance as if no one's watching.
  • The suspicion is that Microsoft put the extensions in purely to break
    interoperability. Since interoperability is one of the key points of
    Kerberos, if that is so, then they are trying to derail an open
    standard.

    If that wasn't their aim, then why haven't they tried to defend
    themselves on this point, instead of the lunatic `trade secret' route
    they chose?

  • But then, nothing would remain of the software Giant (well, maybe Sales...)
  • As to the current article, it surprises me that when writing a vendor-specific field, MIT wouldn't expect some companies to use that field to create implementations that were only operable between that single vendor's products.
    I'm sure they would expect it. Any real innovation would naturally not have other-party interoperable products, at first. The trouble with Microsoft's approach is, they want to lock in "at first' and make it "ever," by asserting trade secret and copy rights, instead of contributing unencumbered extensions to a public standard, and competing simply on the basis of being first to market with a technically excellent product, and marketing it well.
    To me, the current complaints sound like a knee-jerk anti-Microsoft reaction.
    I agree, there's a lot of that on /. I think of it more like a whole neighbohood of puppies starting to yap and howl when they hear one dog bark. You can ignore most of it, but the original bark may signify something you'd do well to investigate. And if you missed the original bark, you might want to know what got the puppies started.

    How is Microsoft any different from a small consulting company which might use the same Kerberos optional field in implementing a private project for their client? Well, IMHO there is a difference.

    Microsoft and other companies with very dominant market share are in the position of creating de facto standards in whatever they produce. Standards have an enabling role in a free market, namely that they define a basis for direct competition. Consumers can choose between competing products that do the same (to the extent defined by the standard) thing, which developers are able to produce with assurance because of the public standard.

    Microsoft's release of products including special uses of an optional Kerberos field will automatically create a new, de facto (extended) standard. Technically, fine (hopefully). Kudos to Microsoft for thinking up something new and useful. But standards-wise, maybe not so fine, if it is closed/restricted and serves to exclude competition.

    Microsoft's use of an optional Kerberos field does not make them nonconforming w.r.t. the base standard. But insofar as they are creating a new (and because of their market share, widespread) de facto standard, and insofar as they are excluding competition, they are in effect putting others into the position of being nonconforming -- with no permitted way of becoming so, except possibly by paying license fees to Microsoft. This is a perversion of the purpose of an open standard, and not so incidentally, the DMCA is an example of engineering extra locks to secure the perversion.

    I haven't looked at the new spec, but it immediately comes to mind that there are several ways to use open slots in a standard structure, and etiquette and technical foresight come into play. I doubt that Microsoft would simply pre-empt the full use of a slot by, e.g., storing a "handle" to a proprietary object in the slot. That would lock out other simultaneous independent options (except of course through mods to the proprietary object), which would be acceptable for a private project, but certainly not for a de-facto-standards-defining, market-dominating one. An acceptable alternative might be to use the slot as the head of a linked list which could be traversed according to open methodology. This wouldn't lock anyone else out of simultaneous optional-slot use. Etiquette would demand that the original standards authors/overseers/maintainers be consulted before proceeding with such a (list-structure) extension of the standard. The list nodes could then be used in private projects or de-facto-standards-defining mega-releases. I'd be interested in knowing how Microsoft proceeded.

    I believe much of the antipathy towards Microsoft stems from the sense that they don't want to compete on pure technical merit, even though they have recruited a tremendous pool of technical talent, whose members very likely feel they can win in a clean game, and would prefer it that way.

    Some (most?) lawyers and marketers are other kinds of players, though. It seems like they take pride in being able to "win" in any game, and a dirty game is just a game with different rules (and to them that's the way the world is), which makes it honorable to play as dirty as you can get away with, including {bribe,lobby}ing to change the rules in your favor as you're playing. I can see some people wanting to get into that kind of "sport" (can you be big-corp CEO otherwise in today's environment?), but sadly, it really fouls up the game for those of us who would rather not play that way. If we are the majority, perhaps we can get our representatives to work on reforming the rules of play, so fewer people would get hurt and more could enjoy it, and there would be less bad feelings among us all. Of course, our representatives are mostly lawyers ;-/

    Cheers :-)

  • Hmm... lessee... every new version of Word is non-interoperable with the previous one (breaking a defacto industry standard.) There is also the various standards breakages in IE (pick any version)(though Netscape wasjust as guilty). Those are just off the top of my head- I'm sure others can find more.
    ~luge

  • Re:This might be interesting (Score:5)

    by IntlHarvester ( 11985 ) on Saturday May 20, 2000 @05:58AM (#1059620) Journal
    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.
    --
  • Isn't the Samba team based in au? I thought Australia gave much better protection to reverse engineering than the US.

    Yeah, that's a very interesting question. Some of the Samba developers appear to be in Germany, too, where reverse engineering for the sake of compatibility is allowed.
    Would the resulting product still be redistributable in the US?

  • a reverse-engineered implementation may not work 100% and could not be trusted 100%

    This comment was probably not inteded as FUD, but that was the result.

    Almost every Wintel PC on the market owes its existance to Compaq, who reverse-engineered the IBM chipset in the 80's. (Back in "the day", people used the term "IBM Compatable" or "clone"... In order to obfuscate the fact that most Windows boxes were reverse-engineered copies of something, MICROS~1 usurped the term "PC", and insisted that people stop mentioning IBM when talking about Wintel systems.)

    Most of "GNU/Linux" (there I said it, happy RMS?) relied on reverse-engineering to get built, too... and it is pretty solid.

    Reverse engineering is hard work, but when done right it can be very successful, and sometimes will even produce a product that can be "trusted" more than the original.

  • Re:This is the way to do it (Score:5)

    by Katravax ( 21568 ) on Saturday May 20, 2000 @05:58AM (#1059623)

    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.

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

    This is sorta ironic, given that this was precisely the strategy first exercised by Microsoft to keep Samba incompatible (and thus out of the replacing-NT-business). They changed the SMB standard and had a few precious months (weeks? days?) of "innovation" before the changes were reverse-engineered and incorporated into Samba.

    Of course, the only thing the IETF is trying to protect is the equivalence of the terms "Kerberos compliant" and "Kerberos interoperable." Seems to make a lot more sense than Microsoft's attempt to make the terms "Microsoft compatible" and "Microsoft owned" indistinguishable...

  • Thanks for clueing me in with the answer to the second thought.
    But 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 see that others think alike. But I still have my doubts, not because of what MS claims in the case, but because of how /. designed their response letter, and thus their defense. It's clear that /. wants to involve a more broad scope into the picture, namely the legitimity AND usefulness of MS' copiright. /. sent this message (IMHO) "Kerberos is perceived and accepted as an open and universally useful protocol, and your stance may piss off many in the industry. Do you really want to do this?".
    In light of this, broader scope of /.'s defense, I guess Neuman's proposed rewrite will be beneficial to /. because it will re-enforce their position in the public eye.
    IMHO & IANAL (which means, I accept constructive criticism of my ideas)

  • It's pretty ironic that in this article dealing with Microsoft's Kerberos implementation, you're blaming Microsoft for their browser correctly interpreting the W3C's HTML 4.01 spec, by which </ a> isn't valid HTML. Now why do I get the feeling that if IE5 worked with this invalid HTML, you'd be moaning and crying about Microsoft embracing and extending the HTML standard? Hmmm?

    Just like Microsoft's Kerberos implementation adheres to the IETF Kerberos standard, so does IE5 adhere to the HTML standard in the example you mentioned above. What part of "standards" do you guys not understand? Looks like they're always a good thing except when Microsoft follows them.

    Cheers,
    ZicoKnows@hotmail.com

  • Well, after downloading and still using both their Interix and Services for Unix 2.0 packages, I don't feel that Microsoft is ignoring their Unix-using customers.

    Cheers,
    ZicoKnows@hotmail.com

  • "You know, you use that word a lot, but I don't think it means what you think it means ..."

    How about forcing people to make innovative *standards* that others can use and prosper from just as easily as you can? That is, after all, how the Internet came about. TCP/IP was very innovative, POP3/SMTP/HTTP/DNS too, Unix socket i/o, and yes, even Linux are all very innovative products. They're also very pervasive products as well, although this has as much to do with the fact that it's an *open innovation* than it does with the innovative nature of it...

    Micrsoft and its cronies love to use this 'innovate' word, but I don't think it means what they think it means. Maybe they're using MS Dictionary 1.0, I dunno.

  • Okay, I'll see your touché and raise you a c'est bon. I don't disagree with you about why some people are perturbed, it's just tiring to see so many people continue to misunderstand the fact that their Kerberos implementation is compliant. As to the current article, it surprises me that when writing a vendor-specific field, MIT wouldn't expect some companies to use that field to create implementations that were only operable between that single vendor's products. To me, the current complaints sound like a knee-jerk anti-Microsoft reaction.

    Cheers,
    ZicoKnows@hotmail.com

  • Certainly the name should be used, since it was not MS that invented Kerberos. All MS does is it uses an unused block within the header of the existing protocol to carry their own data. This does not change Kerberos protocol - it uses Kerberos protocol to carry some private data. So the name of the protocol can not be changed. In fact should MS rename the protocol into something else (and they would love to do that) they would have a serios copyright and patent infrigement case on their hands.

    Of-course MS marketing dep't consist of anal sfinctor boys and girls who all hope to become little Bills sometimes in the future and it is those people who are responsible for all the BS that is going on at MS. I don't think it is all about engineers, BUT should the engineers at MS be a little more conscientious and have at least a minute ability to feel ashamed they would not have abided with MS marketing dep't and would rather quit than fuck all the world around them.

    Thank you.

  • Neither does it display right in Netscape 4.72 under NT4. But it displays correctly in my sentimental favorite of all browsers, Lynx.

    Yours WDK - WKiernan@concentric.net

  • It's not a knee-jerk anti-Microsoft reaction, this outcry over Microsoft's latest standards-smashing scam is well-founded. The whole idea of Kerberos was to have a publicly-documented, platform-independent authentication scheme, and Microsoft deliberately broke it. To make matters worse, they pull this disgusting legal razzmatazz with their EULA-protected "trade secrets," to forestall legitimate reverse engineering.

    Cheat, cheat, cheat, and even in the midst of their antitrust suit they never stop - the Sid Vicious of software vendors. God knows, "business ethics" is something of an oxymoron, but even amidst the low, swinish company of capitalist businesses in general, Microsoft stands out; that damned gang is just plain pathological.

    OK, you could say that "any company in their position in a capitalist market system would act as they do," and I suspect you'd be right - but that is only an indictment of capitalism in general.

    Yours WDK - WKiernan@concentric.net

  • SMB was never an open spec, so it's not quite the same thing.

    I'm not sure exactly what you are talking about, but I don't think Microsoft ever intentionally tried to break Samba. They did change the authentication mechinism at some point, but that was because customers were bitching about their crappy authentication protocols. The change was documented, and Samba users had trouble, but so did WfW and Win95a and Win NT 3.5 users.
    --

  • Mac? (Score:4)

    by Darchmare ( 5387 ) on Saturday May 20, 2000 @06:13AM (#1059650)
    ---
    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 [velocinews.com])
  • Exchange itself. It does not work with open email standards.

    Where I work, the system admins on the M$HAFT side of things run the email. They absolutely refuse to open up pop3 or LDAP.

    Thus we can only use Outlook to read our mail; the exchange protocol is proprietary.

    People say that HP OpenMail has a client that will access Exchange from Linux, but I have never seen it on the HP website.

    As an aside, our company recently hired some M$HAFT types to write a "web based info system". They wrote it such that it only works with IE -- Netscape can't access it.
  • In a way, I hope that developers DON'T come out with a patch that makes "standard" kerberos capable of talking to MS Kerberos.

    Why? Because this would be tantamount to accepting the Microsoft extensions, and making the standard needlessly more complicated to support. Why should MS be allowed to have a different implementation than everyone else? Why should people who want to use Kerberos in heterogenous environments be forced to deal with 2 separate interfaces?

    No, I think that I would prefer to see the rest of the world adapt the new standard, and snub the MS version completely. That would be a great test of whether MS really does have monopoly power over the industry; we could just see who gave in. If it's a case of "The rest of the world" vs. "Microsoft", and the world loses...then there is definitely still a problem, and that means that MS can still do whatever they want, unchecked, and unfettered by what is good or preferable for the populance.

Slashdot Top Deals

Nothing ever becomes real till it is experienced -- even a proverb is no proverb to you till your life has illustrated it. -- John Keats

Close