Forgot your password?
typodupeerror
Microsoft

Kerberos, PACs And Microsoft's Dirty Tricks 417

Posted by Hemos
from the read-more-about-it dept.
Chris DiBona wrote to us with something that Ted and Jeremy (Samba Boys) wrote: "Microsoft, after getting beat up in the press for making propietary extensions to the Kerberos protocol, has released the specifications on the web -- but in order to get it, you have to run a Windows .exe file which forces you agree to a click-through license agreement where you agree to treat it as a trade secret, before it will give you the .pdf file. Who would have thought that you could publish a trade secret on the web?" Read more from the Samba Team below.

The critical part of the license states:

  • "b. The Specification is confidential information and a trade secret of Microsoft. Therefore, you may not disclose the Specification to anyone else (except as specifically allowed below), and you must take reasonable security precautions, at least as great as the precautions you take to protect your own confidential information, to keep the Specification confidential. If you are an entity, you may disclose the Specification to your full-time employees on a need to know basis, provided that you have executed appropriate written agreements with your employees sufficient to enable you to comply with the terms of this Agreement.
This is course is a very clever way to pretend to distribute the spec, whilst making it completely impossible to implement in competiting implementations which implements their propietary protocol extensions --- extensions to a protocol which was originally published by the Kerberos team as an Open Standard in the IETF. This completely defeats the IETF's interoperability goals, and helps Microsoft leverge their desktop monopoly into the server market.

The one good thing about Microsoft having pulled this dirty trick is that it makes their propietary intentions about the Windows 2000 PDC clear as day. I doubt anyone else could come up with a charitable explanation for what they've done. What a better example of Microsoft's "embrace, extend, and engulf" business model!

Jeremy Allison,
Samba Team.

Theodore Ts'o,
(former) Kerberos Development Lead "

This discussion has been archived. No new comments can be posted.

Kerberos, PACs And Microsoft's Dirty Tricks

Comments Filter:
  • I call your attention to the part you quoted which says "AT LEAST as great as the precautions you take to protect your own confidential information."

    What Microsoft's statement says is that the least amount of precautions you must take are those that you take with your own confidential information. You may take more, but it does not seem to require that you do so. Why would they bother including the statement above if they had expressly spelled out the precautions you must take?

    How many people have to download the information before it becomes common knowledge in the industry? Is it still a trade secret if everyone knows the secret? Doesn't make a lot of sense. Seems like Microsoft is playing a game and I hope to see them lose.

  • Why bother even mentioning B at all then? It seems to be completely irrelevant. Why not just say that X must be >= A then? That's why I didn't agree with the interpretation. Did they ever define A?

  • If a copyrighted work is illegally redistributed, perhaps even with a "new" license (one that could make it public domain, for example), that license is null and void since the work was obtained/distributed illegally in the first place. You can't just slap a new license on something unless you *own* that something. Anyone downloading your copy, legally, have zero rights to it. If they honestly didn't know it was ripped off, and thought the "new" license/copyright terms were the real ones, they would be fine (they'd just lose subsequent rights to the work in total).

    Of course, I'm just looking at this from a simple copyright perspective. People are using terms like trade secret and patent and trademark, etc., but simple copyright law is all that you need.

    They wrote the document; they can determine exactly who is allowed to get it via how it can be redistributed.

    Why don't we just borrow some books from the library and transcribe the contents on web pages? People would never have to buy books again! What about movies? CD's? It's the same concept.
  • This may very well be the case. However, you're missing a possibly subtle point.

    We're not in a war against them. We don't need to watch W2K die. We just need to continue doing our jobs -- and continue contributing to the community -- just as we've been doing.

    I'm not saying that we should ignore this kind of deliberate attack; it's likely that this attack will get in the way of us doing our jobs. My point is simply that we don't have to watch W2K die. The mere fact that its supporter is Microsoft, a company who does this kind of thing, will kill it -- together with the fact that the people (us) supporting the better operating systems don't do that.

    We should be known as the people willing to help other people get their jobs done, without stooping to bickering and fighting. Our motto should be something along the lines of: "It's not an operating system. It's people."

    -Billy
    "IT'S PEOPLE!!! YOU'VE GOT TO TELL THEM IT'S PEOPLE!! IT'S MADE OF PEOPLE!" -- Charlton Heston
  • IIRC, Microsoft has extended Kerberos in a standard way, that is, by using parts of the protocol which are intended to be vendor defined. I'm not sure whether they have maintained interoperability.
    --
  • IANAL, but I think that a trade secret can be legally protected if reasonable steps were taken to protect it. So if someone breaks in and steal your trade secret, then publishes it, other parties may be enjoined from using the information.

    A court would have to decide if Microsoft took reasonable steps to protect their trade secret in this case, I'd say they didn't, but then again I'm biased.
    --
  • the first paragraph says you have to have licensed it to read further.

    Actually, no it doesn't. It asks you to only look at the information if you have a license, it doesn't demand it. The actual wording is:

    Please review this specification only if you licensed and downloaded it from Microsoft Corporation's website; if you did not, please destroy this copy

    Note the use of the word "please". I'm free to ignore any requests from Microsoft Corporation, and I choose to do so here. BTW, I didn't agree to any licensing terms to get that information.

  • The Samba team doesn't protect their own confidential trade sectrets very well, and surely they could use this spec if they protected the implementation equally well. Microsoft knows that of course. But hey, they're not just giving away competitive advantages all of the sudden. It's a PR stunt for sure, but it's not good enough to be just that. There _must_ be something important which is not in the spec, or which is different in the spec. What could it be ? I haven't seen the spec myself and I don't know Kerberos stuff, but somehow we're going to find out when Samba implements the spec and some sort of hell breaks lose. My best guess would be that it is related to security - call me detective ;) Could there be some blatant backdoor inherent in an implementation following the spec ? Let's hear what people who know Kerberos and the spec say...
  • ...to create enough documents so that all that extra bits of info M$ is grabbing off your disk in Word files, which would include their kerberos source modifications, ends up being send along the bogus documents via email attachments.

    Reassemble everything, and you have sources that were published by MicroSoft's own incompetence in a way they can't blame you.
  • Clearly you haven't extracted it enough...

    Set up a pair of groups to extract it. One agrees to the terms and knows what the license is.

    The other does not agree, and never looks at the docs at all. But they keep making filters which they think are likely to strip the license. They make a metric crapload of them, present them to the 1st group and asks "Are any of these licenseless?"

    A bit of grepping determines the answer, and voila - a copy of the docs w/o license.

    ;)
    (and if you think I'm a lawyer, I've got this bridge that's very affordable...)
  • But my point is that with normal copyright, I can distribute works that rely on someone else's shared library. With GPL you can't legally do this, or at least RMS hopes you can't.

    IANAL, but: This issue is muddy because nobody really knows what the legal position is. There are essentially two possible cases:

    • Linking with a shared library does not make your program a derived work of that library. In this case, both proprietary software and GPLed software can be dynamically linked to any program you write and distribute. The GPL claims that this is not allowed, but if your program isn't a derived work of the GPLed code, then your program is not bound by the GPL's terms anyway.
    • Linking with a shared library does make your program a derived work. In this case, you cannot distribute a program linked with a library without permission from the library's copyright holder. Proprietary software might allow this, depending on the licence terms. Certainly something marketed as a 'library' would allow it under ceratin conditions. However, you could be on shakier ground if you wrote a program depending on 'some other company's shared library' which they hadn't given you permission to use (for example, if you wanted to use MS Word's import filters). The GPL also allows linking, treating it exactly the same as any other derived work - ie if you distribute your program, you must distribute it only under the GPL.
  • While the GPL gives you certain priveledges that you wouldn't have with normal copyrighted works, it also takes some normal rights away.

    ianal: It's not possible for a licence to take normal rights away (at least not without DMCA, UCITA, etc laws). The whole point of rights like fair use, parody and so on (which vary from country to country) is that they can't be taken away by the copyright holder, no matter how much crap is in the licence 'agreement'.

    Now the GPL claims that a program which uses a library is a derived work of that library, but if this turns out not to be true (it's not been tested in court AFAIK) then that section of the GPL doesn't carry any weight.

    In particular, it's perfectly legal for me to create a proprietary program that relies on some copyrighted shared library (.dll, .so, whatever-your-OS-uses) made by someone else.

    Are you sure? Without the permission of whoever wrote the library? Have a look at the files for Microsoft Office, pick a DLL at random and distribute your own program linking with that DLL. See what happens.

  • If failing to read a license causes me not to be bound by it, then maybe I'll just download the Linux kernel code, ignore the license, and call it public domain.
    Read what the GPL says:
    5. You are not required to accept this License, since you have not signed it.

    You don't have to accept the GPL at all. But you will be violating copyright if you distribute Linux under any licence except the GPL.

  • Ah, but the GPL grants you additional rights that you would not normally have under copyright law.

    While the GPL gives you certain priveledges that you wouldn't have with normal copyrighted works, it also takes some normal rights away. In particular, it's perfectly legal for me to create a proprietary program that relies on some copyrighted shared library (.dll, .so, whatever-your-OS-uses) made by someone else.

    If I tried to make a proprietary program that relied on a dynamically linked "libreadline" for example, I'd be in trouble though. According to RMS, GPL doesn't allow non-GPL programs to link with GPL code in this way, because the code "depends on" the GPL code.

    So I can do certain things with normal copyrighted works that I cannot do within the constraints of GPL (or at least the GPL's intent, according to RMS).
  • The GPL lets you make derivative works based on a shared library. It just doesn't let you DISTRIBUTE those derivative works.

    Fine. But my point is that with normal copyright, I can distribute works that rely on someone else's shared library. With GPL you can't legally do this, or at least RMS hopes you can't.

    Just like I might make a picture and say ``its free for you to use on webpages, but you can't sell t-shirts with it.'', the GPL is the same way.

    No, it's more like, "you can link to my web page only if your web page meets certain conditions". I'm talking about dynamic linking here, which is actually quite a bit like linking web pages in a sense.

    That's not taking away any rights you otherwise might have had.

    I think you completely missed the point. If I wanted to, I could write a program that relied on some other company's shared library, and I could sell tht program (and yes, distribute it). As long as I don't include the copyrighted library itself then copyright won't restrict me from doing that. However, with GPL, RMS's hope is that people are not allowed to create non-GPL programs that "depend upon" GPL code, even through dynamic linking.

    To give an example: it would be legal for me to create a non-GPL Macintosh emulator that required you to get your own Mac ROM files. The Mac ROMs are copyrighted, but it's okay (IANAL, but I'm fairly certain this is the case) for me to create software that depends on that copyrighted code, provided I don't go and give people that copyrighted code.

    If the Mac ROMs were under GPL though, I wouldn't be allowed to distribute a non-GPL emulator. My emulator would clearly be dependant upon the Mac ROMs, and the GPL states that in such a situation it had better be GPL too if I want to distribute it. Whether that would actually hold up in court, I don't know. But RMS's intent is obvious, and he's stated it publicly many times.

    You're just bitching because its not giving you the rights you want.

    I think you're confusing independent thought with bitching. I have no problem with the restrictions GPL places. I'm working on some code right now that I plan on releasing under GPL. Does that mean I agree with all of RMS's philosophies? No. I think content creators should get to name their price. If they want to give it away free, fine. If they want to get a million dollars, fine. If they want you to give away your source, fine. You don't like the price? Don't use the code. I write proprietary software too. That's how I pay the rent. I don't get donations like RMS.

    That said, I do have serious doubts about the dynamic linking restriction being legally enforceable, but I don't care much either way in this situation. It would set a rather nasty precedent, but as far as GPL goes, I have no intention of writing non GPLed code that dynamically links with GPLed code. That restriction (real, or only intended) is one that normal copyrighted code doesn't have though.
  • Now the FBI is looking for you Anonymous Coward and since you post comments to slashdot too many times a day they probably already know who are you.

    Note that that strategy of posting your comments from different IP addresses every time is not helping you any more to remain anonymous.
  • > So why do we need this information? Simple:
    > without this information it's impossible to
    > modify Samba to allow Kerberos authentication
    > (and encryption?) of remote shares.

    Actually this is not correct at all. Samba really doesn't need this information to do authentication or encryption from a Win2k client, as the Win2k client is kerb5 standards complient enough to allow this to work perfectly (once the code is added to Samba).

    It *would be* needed, however, to create a Win2k client compatible PDC, and it would also help if Samba used the extra SID information to do access control (map these SIDs into UNIX groups and do a setgroups() call from the smbd) if the Samba server were a member of a Win2k domain and was getting the user/group information from the Win2k PDC (either via LDAP or the new winbind daemon code). It's not even completely neccessary for the latter case, as we can get the same information by doing MS-RPC queries to a DC, it's just more efficient to pull the info out of the PAC.

    This spec is needed to add the PAC format to MIT kerb5 kdc's and heimdal kdc's, not for Samba.

    Hope that clears things up.

    Regards,

    Jeremy Allison,
    Samba Team.
  • > You may not value intelletual property but MS,
    > Xerox, and many other companies do.

    This isn't intellectual property, it's a land grab on a previously open spec.

    > Don't force your Open Source Religion on
    > everybody else

    But I don't want your code ! I want *OPEN* specs, implementable by anyone. That's how the internet got built.

    > Where's the problem?

    The problem is you are using your client desktop monopoly to attempt to gain a server monopoly. This is why you're being broken up. This is why you're being taken to court in the EU, this is *NOT LEGAL*. That's the problem.

    Regards,

    Jeremy Allison,
    Samba Team.

  • 1. Record the whole reverse engineering process on video to use as proof of actually rev.eng'ing, not following specs in court.

    2. Publishing a "trade secret" obviously isn't "reasonable effort to protect", is it? Even with oxymoronish "by reading this..." comments.

    3. Read the spec and explain it in your own words elsewhere. Someone else follows /your/ specs, not M$'s.

    4. Do it the Professional way (IBM, #118).

    Now if we only had enough interested developers to form four groups to make independent patches/modules for Samba.

    Better yet, IMHO IETF really should use the reserved bit differently in a new version, rendering MS "trade secret" inoperable. They just deserve it.

    Anything I didn't answer (or copy) yet, eh?
  • IANAL, but part of the laws regulating trade secrets presumes that you are taking reasonable measures to prevent the public release of the secret. Posting a "trade secret" to a website for the general public to access could very easily invalidate any future claims to trade secret status.

    An analogous situation would be if Bill Gates, staggering around drunk in Central Park, walked up to each of several thousand people and offered to tell them Microsoft trade secrets if they "promise not to tell". While there are no doubt judges that would let this crap slip by, I think it is likely that the vast majority of appellate courts would laugh loud and long at this. Secrets are secrets because they are, well, secret. They are not secret because Bill Gates distributes them to a billion-plus people and says "Shhhhhh".
  • So, what if some unknown person, logged on from a public access PC (such as at a library), downloaded this stuff, then posted it, sans license, on a free website, such as geocities? After a bit, it wouldn't really be a secret any more...

    On the other hand, what's the big deal? If no one uses Microsoft's extensions, it's a non-issue.

  • IANAL either, but from what I've heard things aren't so dire as you explain. in particular, no individual or company can place restrictions on your ability to *implement an idea*, otherwise than by patenting it, or having *you* accept these restrictions. if someone else gave the information to you (and there are no patents), you are legally FREE to use it. so the above posts aren't "illegal"; the act of posting them may be (but that's a risk the poster is taking), but the posts themselves are not.

    again, IANAL.

  • (Score:-1, Illegal) ?

    The idea that Microsoft could take the Samba team to court is both plausable yet sickening. Aren't they presumed innocent until proven otherwise? And how would it look for their PR? "Samba team taken to court over implementation of 'open' specification"

    The scary part is, it wouldn't surprise me.

  • Not necessary to give it out; just rewrite a description of the protocols in your own words.

    That doesn't violate copyright, and since it's a trade secret they can't patent it, so it'd be perfectly legal.

    Microsoft screwed up.

    --
  • I think it's clear that Microsoft has been deliberately, willfully engaged in criminal behavior for their entire existence.

    Not punishing them because the acts were performed by a corporation instead of a person is rubbish; they were performed by people, just as much as more horrible crimes in the 1930s and 1940 were performed by German soldiers, not by Germany.

    To not punish Microsoft for it's crimes, based on the idea that they won't commit them any more, would be like not jailing Ted Kaczynski because he hasn't blown anybody up lately.

    The Microsoft executives responsible for this debacle, including Bill Gates and Steve Ballmer, should be jailed for a long time and have all of their personal assets that derive from Microsoft seized and placed up for auction.

    Microsoft itself should be dissolved, all assets sold, and the proceeds divided among everyone who has ever bought or sold a copy of a Microsoft software product.

    The domain "microsoft.com" should be given to the Electronic Frontier Foundation, with them directed to operate a web server at that address with all the relevant court documents displayed there for all time.

    They should be directed to place the source code for all of their products under GPL immediately, and reassign the copyrights to Richard Stallman.

    Oh; and Gates should be delivered to the jail wearing lipstick and a miniskirt.

    --
  • How about if I said, "I baked a great lemon pie! I'll give you the recipie!" Then I send you a recipie for a good pie, with a legal agreement that says you can't share it, or use it, oh and by the way, it's not really lemon, it's artificially flavored, but you can't tell anyone.

    That's what MS is up to. They're offering you the recipie so that they can advertise (falsely) "lemon pie, with recipie".

  • It's bypassing the click-thru that's important. Having the license printed on every page may seem intimidating, but consider what would happen if you were to print it out and "loose" the printout. Whoever found it would most certainly not be bound by the license - hell, maybe they don't read English, or maybe they're a minor and legally unable to enter into this kind of agreement.

    In short, MS doesn't really have a legal leg to stand on. What they do have, however, is an excuse to drag whoever they want (Samba team, anyone?) into court and sue them into bankruptcy. They don't even have to win, just have enough cash - which they do - to be able to pay their lawyers longer than you can pay yours.

  • 1 - Lot's of people that they've done nothing wrong when in fact, in the eyes of the law, they have. Not that I'm defending them here, but it is completely plausible that one could err and still believe they did what was right.

    2 - I think that Microsoft did indeed help the industry. They provided a low-cost common platform for people to develop applications for. Sure they bought it from QDOS or whatever, but if they hadn't would the people who had QDOS had thought to call IBM up and say "hey... i've got this operating system?" Doubtfully. It's not like Microsoft made it so that the Unixes broke apart in every direction in the publics perspective.

    3 - People DO love him. Microsoft, up until the past few weeks, was one of the surest picks for year over year growth, profits, etc... Look at where $1000 invested in Microsoft 15 years ago would be today. Compare that with Apple, Novell, IBM, etc... For that reason, investment managers do love the company and him, since upuntil recently he ran it.

    4 - No argument from me here :) All they seem to do is sit back and wait for a good idea to spring out of silicon valley, buy the company or destroy the company, and reimplement that technology in windows or office.
  • Why don't they just read the stuff and write a SAMBA client thats "closed" source, and release it with no restrictions. That way the only way MS could know if they were violating the copyright would be if they themselves hacked the program to see what it does.

    ... but remember, I'm no lawyer.
  • Uh, how do you figure M$ is irrelevant? 89% some percent of people still use their OS on their personal computers and they make billions of dollars a year. I haven't seen them lose any developers. As a matter of fact a company around here just signed a juicy deal with M$ to provide them with biometric reading software thats going to be in the next couple versions of Windows.
  • Isn't it? What is the difference between a PDF files -- a stream of 1s and 0s which, when interpreted by a certain computer program, causes a particular action (i.e., a display of text) -- and a source code file

    Well, the manifestation of the bits isn't what we're talking about, but rather the words, the arrangements of letters and idea that the PDF contains, is what is protected without question, because those words (whether represented as bits, as ink, or as stone carvings) are a "creative expression".

    So to answer your question, the copyright status of the content wouldn't be affected by how it is stored (whether it's a PDF or a batch file that prints it to the screen). The words that are represented are protected. Whether or not the program that generates those words has a separate protection under [copyright|patent] is where the gray area and debate is.
  • I guess Windows 386 (1987) was a figment of my imagination.

    Nope, it was real. It just didn't do multitasking (task switching at best), and MS didn't have a multitasking OS until OS/2-WinNT in the 90's. Didn't have a multitasking consumer OS until win95 (arguably) or Win98.
  • I'm sure the anonymous coward who posted the contents of the contents of Microsoft's PAC specification here thought he was doing the world a favor and sticking it to the Evil Empire in the process. But the truth is that what the poster has done is illegal in the US thanks to the DMCA, whether we like it or not. Moreover, making the contents of the file widely available in this manner threatens to taint the efforts of those who need to get this information legally!

    The Samba team, and others who want Kerberos compatibility with Microsoft's PAC bastardization, need to come by this information legitimately -- either by reverse-engineering it, or by twisting MS's arm until they start behaving themselves and release the information openly. If anyone uses the above code to implement Win2k compatibility, Microsoft can take them to court for using stolen trade secrets.

    Even if the Samba team *doesn't* use this information, if it becomes widely available then it becomes very difficult to prove that those who did the reverse-engineering didn't read Microsoft's document... in which case Microsoft can still take people to court for it and keep them there for a very long time because of the difficulty of proving guilt or innocence. The last thing we want is for future Samba development to be caught up in a legal gray area for years on
    end.

    And don't be too sure that Microsoft wouldn't take the Samba team to court for something like that, even if they knew the Samba team was innocent. They're playing dirty here, milking the gullibility of the US legislature for all it's worth. Microsoft promised open documentation, and instead they've given us a legal boobytrap. Please, let's not play into their hands.
  • Glad that they did this? Not really. It's a strategic move on their part designed to make them look like good guys (look, we're publishing a spec! We're open!), when in fact what they've given us is completely useless to the Community (unless you really /prefer/ to use Microsoft's server products and are only interested in making them more secure). It's worse that useless, really: anyone who touches the documentation MS has put out can wind up in legal trouble with Microsoft if they later work on any project involving the reverse-engineering and reimplementation of the PAC.

    So thanks, Microsoft, but no thanks.
  • What? You mean you used that nefarious program WinZip to circumvent a content encryption scheme put in place to both protect copyright AND trade secrets? That's it! Under the DMCA all traces of WinZip must now be removed from the Internet! Anyone caught using WinZip from now on will have seven grades of shite kicked out of him/her by large men wearing big boots, sent round to your house by the MPAA.

    ;-)

    --
  • Here's a good question (IMHO). Part of making something a trade secret requires that you make a reasonable effort to protect the information. Microsoft's answer to this is making you click a license agreement before seeing the information. But, is that really a protection. If every single person on the Internet can access that information (even if they have to click on a license), can that really still be considered secret???

    ---


  • Given this fact, I wouldn't be surprised if this spec describes some small detail which is NOT present in the behavior of Win2K.

    If your implementation exhibits this behavior it'll be fairly obvious that you used the spec rather than properly reverse engineering the protocol. This should be enough to destroy you in court.
  • In the United States, any artistic expression is automatically copyrighted to the author on creation, regardless of copyright or other protections sought.

    It is a violation of the author's copyright to electronically distribute the Microsoft document without permission (even though they posted it on the web), or to make physical copies without permission. I personally find it silly to post technical specifications without granting the reader the right to make copies (i.e. print it out and make copies of that printout), but the decision as to making copies is up to the author.

    It is legal to distribute the "concept" (i.e. information content) contained in an artistic expression as long as it is rephrased (i.e. not an exact copy or derivative work). There are three exceptions to this:

    • Source code is a gray area currently being debated. Some people believe it is an artistic expression and is text, others believe it is something else altogether and not protected by copyright.
    • You can be held liable in certain circumstances if you illegally obtained information then redistributed it. The term trade secret refers to such information, and is part of the debate. National secrets come under this category as well (I think that term is something of an oxymoron if taken literally)
    • It is always legal to reproduce small portions of a work for review or commentary purposes provided a citation is given.

    So, like Metallica's songs, your post on /., and the book War of the Worlds, that PDF document is copyrighted. It is illegal to distribute it against the copyright holder's (MS) wishes. Whether it is legal to redistribute the information content (the spec.) without using the verbatim text is a separate question over which copyright law does not preside.

    magic

  • > What you can do is tell all your friends about what Microsoft is doing, especially those folks who work in I/T departments. Get them to understand why accepting a Windows 2000 deployment isn't in their company's long-term interest

    What amazes me is that any company would still do any business with Microsoft at all after the Halloween Documents, with their unabashed recommendation of decommoditizing protocols as a technical solution to Microsoft's marketing problem.

    When your vendor says "Sorry, but it's easier to compete in the marketplace by fucking you than to compete by producing a better product at a better price", then it is time to find another vendor.

    It amazes me that they've sold a single box since that bald suggestion was publicized. Let alone now that evidence of them actually using the suggestion has been revealed to the larger public.

    --
  • > About 10 years vefore MS got around to it...

    Innovation isn't the kind of thing you want to rush.

    --
  • Here's another one to Ponder: As I write this, does /. have editorial control over what I write? Or are they just a distribution channel for my comments published by me (by the very act of typing this in and pressing the submit button). I would venture that /. is a distributor and therefore not subject to responsibility for content in the same way Amazon.com is not responsible for the content of the material contained w/in the text of their product.
  • Fair use applies to straight copyright law. Contracts and EULAs can add additional rights. Remember, 'fair use' doesn't equate to 'you think it's fair'.

    Also, copyright law does not 'grant' you rights, it grants rights TO THE COPYRIGHT HOLDER. It gives them the power to license it to you under their own terms and conditions.

  • Uhh..
    how is that news?
    They are the 'first' to offer kerberos v5 native in windows 2000? Who ELSE would be offering it as native in windows 2000?
  • Even if this is the case.. if someone can show that anyone can just go fill out the form and get it.. can they still claim it to be trade secret?
    Or is this their way of saying 'see.. we're open about everything! we're not trying to hijack the protocol! OH! but if you try to build something using our proprietary extensions, we'll fuck you over'
  • IANAL... but...
    I've had to deal with Trade Secerets a fair amount of time.

    My understanding is that in order for a piece of information to maintain the classification then:
    1) I need to agree to keep the secret
    2) The information needs to be transmitted in writing (I'm assuming electronic form is considered writing) and
    3) At the bottom of each page should be a notice that this information is a Trade Secret.

    I believe (perhaps an IP Lawyer out there can verify) that unless those conditions are met, the information is not considered a Trade Secret.
    (ie. if someone gives you some documents and then later comes along and tells you, 'oh, and this is a trade secret' you don't have to follow their wishes)
    If this weren't the case then you wouldn't have to sign an NDA, they could just give you the document with the license 'printed on page 10 and 11'.

  • "...equal to asking you to sign..."

    Ah, but they're only asking. You don't have to sign anything you don't want to, being of sound mind and free will. I make it a practice to read everything I put my name and/or signature to. If I don't like or don't understand it, I don't sign it. Simple as that.

    Bothersome - people here imply that Microsoft is "tricking" people, that Microsoft is "forcing" them into an unagreeable license. But they're the ones who downloaded Microsoft's intellectual property and begat themselves of its wonders, and 9/10 of them knew there was a license attached to what they were reading.

    Seems to me the fools here are the ones who read the license, understood what it meant, didn't like it, and went ahead and clicked OK anyways. Stop all this talk of being forced to do things - you're not all helpless sheep victim to any passing breeze. You're human beings with rational minds and the ability to make decisions based on your judgement.

    And if you are a sheep, well, that's just the way you are, but if you *know* you're a sheep you shouldn't be going around clicking OK to things you don't understand.

    OK! I know flamebait when I see it. It's late.

    Nebulo
  • IANAL, but I think that a trade secret can be legally protected if reasonable steps were taken to protect it.

    I seriously doubt that posting it to the Net would count as a reasonable step to protect the secret. Either way I'm not touching W2K (and it's not touching any of my company's computers) until it can play nice.

    --
  • You're right; it isn't legal. But people think it's legal. And the relevant laws can be made to sound mumble-jumble enough that it only takes several million dollars worth of legal talent to convince a dozen of our peers that it is legal.
  • I am not 'the Slashdot crowd', I am me and speak only for myself. Sometimes not even that.

    Actually, the GPL violations in China do not interest me much either - anyone there who really wants the sources could probable get them anyway.
  • It's "Cerberus". "Cerebus" is an aardvark.
  • by Anonymous Coward on Tuesday May 02, 2000 @01:25PM (#1096614)
    Indeed MS has maintained interoperatbility. There were vendor defined fields where MS added extra information to make the delegation work between multiple W2K domains. Kerberos hasn't been tarnished by this and MS extended an olive branch by showing what they stuffed in the vendor-defined fields. Of course the /. folks go silly over a boilerplate licensing agreement rather than looking at the issue itself. Vendor defined fields can be a good thing if a standard does not have to be too tightly defined. Don't get upset folks. Your Kerberos network still works. I don't want to say who I am but I'm "in the know"
  • by Anonymous Coward on Tuesday May 02, 2000 @11:21AM (#1096615)
    Microsoft Authorization Data Specification v. 1.0
    for Microsoft Windows 2000 Operating Systems
    April, 2000
    ) 2000 Microsoft Corporation.
    All rights reserved.
    Microsoft Confidential
    Please review this Specification copy only if you licensed and downloaded it from Microsoft
    Corporations website; if you did not, please destroy this copy, but you are welcome to license the
    Specification at http://www.microsoft.com/technet/security/kerberos .
    If you are an authorized licensee, when you downloaded the following Specification, you agreed
    to the Agreement for Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000
    Operating Systems (the "Agreement"). For your future reference, that Agreement is reproduced at
    the end of this document.
    Abstract
    Microsoft Windows 2000 includes OS specific data in the Kerberos V5 authorization data field that is
    used for authorization as described in the Kerberos revisions Internet Draft [1]. This data is used for
    user logon and to create an access token. The access token is used by the system to enforce
    access checking when attempting to reference objects. This document describes the structure of
    the Windows 2000 specific authorization data that is carried in that field.
    Top-Level PAC Structure
    The PAC is generated by the KDC under the following conditions:
    during an AS request that has been validated with pre-authentication
    during a TGS request when the client has no PAC and the target is a service in the domain or a
    ticket granting service (referral ticket).
    The PAC itself is included in the IF-RELEVANT (ID 1) portion of the authorization data in a ticket.
    Within the IF-RELEVANT portion, it is encoded as a KERB_AUTH_DATA_PAC with ID 128.
    The PAC is defined as a C data type, with integers encoded in little-endian order. The PAC itself is
    made up of several layers. The outer structure, contained directly in the authorization data, is as
    follows. The top-level structure is the PACTYPE structure:
    typedef unsigned long ULONG;
    typedef unsigned short USHORT;
    typedef unsigned long64 ULONG64;
    typedef unsigned char UCHAR;
    typedef struct _PACTYPE {
    ULONG cBuffers;
    ULONG Version;
    PAC_INFO_BUFFER Buffers[1];
    } PACTYPE;
    The fields are defined as follows:
    cBuffers - contains the number of entries in the array Buffers
    Version - this is version zero
    Buffers - contains a conformant array of PAC_INFO_BUFFER structures
    The PAC_INFO_BUFFER structure contains information about each piece of the PAC:
    typedef struct _PAC_INFO_BUFFER {
    ULONG ulType;
    ULONG cbBufferSize;
    ULONG64 Offset;
    } PAC_INFO_BUFFER;
    Type fields are defined as follows:
    ulType - contains the type of data contained in this buffer. For Windows 2000, it may be one of the
    following, which are explained further below:
    #define PAC_LOGON_INFO 1
    #define PAC_CREDENTIAL_TYPE 2
    #define PAC_SERVER_CHECKSUM 6
    #define PAC_PRIVSVR_CHECKSUM 7
    #define PAC_CLIENT_INFO_TYPE 10
    Offset - contains the offset to the beginning of the data, in bytes, from the beginning of the
    PACTYPE structure. The data offset must by a multiple of 8. If the data pointed to by this field is
    complex, the data is typically NDR encoded. If the data is simple (indicating it includes no pointer
    types or complex structures) it is a little-endian format data structure.
    PAC Credential Information
    PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential information for the client of
    the Kerberos ticket. The data itself is contained in a KERB_VALIDATION_INFO structure, which is NDR
    encoded. The output of the NDR encoding is placed in the PAC_INFO_BUFFER structure of type
    PAC_LOGON_INFO.
    typedef struct _KERB_VALIDATION_INFO {
    FILETIME LogonTime;
    FILETIME LogoffTime;
    FILETIME KickOffTime;
    FILETIME PasswordLastSet;
    FILETIME PasswordCanChange;
    FILETIME PasswordMustChange;
    UNICODE_STRING EffectiveName;
    UNICODE_STRING FullName;
    UNICODE_STRING LogonScript;
    UNICODE_STRING ProfilePath;
    UNICODE_STRING HomeDirectory;
    UNICODE_STRING HomeDirectoryDrive;
    USHORT LogonCount;
    USHORT BadPasswordCount;
    ULONG UserId;
    ULONG PrimaryGroupId;
    ULONG GroupCount;
    [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
    ULONG UserFlags;
    ULONG Reserved[4];
    UNICODE_STRING LogonServer;
    UNICODE_STRING LogonDomainName;
    PSID LogonDomainId;
    ULONG Reserved1[2];
    ULONG UserAccountControl;
    ULONG Reserved3[7];
    ULONG SidCount;
    [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
    PSID ResourceGroupDomainSid;
    ULONG ResourceGroupCount;
    [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;
    } KERB_VALIDATION_INFO;
    The fields are defined as follows:
    LogonTime - the time the client last logged on.
    LogoffTime - the time at which the clients logon session should expire. If the logon session should
    not expire, this field should be set to (0x7fffffff,0xffffffff).
    KickOffTime - the time at which the server should forcibly logoff the client. If the client should not be
    forced off, this field should be set to (0x7fffffff,0xffffffff). The ticket end time is a replacement for the
    KickOffTime. The service ticket lifetime will never be longer than the KickOffTime for a user.
    PasswordLastSet - the time the clients password was last set. If it was never set, this field is zero.
    PasswordCanChange - the time at which the clients password is allowed to change. If there is no
    restriction on when the client may change its password, this field should be set to the time of the
    logon.
    PasswordMustChange - the time at which the clients password expires. If it doesnt expire, this field
    is set to (0x7fffffff,0xffffffff).
    EffectiveName - This field contains the clients Windows 2000 UserName, stored in the Active
    Directory in the SamAccountName property. This field is optional. If left blank the length, maxlength
    and buffer are all zero.
    FullName - this field contains the friendly name of the client, which is used only for display purpose
    and not security purposes. This field is optional. If left blank the length, maxlength and buffer are all
    zero.
    LogonScript - This field contains the path to the clients logon script. This field is optional. If left blank
    the length, maxlength and buffer are all zero.
    ProfilePath - This field contains the path to the clients profile. This field is optional. If left blank the
    length, maxlength and buffer are all zero.
    HomeDirectory - This field contains the path to the clients home directory. It may be either a local
    path name or a UNC path name. This field is optional. If left blank the length, maxlength and buffer
    are all zero.
    HomeDirectoryDrive - This field is only used if the clients home directory is a UNC path name. In that
    case, the share on the remote file server is mapped to the local drive letter specified by this field.
    This field is optional. If left blank the length, maxlength and buffer are all zero.
    LogonCount - This field contains the count of how many times the client is currently logged on. This
    statistic is not accurately maintained by Windows 2000 and should not be used.
    BadPasswordCount - This field contains the number of logon or password change attempts with
    bad passwords, since the last successful attempt.
    * UserId - This field contains the relative Id for the client.
    PrimaryGroupId - This field contains the relative ID for this clients primary group.
    * GroupCount - This field contains the number of groups, within the clients domain, to which the
    client is a member.
    * GroupIds - This field contains an array of the relative Ids and attributes of the groups in the clients
    domain of which the client is a member.
    * UserFlags - This field contains information about which fields in this structure are valid. The two bits
    that may be set are indicated below. Having these flags set indicates that the corresponding fields
    in the KERB_VALIDATION_INFO structure are present and valid.
    #define LOGON_EXTRA_SIDS 0x0020
    #define LOGON_RESOURCE_GROUPS 0x0200
    LogonServer - This field contains the NETBIOS name of the KDC which performed the AS ticket
    request.
    LogonDomainName - This field contains the NETBIOS name of the clients domain.
    * LogonDomainId - This field contains the SID of the clients domain. This field is used in conjunction
    with the UserId, PrimaryGroupId,and GroupIds fields to create the user and group SIDs for the client.
    UserAccountControl - This fields contains a bitfield of information about the clients account. Valid
    values are:
    #define USER_ACCOUNT_DISABLED (0x00000001)
    #define USER_HOME_DIRECTORY_REQUIRED (0x00000002)
    #define USER_PASSWORD_NOT_REQUIRED (0x00000004)
    #define USER_TEMP_DUPLICATE_ACCOUNT (0x00000008)
    #define USER_NORMAL_ACCOUNT (0x00000010)
    #define USER_MNS_LOGON_ACCOUNT (0x00000020)
    #define USER_INTERDOMAIN_TRUST_ACCOUNT (0x00000040)
    #define USER_WORKSTATION_TRUST_ACCOUNT (0x00000080)
    #define USER_SERVER_TRUST_ACCOUNT (0x00000100)
    #define USER_DONT_EXPIRE_PASSWORD (0x00000200)
    #define USER_ACCOUNT_AUTO_LOCKED (0x00000400)
    #define USER_ENCRYPTED_TEXT_PASSWORD_ALLOWED (0x00000800)
    #define USER_SMARTCARD_REQUIRED (0x00001000)
    #define USER_TRUSTED_FOR_DELEGATION (0x00002000)
    #define USER_NOT_DELEGATED (0x00004000)
    #define USER_USE_DES_KEY_ONLY (0x00008000)
    #define USER_DONT_REQUIRE_PREAUTH (0x00010000)
    * SidCount - This field contains the number of SIDs present in the ExtraSids field. This field is only valid
    if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
    * ExtraSids - This field contains a list of SIDs for groups to which the user is a member. This field is only
    valid if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
    * ResouceGroupCount - This field contains the number of resource groups in the ResourceGroupIds
    field. This field is only valid if the LOGON RESOURCE_GROUPS flag has been set in the UserFlags
    field._
    * ResourceGroupDomainSid - This field contains the SID of the resource domain. This field is used in
    conjunction with the ResourceGroupIds field to create the group SIDs for the client.
    * ResourceGroupIds - This field contains an array of the relative Ids and attributes of the groups in
    the resource domain of which the resource is a member.
    Fields marked with a '*' are used in the NT token.
    When used in the KERB_VALIDATION_INFO, this is NDR encoded. The FILETIME type is defined as
    follows:
    typedef unsigned int DWORD;
    typedef struct _FILETIME {
    DWORD dwLowDateTime;
    DWORD dwHighDateTime;
    } FILETIME;
    Times are encoded as the number of 100 nanosecond increments since January 1, 1601, in UTC
    time.
    When used in the KERB_VALIDATION_INFO, this is NDR encoded. The UNICODE_STRING structure is
    defined as:
    typedef struct _UNICODE_STRING
    USHORT Length;
    USHORT MaximumLength;
    [size_is(MaximumLength / 2), length_is((Length) / 2) ] USHORT * Buffer;
    } UNICODE_STRING;
    The Length field contains the number of bytes in the string, not including the null terminator, and the
    MaximumLength field contains the total number of bytes in the buffer containing the string.
    The GROUP_MEMBERSHIP structure contains the relative ID of a group and the corresponding
    attributes for the group.
    typedef struct _GROUP_MEMBERSHIP {
    ULONG RelativeId;
    ULONG Attributes;
    } *PGROUP_MEMBERSHIP;
    The group attributes must be:
    #define SE_GROUP_MANDATORY (0x00000001L)
    #define SE_GROUP_ENABLED_BY_DEFAULT (0x00000002L)
    #define SE_GROUP_ENABLED (0x00000004L)
    The SID structure is defined as follows:
    typedef struct _SID_IDENTIFIER_AUTHORITY {
    UCHAR Value[6];
    } SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY;
    The constant value for the NT Authority is:
    #define SECURITY_NT_AUTHORITY {0,0,0,0,0,5}
    typedef struct _SID {
    UCHAR Revision;
    UCHAR SubAuthorityCount;
    SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
    [size_is(SubAuthorityCount)] ULONG SubAuthority[*];
    } SID, *PSID;
    The SubAuthorityCount field contains the number of elements in the actual SubAuthority
    conformant array. The maximum number of subauthorities allowed is 15.
    The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and their corresponding
    attributes:
    typedef struct _KERB_SID_AND_ATTRIBUTES {
    PSID Sid;
    ULONG Attributes;
    } KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES;
    The attributes are the same as the group attributes defined above.
    Client Information
    The client information is included in the PAC to allow a server to verify that the PAC in a ticket is
    applicable to the client of the ticket, which prevents splicing of PACs between tickets. The
    PAC_CLIENT_INFO structure is included in a PAC_INFO_BUFFER of type PAC_CLIENT_INFO_TYPE.
    typedef struct _PAC_CLIENT_INFO {
    FILETIME ClientId;
    USHORT NameLength;
    WCHAR Name[1];
    } PAC_CLIENT_INFO, *PPAC_CLIENT_INFO;
    The fields are defined as follows:
    ClientId - This field contains a conversion of the AuthTime field of the ticket into a FILETIME structure.
    NameLength - This field contains the length, in bytes, of the Name field.
    Name - This field contains the client name from the ticket, converted to Unicode and encoded
    using "/" to separate parts of the client principal name with an "@" separating the client principal
    name from the realm name. The string is not null terminated.
    Supplemental Credentials
    The KDC may return supplemental credentials in the PAC as well. Supplemental credentials are
    data associated with a security package that is private to that package. They can be used to
    return an appropriate user key that is specific to that package for the purposes of authentication.
    Supplemental creds are only used in conjunction with PKINIT[2]. Supplemental credentials are
    always encrypted using the client key. The PAC_CREDENTIAL_DATA structure is NDR encoded and
    then encrypted with the key used to encrypt the KDCs reply to the client. The
    PAC_CREDENTIAL_INFO structure is included in PAC_INFO_BUFFER of type PAC_CREDENTIAL_TYPE.
    Supplemental credentials for a single package are NDR encoded as follows:
    typedef struct _SECPKG_SUPPLEMENTAL_CRED {
    UNICODE_STRING PackageName;
    ULONG CredentialSize;
    [size_is(CredentialSize)]PUCHAR Credentials;
    } SECPKG_SUPPLEMENTAL_CRED, *PSECPKG_SUPPLEMENTAL_CRED;
    The fields in this structure are defined as follows:
    PackageName - This field contains the name of the package for which credentials are presented.
    CredentialSize - This field contains the length, in bytes, of the presented credentials.
    Credentials - This field contains a pointer to the credential data.
    The set of all supplemental credentials is NDR encoded in a PAC_CREDENTIAL_DATA structure:
    typedef struct _PAC_CREDENTIAL_DATA {
    ULONG CredentialCount;
    [size_is(CredentialCount)] SECPKG_SUPPLEMENTAL_CRED Credentials[*];
    } PAC_CREDENTIAL_DATA, *PPAC_CREDENTIAL_DATA;
    The fields are defined as follows:
    CredentialCount - This field contains the number of credential present in the Credentials array.
    Credentials - This field contains an array of the presented supplemental credentials.
    The PAC_CREDENTIAL_DATA structure is NDR encoded and then encrypted with the key used to
    encrypt the KDC reply. The resulting buffer is returned in the following structure:
    typedef struct _PAC_CREDENTIAL_INFO {
    ULONG Version;
    ULONG EncryptionType;
    UCHAR Data[1];
    } PAC_CREDENTIAL_INFO, *PPAC_CREDENTIAL_INFO;
    The fields are defined as follows:
    Version - This field contains the version field of the key used to encrypt the data, or zero if the field is
    not present.
    EncryptType - This field contains the encryption type used to encrypt the data. The encryption type
    uses the same values as the defined encryptions types for Kerberos [1].
    Data - This field contains an array of bytes containing the encrypted supplemental credential data.
    Signatures
    The PAC contains two digital signatures: one using the key of the server, and one using the key of
    the KDC. The signatures are present for two reasons. First, the signature with the servers key is
    present to prevent a client from generating their own PAC and sending it to the KDC as encrypted
    authorization data to be included in tickets. Second, the signature with the KDCs key is present to
    prevent an untrusted service from forging a ticket to itself with an invalid PAC. The two signatures
    are sent in PAC_INFO_BUFFERs of type PAC_SERVER_CHECKSUM and PAC_KDC_CHECKSUM
    respectively.
    The signatures are contained in the following structure:
    typedef struct _PAC_SIGNATURE_DATA {
    ULONG SignatureType;
    UCHAR Signature[1];
    } PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA;
    The fields are defined as follows:
    SignatureType - This field contains the type of checksum used to create a signature. The checksum
    must be a keyed checksum.
    Signature - This field consists of an array of bytes containing the checksum data. The length of bytes
    may be determined by the wrapping PAC_INFO_BUFFER structure.
    For the servers checksum, the key used to generate the signature should be the same key used to
    encrypt the ticket. Thus, if the enc_tkt_in_skey option is used, the session key from the servers TGT
    should be used. The Key used to encrypt ticket-granting tickets is used to generate the KDCs
    checksum.
    The checksums are computed as follows:
    1. The complete PAC is built, including space for both checksums
    2. The data portion of both checksums is zeroed.
    3. The entire PAC structure is checksummed with the servers key, and the result is stored in the
    servers checksum structure.
    4. The servers checksum is then checksummed with the KDC's key.
    5. The checksum with the KDC key is stored in the KDC's checksum structure.
    PAC Request Pre-Auth Data
    Normally, the PAC is included in every pre-authenticated ticket received from an AS request.
    However, a client may also explicitly request either to include or to not include the PAC. This is done
    by sending the PAC-REQUEST preauth data.
    KERB-PA-PAC-REQUEST ::= SEQUENCE {
    include-pac[0] BOOLEAN -- if TRUE, and no PAC present,
    -- include PAC.
    ---If FALSE, and PAC
    -- present, remove PAC
    }
    The fields are defined as follows:
    include-pac - This field indicates whether a PAC should be included or not. If the value is TRUE, a
    PAC will be included independent of other preauth data. If the value is FALSE, then no PAC will be
    included, even if other preauth data is present.
    The preauth ID is:
    #define KRB5_PADATA_PAC_REQUEST 128
    References
    1 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat-kerberos-
    revisions-05.txt, March 10, 2000
    2 Tung, B., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J., Trostle, J., " Public Key Cryptography for
    Initial Authentication in Kerberos", draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000
    ) 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
  • by Matthew Weigel (888) on Tuesday May 02, 2000 @12:56PM (#1096616) Homepage Journal
    Obviously this person has violated the click-license agreement. But what happens if Jeremy picks up the stripped specs and implements them? Jeremy has agreed to nothing. So is he accountable? Is there something in the DMCA or other law which would place him in jeopardy?
    You mean, like copyright? Owning copyrighted without ever having been licensed to do so? Modifying copyrighted works?

    Just because the information contained in the doc is a trade secret, doesn't mean that the doc itself has no protection. It's no different from grabbing a Word doc of Ender's Game and throwing it on the web, sans copyright information.
  • by GeorgeH (5469) on Tuesday May 02, 2000 @10:56AM (#1096617) Homepage Journal
    "You must take reasonable security precautions, at least as great as the precautions you take to protect your own confidential information."

    Since we release our source code for the world to see, we should take the same precautions with their specifications, right? Since the precaution we take is by applying the GPL to our source, the same should be done with their spec. I guess they forgot that not everyone has been assimilated yet.
    --
  • by myconid (5642) on Tuesday May 02, 2000 @04:27PM (#1096618) Homepage
    Heres a good loophole. Install Winrar, right click on the icon and select OPEN WITH WINRAR, extract the file. Whats a license? I never saw one..


  • by Jeremy Allison - Sam (8157) on Tuesday May 02, 2000 @04:01PM (#1096619) Homepage
    > Of course the /. folks go silly over a
    > boilerplate licensing agreement

    Come now, this is hardly a "boilerplate licensing agreement". This is a deliberate attempt to keep control of the spec. and make it unimplementable in open code.

    This is not what *anyone* in the Open Source community or at MIT had in mind when they asked Microsoft for the spec, something I have personally been doing for 2+ years.

    > I don't want to say who I am but I'm "in the
    > know"

    Yeah, yeah, easy to say anonymously. I'd feel happier seeing a statement from folks I actually *know* and trust at Microsoft that this was a licensing screwup that will get fixed soon, but I'm not holding my breath.

    Regards,

    Jeremy Allison,
    Samba Team.
  • by Jeremy Allison - Sam (8157) on Tuesday May 02, 2000 @04:09PM (#1096620) Homepage
    > I think is that in order for their SMB client
    > (ie, microsoft networking) to use Kerberos
    > authentication when connecting to an SMB file
    > server, it requires the use
    > of their proprietary extension to kerberos, the
    > priveledge attribute certificate - PAC.
    > Apparently the Samba developers ran into this
    > problem while trying to add kerberos support to
    > samba and make it work with windows 2000

    No, this is not true at all. Samba doesn't *need* this PAC format except as an optimization. See my posting below in this.

    The MIT kerberos and Heimdal developers need to implement this PAC format, something explicitly denied to them in this license.

    Regards,

    Jeremy Allison,
    Samba Team.
  • by hatless (8275) on Tuesday May 02, 2000 @03:01PM (#1096621)
    Not sure what a court would make any of this.. a proprietary grab at an IETF task force submission (itself similar to the patent application for stylesheets last year).

    Maybe the answer is to get some 15-year-old programmers to merge this into the Samba, OpenLDAP and standard Kerberos code trees.

    In any case, this certainly poisons the well. Releasing the specs of their changes like this is worse than keeping it closed: it will make it extremely difficult for an unpolluted clean-room implementation of the modified protocol to be accepted into anything, as anyone who has reviewed this spec may well be barred from participating in even a reverse-engineered implementation.

    This is brilliantly evil.

    I wonder if the PDFs are individually watermarked to track *who* leaked a given copy. I don't think I've ever seen Microsoft publish anything as a PDF before. They usually pass this stuff out as HTML or a Word document.
  • by arivanov (12034) on Tuesday May 02, 2000 @11:55PM (#1096622) Homepage
    Erm... we need a new /. moderator category: "illegal"

    Yes we do. With a +2 rating.

  • by sterno (16320) on Tuesday May 02, 2000 @11:27AM (#1096623) Homepage
    The difference is that in the microsoft realm, this is the process:

    embrace -> extend

    In open source, this is the process:

    embrace -> extend -> publish extensions

    Open source advocates are very happy to back extension and improvement of a standard as long as it is a PUBLISHED standard. When a company adds an extension and refuses to publish it, they create incompatibility (or in other parlance, competitive advantage).

    Microsoft, historically, has extended things purely as a means of maintaining control. They don't actually enhance anything, they just attempt to maintain their monopoly. This appears to be yet another case of the same thing.

    ---

  • by Sehnsucht (17643) on Tuesday May 02, 2000 @10:43AM (#1096624)
    Isn't it true that minors can't agree to such licenses, or something like that? If so, I could have my lil bro download and click, then I could copy the PDF elsewhere.. hehe
  • by dillon_rinker (17944) on Tuesday May 02, 2000 @11:09AM (#1096625) Homepage
    I will give copies of the .pdf file to anyone who asks, its public domain as far as I'm concerned.

    I wouldn't do that. It's still copyrighted, and if you are associated with any group that "reverse engineers" the specs, whatever prodcut you create could get tied up in court for a long time. Distributing MS's copyrighted info could also get you into legal hot water.

    Now, if you're up for some work, what you could do is rewrite the whole thing, while preserving the ideas - copyright doesn't cover that. Or you could tell people how to get this. But don't make yourself a target for MS's legal division; that's completely unnecessary.
  • by Vlad_the_Inhaler (32958) on Tuesday May 02, 2000 @10:47AM (#1096626) Homepage
    So what happens if someone in Usbekistan grabs the specs and puts them up on the net? Does this then make them publicly available and the person who did this liable for prosecution in a country that could not care less anyway?

    The GPL (for instance) is routinely ignored in China so China would seem be another good candidate.
  • IANAL (and when I pretend to be, I'm often wrong (WIPTBIOW)), so feel free to give counterarguments if you think of any.

    Does this hamper legitimate reverse-engineering of the product?

    Before, the implementation details were not known except for inside microsoft, so if someone implemented it, it was assumed that they reverse-engineered it. If MS wanted to say that secrets were stolen from within MS, then MS had the burden of proof.

    Now, the details are out in the open, but unusable. So if someone implements it now, it's up to them to prove that they used clean room reverse-engineering. Furthermore, they might have to show that those in the clean room had never seen the public-but-secret document before.
    --

  • Now, I trust Microsfoft not as far one can comfortably spit a rat, but was there any call yet to verify if this was a lapse? "Slap on the usual license.." or such?

    I admire your charity..... but this is definitely not your usual license. Calling it a trade secret, and then adding the deliberate amplification that you're not allowed to create implementations of the specification is definitely not a stock legal license. This was something very carefully crafted to preserve a monopoly situation with respect to implementations of their propietary extensions of an Open IETF standard.

    This very carefully allows Microsoft to throw sand in the arguments of people who are complain that they part of the security protocols are secret, as Bruce Schinier recently complained. But at the same time, it doesn't allow anyone else to implement a compatible implementations. Obviously, they're still pissed that you can implement things like Samba, so that windows boxes can be served by Unix boxes. Windows 2000 is a way of trying to head that off.

    What can people do? Posting the pdf file on various web sites, as some people have done or threatened to do, isn't particularly helpful. In fact, to the extent that it makes it harder for people who are working on reverse engineering the protocol to prove that they weren't tainted with information that came from a trade-secret contaminated source, it actually can be doing people a real disservice.

    What you can do is tell all your friends about what Microsoft is doing, especially those folks who work in I/T departments. Get them to understand why accepting a Windows 2000 deployment isn't in their company's long-term interest, since it will eventually put them under the monopoly thumb of Microsoft. We can't trust the DOJ to protect us. We have to get the word out there, and protect ourselves. Remember, if you don't use Propietary Microsoft code, then you can't get caught by Microsoft's games.

  • by BlueUnderwear (73957) on Tuesday May 02, 2000 @01:15PM (#1096629)
    > So, what if some unknown person, logged on from a public access PC (such as at a library), downloaded this stuff, then posted it, sans license, on a free website, such as geocities?

    You're wish has been granted: kerberos.pdf [free-dvd.org.lu]

  • Download it here [free-dvd.org.lu]. It's unzipped, and that pesky footer on each page has been removed too. Enjoy!
  • by Loge (83167) on Tuesday May 02, 2000 @11:00AM (#1096631)
    whilst making it completely impossible to implement in competiting implementations which implements their propietary protocol extensions

    Huh? It looks to me like these conditions just specify what is required to gain access to the specification...I don't see anything that prohibits development competing implementation without Microsoft's consent. This agreement simply allows Microsoft to keep track of who sees the spec, nothing more.

    You can speculate on how they use this information, and how they might react in the future when competing implementations do appear, but that has nothing to do with who can or can't implement the extensions themselves.
  • by user (88235) on Tuesday May 02, 2000 @05:00PM (#1096632)
    Erm... we need a new /. moderator category: "illegal"

    INAL, but I believe that things of the nature of this "trade secret" fall under the same logic as copyrights - that is, as long as the provider, Microsoft, has made a good faith attempt to inform the recipients that the material has certain restrictions - which they have done - the material, and the recipient(s) are indeed bound by the restrictions (unless the restrictions themselves are found to be illegal). You can't download the information directly from MS without being informed of the existence of the license, and thus (assuming the license itself is legal), you are bound by it even if you creatively bypass the license itself.

    While individuals who may happen to receive the information through non-MS distribution channels are probably not breaking the license (if they can plausibly be unaware of its existence and circumvention), this is not to say that they are not bound by the "thou shalt not implement" clause, as this right was never bestowed by MS upon the original recipient.

    This would be analagous to me stealing something from CmdrTaco and giving it to you, not telling you where I got it from. You don't suddenly own the object, even though you didn't know it was stolen, and would be required to return it to CmdrTaco - and most likely any economic loss you suffered would be owed to you by me, the person who broke the law in the first place.

    -User
  • by ChadM (102789) on Tuesday May 02, 2000 @12:14PM (#1096633)
    when you can simply ignore it and continue using the REAL kerberos protocol(if you wish). Microsoft is trying to be sneaky by saying "maybe if we make it seem like we don't want people to use this they will use it even more." Look through it and realize that apps written utilizing this protocol will only tell Microsoft that their little ploy worked. If it keels over and dies they might realize "hah maybe we should just stick to the REAL protocols." I'm not an expert in the way all that stuff works but it seems fairly obvious to me what they're trying to do
  • by jbarnett (127033) on Tuesday May 02, 2000 @10:54AM (#1096634) Homepage

    Who would have thought that you could publish a trade secret on the web

    Oh dam, I bet that is why I was fired from Coke-a-cola... it is all so clear now.
  • by MPolo (129811) on Tuesday May 02, 2000 @10:57AM (#1096635)

    "Cerberus" is the three-headed dog from Greek mythology, if you pass the name through a Latin filter first. (Latin doesn't use K much, and "us" is a more common ending in Latin.) If you try to be faithful to the Greek, which has Kappa Epsilon Rho Beta Epsilon Rho Omicron Sigma -- you get Kerberos.

    "Cerebus", on the other hand, is an aardvark with an attitude, from the comic book of the same name, written and drawn by Dave Sim.

  • by Silicon Rat (172196) on Tuesday May 02, 2000 @04:14PM (#1096636)
    If somebody were to accidentally-brutally table this as evidence in a court case, it would become a matter of public record Be a shame that.
  • by Anonymous Coward on Tuesday May 02, 2000 @01:33PM (#1096637)
    That's the way to do it. Propose an extension of Kerberos that uses this field. After all, there's no published use for this field by anybody, so it's free for the using, right? :-)

    Make it similar to but not the same as what MS is doing so that MS's version is broken. (Gee, where have we seen that tactic before?). And we could even use the .pdf file to do it -- we're not implementing a compatible version, now are we? And after reviewing the MS doc "for security analysis", we decided that it wasn't quite up to snuff in the security arena (because it doesn't allow for secure authentication with non-MS systems).

  • by smartin (942) on Tuesday May 02, 2000 @11:20AM (#1096638)
    What happens to the people that implement it (ie. the Samba guys) even if they obtain the information without intentionally breaking the license. Are they exposing themselves to expensive litigation? Are they endangering the project?
  • I don't get why everyone is advocating tricks to get around clicking 'ok' on the license agreement. Does anyone really think that a judge would uphold that dodge in court? 'Oh, you didn't know the license was there, so you accidentally used winzip rather than just double clicking on the executable'. I don't see this going over well.

    The bigger issue here is that spreading stuff that Microsoft has indicated is not for distribution (and implementation) is no more morally respectable than someone ignoring inconvenient provisions in the Gnu General Public License. There may be a legal question as to whether anyone requires a license from Microsoft to implement any kind of spec, but taking the attitude that we have the right to take possession of their stuff is problematic at best.

    We don't want people to get the idea that free software / open source software people are thieves, we want them to get the idea that we are better because we are willing to do hard work on our own.

    Until a lawyer comes along and officially says that Microsoft's attempt at doing an orwellian double think specification release runs afoul of the law, leave this stuff alone.

  • by ink (4325) on Tuesday May 02, 2000 @11:50AM (#1096640) Homepage
    So open standards are passe, eh Microsoft?

    Remeber the AOL vs. IM [slashdot.org] debacle? When AOL refused to allow IM to work with AIM, Microsoft wanted a standards agency to govern some sort of instant message standard. Well, well, well, now we have a real, open RFC standard [isi.edu] defining Kerberos, but do they want it?

    This is typical Microsoft. They have some of the most excellent coders, and excellent people in other fields working there, but they also have some of the most selfish policies in the industry.

    The wheel is turning but the hamster is dead.

  • by JPelorat (5320) on Tuesday May 02, 2000 @11:15AM (#1096641)
    It's printed on every page. Extracting it from the file without reading that license gets you nowhere, cos the first paragraph says you have to have licensed it to read further. And then it's at the bottom of every page after that.

    Extracting it from the cab file doesn't do you any good. It certainly doesn't let you bypass the license.
  • by SgtPepper (5548) on Tuesday May 02, 2000 @10:40AM (#1096642)
    at least as great as the precautions you take to protect your own confidential information

    Well hrm....what if I /don't/ take any precautions to protect my confidential information?

    Or less crazy, what if the precautions I /do/ take aren't that great?

    Just a thought...

    Besides, shouldn't we be at least somewhat glad they did THIS. They didn't HAVE to. And yeah it's still stupid that they messed with Kerberos, but this is one step farther that they wouldn't have gone before.

    So far they're acting better then nVidia.

    Oooo, that's gonna piss someone off ;)
  • by Croaker (10633) on Tuesday May 02, 2000 @10:49AM (#1096643)
    Well, you got to give Microsoft credit. Their ability to reveal their additions to a perfectly good public standard in such a way as to remain propretary is certainly innovative.

  • by seebs (15766) on Tuesday May 02, 2000 @10:45AM (#1096644) Homepage
    Remember, you're allowed to try to *obtain* a trade secret, and once you do, if you haven't agreed to anything, it's no longer a secret.

    Trade secrets enjoy very little legal protection, unlike other kinds of information. They can't sue you for infringement, for instance.

    So, if someone is able to *extract* the information from the .exe, without running it or agreeing to anything, that's well and good.

    Trade secrets are a poor form of "security".
  • by MeanGene (17515) on Tuesday May 02, 2000 @10:43AM (#1096645)
    The license states that

    the Specification is provided...for the sole purpose of reviewing the Specification for security analysis.

    And later: Microsoft does not grant you any right to implement this Specification.

    I guess, if you want to make anything else out of it, you'd be in violation of everything and anything...

  • by alkali (28338) on Tuesday May 02, 2000 @01:02PM (#1096646)
    There should be something to protect us from these kind of things. Are you really allowed to make changes to a open standard and refuse to disclose it?

    Trivially, yes. Suppose I write a browser that I distribute in binary form that renders standard HTML except adds the element "". No law obliges me to disclose I've made this change to the standard.

    Qualification: It could be contended that the antitrust laws may prohibit a monopolist from doing this. Here is Robert Bork's argument to that effect in his white paper in the DOJ v. MS case [www.tao.ca]:

    That a monopolist or virtual monopolist is not free to define its product in ways that stifle competition is clear from
    Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. 585 (1985) [findlaw.com]. The defendant Skiing Co. owned and operated downhill skiing facilities on three mountains in Aspen; plaintiff Highlands operated on a fourth mountain. For years, the two companies offered a week-long pass, the "all-Aspen ticket," usable at any of the four mountains. The price was usually discounted from the price of daily tickets.

    Skiing Co. then initiated various changes that ended its cooperative marketing with Highlands, effectively denying skiers the benefits of the four-mountain pass and diminishing substantially skiers' use of Highland's mountain. In successive ski seasons, from 1976 to 1981, Highlands' share of downhill skiing services in Aspen declined steadily: from 20.5% to 15.7% to 13.1% to 12.5% to 11%. Though it agreed that "even a firm with monopoly power has no general duty to engage in a joint marketing program with a competitor," the Supreme Court said that if the firm attempts to exclude rivals on some basis other than efficiency, its behavior is predatory. The record supported the jury's finding that Skiing Co.'s conduct lacked an efficiency justification. The Court therefore upheld the conclusion that Skiing Co. had monopolized the market for downhill skiing services in Aspen. Aspen Skiing is a direct holding that a monopolist is not free to define its product for the purpose and with the effect of excluding a competitor.

    (Emphasis added. Incidentally, whatever you think of Bork as a constitutional theorist, he is recognized as standing among the very top rank of scholars of antitrust law, living or dead.)

  • by SvnLyrBrto (62138) on Tuesday May 02, 2000 @10:56AM (#1096647)
    Anonymous computer time at Kinkos: $.20/minute...

    Anonymous Geocities site to host the file: $0.00

    The looks on Gates and Ballmer's faces as their "trade secret" is mirrored on thousands of sites worldwide....

    ... Priceless!

    john
  • by altair1 (71744) on Tuesday May 02, 2000 @01:15PM (#1096648)
    win2000 actually will work with standard Kerberos services, to an extent. For instance, I set up a win2k workstation to authenticate logons against a unix KDC. You can also do some other small things, like ticket management while using a standard Kerberos KDC. But that is about the extent of their support for standard kerberos, at least as far as I know. The telnet and FTP clients are not Kerberized, and nothing in internet explorer is as far as I could tell.

    The problem raised in this article I think is that in order for their SMB client (ie, microsoft networking) to use Kerberos authentication when connecting to an SMB file server, it requires the use of their proprietary extension to kerberos, the priveledge attribute certificate - PAC. Apparently the Samba developers ran into this problem while trying to add kerberos support to samba and make it work with windows 2000 (using Kerberos authentication. Samba will still work with win2k using the older auth methods).

    So win2k does support standard kerberos, but not in enough applications (like file sharing, telnet, ftp, IE) for users to actually do anything usefull when working with a unix KDC. I suppose they might have just added this support so they could say win2k is compliant with that standard. If they ever do implement kerberos in any of their other apps, some of which I mentioned, it will probably be equally broken.

  • by Sami (83769) on Tuesday May 02, 2000 @10:47AM (#1096649)
    As most Microsoft's self-extracting files, this one is only a CAB file and therefore, you can simply use a program like WinZip [winzip.com] to extract the PDF document.
  • by tjwhaynes (114792) on Tuesday May 02, 2000 @10:43AM (#1096650)

    I'm amazed. Truely amazed. Given that nobody could be under any illusions at all that Microsoft was very much in the eye of the world at a time when the abuse of monopoly power has just been acknowledged by the courts, you would have thought that Microsoft would be on its best behaviour until the dust settled. But no.

    And it's not just the Kerberos 'embrace and extend' play which has surfaced. The story going around about the Bill Gates 'smoking gun' memo on altering Windows 2000 apps to make life harder for people with Palm Pilots has also just appeared. A large part of the DOJ/ US States proposal is that MS be split up *and* be subjected to 3 years of scrutiny under fairly draconian terms. So the last thing that MS could possibly want is to make the need for scrutiny mandatory and yet this is, in all effective purposes, exactly what moves like this are liable to do - leave the courts/govt no choice except to constantly sit on the coat tails of MS and see where they are going.

    Cheers,

    Toby Haynes

  • by Kagato (116051) on Tuesday May 02, 2000 @11:41AM (#1096651)
    It's not like companies don't get around this stuff all the time. It just takes a little more effort. You need to have a double blind. Basically doing the same thing that Compaq did with IBM's BIOS on the PC.

    The first part is person to write a spec. This spec. should detail how you want something to work. "When the client does X the server should respond with Y". Etc. etc.

    This person will have no other role. This person should not be associated with the developement of the MS extentions. Nor should he know any of the people who will be working on this.

    His work should be handed to a third party who will deliver his spec to the developement team. Reverse engineering shall begin. It's a pain to do, but it is workable.

    At any case there should be a nice stink made about this. I suggest that anyone who is a microsoft support customer contact your TAM or GTAM and let them know that this stinks.
  • by Anonymous Coward on Tuesday May 02, 2000 @12:37PM (#1096652)
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 1 of 12
    Microsoft Authorization Data Specification v. 1.0
    for Microsoft Windows 2000 Operating Systems
    April, 2000
    © 2000 Microsoft Corporation.
    All rights reserved.
    Microsoft Confidential
    Please review this Specification copy only if you licensed and downloaded it from Microsoft
    Corporation's website; if you did not, please destroy this copy, but you are welcome to license the
    Specification at http://www.microsoft.com/technet/security/kerberos .
    If you are an authorized licensee, when you downloaded the following Specification, you agreed
    to the Agreement for Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000
    Operating Systems (the "Agreement"). For your future reference, that Agreement is reproduced at
    the end of this document.
    Abstract
    Microsoft Windows 2000 includes OS specific data in the Kerberos V5 authorization data field that is
    used for authorization as described in the Kerberos revisions Internet Draft [1]. This data is used for
    user logon and to create an access token. The access token is used by the system to enforce
    access checking when attempting to reference objects. This document describes the structure of
    the Windows 2000 specific authorization data that is carried in that field.
    Top-Level PAC Structure
    The PAC is generated by the KDC under the following conditions:
    during an AS request that has been validated with pre-authentication
    during a TGS request when the client has no PAC and the target is a service in the domain or a
    ticket granting service (referral ticket).
    The PAC itself is included in the IF-RELEVANT (ID 1) portion of the authorization data in a ticket.
    Within the IF-RELEVANT portion, it is encoded as a KERB_AUTH_DATA_PAC with ID 128.
    The PAC is defined as a C data type, with integers encoded in little-endian order. The PAC itself is
    made up of several layers. The outer structure, contained directly in the authorization data, is as
    follows. The top-level structure is the PACTYPE structure:

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 2 of 12
    typedef unsigned long ULONG;
    typedef unsigned short USHORT;
    typedef unsigned long64 ULONG64;
    typedef unsigned char UCHAR;
    typedef struct _PACTYPE {
    ULONG cBuffers;
    ULONG Version;
    PAC_INFO_BUFFER Buffers[1];
    } PACTYPE;
    The fields are defined as follows:
    cBuffers - contains the number of entries in the array Buffers
    Version - this is version zero
    Buffers - contains a conformant array of PAC_INFO_BUFFER structures
    The PAC_INFO_BUFFER structure contains information about each piece of the PAC:
    typedef struct _PAC_INFO_BUFFER {
    ULONG ulType;
    ULONG cbBufferSize;
    ULONG64 Offset;
    } PAC_INFO_BUFFER;
    Type fields are defined as follows:
    ulType - contains the type of data contained in this buffer. For Windows 2000, it may be one of the
    following, which are explained further below:
    #define PAC_LOGON_INFO 1
    #define PAC_CREDENTIAL_TYPE 2
    #define PAC_SERVER_CHECKSUM 6
    #define PAC_PRIVSVR_CHECKSUM 7
    #define PAC_CLIENT_INFO_TYPE 10
    Offset - contains the offset to the beginning of the data, in bytes, from the beginning of the
    PACTYPE structure. The data offset must by a multiple of 8. If the data pointed to by this field is
    complex, the data is typically NDR encoded. If the data is simple (indicating it includes no pointer
    types or complex structures) it is a little-endian format data structure.

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 3 of 12
    PAC Credential Information
    PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential information for the client of
    the Kerberos ticket. The data itself is contained in a KERB_VALIDATION_INFO structure, which is NDR
    encoded. The output of the NDR encoding is placed in the PAC_INFO_BUFFER structure of type
    PAC_LOGON_INFO.
    typedef struct _KERB_VALIDATION_INFO {
    FILETIME LogonTime;
    FILETIME LogoffTime;
    FILETIME KickOffTime;
    FILETIME PasswordLastSet;
    FILETIME PasswordCanChange;
    FILETIME PasswordMustChange;
    UNICODE_STRING EffectiveName;
    UNICODE_STRING FullName;
    UNICODE_STRING LogonScript;
    UNICODE_STRING ProfilePath;
    UNICODE_STRING HomeDirectory;
    UNICODE_STRING HomeDirectoryDrive;
    USHORT LogonCount;
    USHORT BadPasswordCount;
    ULONG UserId;
    ULONG PrimaryGroupId;
    ULONG GroupCount;
    [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
    ULONG UserFlags;
    ULONG Reserved[4];
    UNICODE_STRING LogonServer;
    UNICODE_STRING LogonDomainName;
    PSID LogonDomainId;
    ULONG Reserved1[2];
    ULONG UserAccountControl;
    ULONG Reserved3[7];
    ULONG SidCount;
    [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
    PSID ResourceGroupDomainSid;
    ULONG ResourceGroupCount;
    [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;
    } KERB_VALIDATION_INFO;
    The fields are defined as follows:
    LogonTime - the time the client last logged on.

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 4 of 12
    LogoffTime - the time at which the client's logon session should expire. If the logon session should
    not expire, this field should be set to (0x7fffffff,0xffffffff).
    KickOffTime - the time at which the server should forcibly logoff the client. If the client should not be
    forced off, this field should be set to (0x7fffffff,0xffffffff). The ticket end time is a replacement for the
    KickOffTime. The service ticket lifetime will never be longer than the KickOffTime for a user.
    PasswordLastSet - the time the client's password was last set. If it was never set, this field is zero.
    PasswordCanChange - the time at which the client's password is allowed to change. If there is no
    restriction on when the client may change its password, this field should be set to the time of the
    logon.
    PasswordMustChange - the time at which the client's password expires. If it doesn't expire, this field
    is set to (0x7fffffff,0xffffffff).
    EffectiveName - This field contains the client's Windows 2000 UserName, stored in the Active
    Directory in the SamAccountName property. This field is optional. If left blank the length, maxlength
    and buffer are all zero.
    FullName - this field contains the friendly name of the client, which is used only for display purpose
    and not security purposes. This field is optional. If left blank the length, maxlength and buffer are all
    zero.
    LogonScript - This field contains the path to the client's logon script. This field is optional. If left blank
    the length, maxlength and buffer are all zero.
    ProfilePath - This field contains the path to the client's profile. This field is optional. If left blank the
    length, maxlength and buffer are all zero.
    HomeDirectory - This field contains the path to the client's home directory. It may be either a local
    path name or a UNC path name. This field is optional. If left blank the length, maxlength and buffer
    are all zero.
    HomeDirectoryDrive - This field is only used if the client's home directory is a UNC path name. In that
    case, the share on the remote file server is mapped to the local drive letter specified by this field.
    This field is optional. If left blank the length, maxlength and buffer are all zero.
    LogonCount - This field contains the count of how many times the client is currently logged on. This
    statistic is not accurately maintained by Windows 2000 and should not be used.
    BadPasswordCount - This field contains the number of logon or password change attempts with
    bad passwords, since the last successful attempt.
    * UserId - This field contains the relative Id for the client.
    PrimaryGroupId - This field contains the relative ID for this client's primary group.
    * GroupCount - This field contains the number of groups, within the client's domain, to which the
    client is a member.
    * GroupIds - This field contains an array of the relative Ids and attributes of the groups in the client's
    domain of which the client is a member.
    * UserFlags - This field contains information about which fields in this structure are valid. The two bits
    that may be set are indicated below. Having these flags set indicates that the corresponding fields
    in the KERB_VALIDATION_INFO structure are present and valid.
    #define LOGON_EXTRA_SIDS 0x0020
    #define LOGON_RESOURCE_GROUPS 0x0200
    LogonServer - This field contains the NETBIOS name of the KDC which performed the AS ticket
    request.

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 5 of 12
    LogonDomainName - This field contains the NETBIOS name of the client's domain.
    * LogonDomainId - This field contains the SID of the client's domain. This field is used in conjunction
    with the UserId, PrimaryGroupId,and GroupIds fields to create the user and group SIDs for the client.
    UserAccountControl - This fields contains a bitfield of information about the client's account. Valid
    values are:
    #define USER_ACCOUNT_DISABLED (0x00000001)
    #define USER_HOME_DIRECTORY_REQUIRED (0x00000002)
    #define USER_PASSWORD_NOT_REQUIRED (0x00000004)
    #define USER_TEMP_DUPLICATE_ACCOUNT (0x00000008)
    #define USER_NORMAL_ACCOUNT (0x00000010)
    #define USER_MNS_LOGON_ACCOUNT (0x00000020)
    #define USER_INTERDOMAIN_TRUST_ACCOUNT (0x00000040)
    #define USER_WORKSTATION_TRUST_ACCOUNT (0x00000080)
    #define USER_SERVER_TRUST_ACCOUNT (0x00000100)
    #define USER_DONT_EXPIRE_PASSWORD (0x00000200)
    #define USER_ACCOUNT_AUTO_LOCKED (0x00000400)
    #define USER_ENCRYPTED_TEXT_PASSWORD_ALLOWED (0x00000800)
    #define USER_SMARTCARD_REQUIRED (0x00001000)
    #define USER_TRUSTED_FOR_DELEGATION (0x00002000)
    #define USER_NOT_DELEGATED (0x00004000)
    #define USER_USE_DES_KEY_ONLY (0x00008000)
    #define USER_DONT_REQUIRE_PREAUTH (0x00010000)
    * SidCount - This field contains the number of SIDs present in the ExtraSids field. This field is only valid
    if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
    * ExtraSids - This field contains a list of SIDs for groups to which the user is a member. This field is only
    valid if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
    * ResouceGroupCount - This field contains the number of resource groups in the ResourceGroupIds
    field. This field is only valid if the LOGON RESOURCE_GROUPS flag has been set in the UserFlags
    field._
    * ResourceGroupDomainSid - This field contains the SID of the resource domain. This field is used in
    conjunction with the ResourceGroupIds field to create the group SIDs for the client.
    * ResourceGroupIds - This field contains an array of the relative Ids and attributes of the groups in
    the resource domain of which the resource is a member.
    Fields marked with a '*' are used in the NT token.
    When used in the KERB_VALIDATION_INFO, this is NDR encoded. The FILETIME type is defined as
    follows:
    typedef unsigned int DWORD;
    typedef struct _FILETIME {
    DWORD dwLowDateTime;
    DWORD dwHighDateTime;
    } FILETIME;

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 6 of 12
    Times are encoded as the number of 100 nanosecond increments since January 1, 1601, in UTC
    time.
    When used in the KERB_VALIDATION_INFO, this is NDR encoded. The UNICODE_STRING structure is
    defined as:
    typedef struct _UNICODE_STRING
    USHORT Length;
    USHORT MaximumLength;
    [size_is(MaximumLength / 2), length_is((Length) / 2) ] USHORT * Buffer;
    } UNICODE_STRING;
    The Length field contains the number of bytes in the string, not including the null terminator, and the
    MaximumLength field contains the total number of bytes in the buffer containing the string.
    The GROUP_MEMBERSHIP structure contains the relative ID of a group and the corresponding
    attributes for the group.
    typedef struct _GROUP_MEMBERSHIP {
    ULONG RelativeId;
    ULONG Attributes;
    } *PGROUP_MEMBERSHIP;
    The group attributes must be:
    #define SE_GROUP_MANDATORY (0x00000001L)
    #define SE_GROUP_ENABLED_BY_DEFAULT (0x00000002L)
    #define SE_GROUP_ENABLED (0x00000004L)
    The SID structure is defined as follows:
    typedef struct _SID_IDENTIFIER_AUTHORITY {
    UCHAR Value[6];
    } SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY;
    The constant value for the NT Authority is:
    #define SECURITY_NT_AUTHORITY {0,0,0,0,0,5}
    typedef struct _SID {
    UCHAR Revision;
    UCHAR SubAuthorityCount;

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 7 of 12
    SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
    [size_is(SubAuthorityCount)] ULONG SubAuthority[*];
    } SID, *PSID;
    The SubAuthorityCount field contains the number of elements in the actual SubAuthority
    conformant array. The maximum number of subauthorities allowed is 15.
    The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and their corresponding
    attributes:
    typedef struct _KERB_SID_AND_ATTRIBUTES {
    PSID Sid;
    ULONG Attributes;
    } KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES;
    The attributes are the same as the group attributes defined above.
    Client Information
    The client information is included in the PAC to allow a server to verify that the PAC in a ticket is
    applicable to the client of the ticket, which prevents splicing of PACs between tickets. The
    PAC_CLIENT_INFO structure is included in a PAC_INFO_BUFFER of type PAC_CLIENT_INFO_TYPE.
    typedef struct _PAC_CLIENT_INFO {
    FILETIME ClientId;
    USHORT NameLength;
    WCHAR Name[1];
    } PAC_CLIENT_INFO, *PPAC_CLIENT_INFO;
    The fields are defined as follows:
    ClientId - This field contains a conversion of the AuthTime field of the ticket into a FILETIME structure.
    NameLength - This field contains the length, in bytes, of the Name field.
    Name - This field contains the client name from the ticket, converted to Unicode and encoded
    using "/" to separate parts of the client principal name with an "@" separating the client principal
    name from the realm name. The string is not null terminated.
    Supplemental Credentials
    The KDC may return supplemental credentials in the PAC as well. Supplemental credentials are
    data associated with a security package that is private to that package. They can be used to
    return an appropriate user key that is specific to that package for the purposes of authentication.
    Supplemental creds are only used in conjunction with PKINIT[2]. Supplemental credentials are
    always encrypted using the client key. The PAC_CREDENTIAL_DATA structure is NDR encoded and

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 8 of 12
    then encrypted with the key used to encrypt the KDC's reply to the client. The
    PAC_CREDENTIAL_INFO structure is included in PAC_INFO_BUFFER of type PAC_CREDENTIAL_TYPE.
    Supplemental credentials for a single package are NDR encoded as follows:
    typedef struct _SECPKG_SUPPLEMENTAL_CRED {
    UNICODE_STRING PackageName;
    ULONG CredentialSize;
    [size_is(CredentialSize)]PUCHAR Credentials;
    } SECPKG_SUPPLEMENTAL_CRED, *PSECPKG_SUPPLEMENTAL_CRED;
    The fields in this structure are defined as follows:
    PackageName - This field contains the name of the package for which credentials are presented.
    CredentialSize - This field contains the length, in bytes, of the presented credentials.
    Credentials - This field contains a pointer to the credential data.
    The set of all supplemental credentials is NDR encoded in a PAC_CREDENTIAL_DATA structure:
    typedef struct _PAC_CREDENTIAL_DATA {
    ULONG CredentialCount;
    [size_is(CredentialCount)] SECPKG_SUPPLEMENTAL_CRED Credentials[*];
    } PAC_CREDENTIAL_DATA, *PPAC_CREDENTIAL_DATA;
    The fields are defined as follows:
    CredentialCount - This field contains the number of credential present in the Credentials array.
    Credentials - This field contains an array of the presented supplemental credentials.
    The PAC_CREDENTIAL_DATA structure is NDR encoded and then encrypted with the key used to
    encrypt the KDC reply. The resulting buffer is returned in the following structure:
    typedef struct _PAC_CREDENTIAL_INFO {
    ULONG Version;
    ULONG EncryptionType;
    UCHAR Data[1];
    } PAC_CREDENTIAL_INFO, *PPAC_CREDENTIAL_INFO;
    The fields are defined as follows:
    Version - This field contains the version field of the key used to encrypt the data, or zero if the field is
    not present.

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 9 of 12
    EncryptType - This field contains the encryption type used to encrypt the data. The encryption type
    uses the same values as the defined encryptions types for Kerberos [1].
    Data - This field contains an array of bytes containing the encrypted supplemental credential data.
    Signatures
    The PAC contains two digital signatures: one using the key of the server, and one using the key of
    the KDC. The signatures are present for two reasons. First, the signature with the server's key is
    present to prevent a client from generating their own PAC and sending it to the KDC as encrypted
    authorization data to be included in tickets. Second, the signature with the KDC's key is present to
    prevent an untrusted service from forging a ticket to itself with an invalid PAC. The two signatures
    are sent in PAC_INFO_BUFFERs of type PAC_SERVER_CHECKSUM and PAC_KDC_CHECKSUM
    respectively.
    The signatures are contained in the following structure:
    typedef struct _PAC_SIGNATURE_DATA {
    ULONG SignatureType;
    UCHAR Signature[1];
    } PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA;
    The fields are defined as follows:
    SignatureType - This field contains the type of checksum used to create a signature. The checksum
    must be a keyed checksum.
    Signature - This field consists of an array of bytes containing the checksum data. The length of bytes
    may be determined by the wrapping PAC_INFO_BUFFER structure.
    For the server's checksum, the key used to generate the signature should be the same key used to
    encrypt the ticket. Thus, if the enc_tkt_in_skey option is used, the session key from the server's TGT
    should be used. The Key used to encrypt ticket-granting tickets is used to generate the KDC's
    checksum.
    The checksums are computed as follows:
    1. The complete PAC is built, including space for both checksums
    2. The data portion of both checksums is zeroed.
    3. The entire PAC structure is checksummed with the server's key, and the result is stored in the
    server's checksum structure.
    4. The server's checksum is then checksummed with the KDC's key.
    5. The checksum with the KDC key is stored in the KDC's checksum structure.

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    This Specification is provided pursuant to the terms and conditions of the Agreement for Microsoft Authorization Data Specification
    v. 1.0 for Microsoft Windows 2000 Operating Systems (the "Agreement") for the sole purpose of allowing review of the
    Specification for security analysis, as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an authorized licensee of the Specification.
    Page 10 of 12
    PAC Request Pre-Auth Data
    Normally, the PAC is included in every pre-authenticated ticket received from an AS request.
    However, a client may also explicitly request either to include or to not include the PAC. This is done
    by sending the PAC-REQUEST preauth data.
    KERB-PA-PAC-REQUEST ::= SEQUENCE {
    include-pac[0] BOOLEAN -- if TRUE, and no PAC present,
    -- include PAC.
    ---If FALSE, and PAC
    -- present, remove PAC
    }
    The fields are defined as follows:
    include-pac - This field indicates whether a PAC should be included or not. If the value is TRUE, a
    PAC will be included independent of other preauth data. If the value is FALSE, then no PAC will be
    included, even if other preauth data is present.
    The preauth ID is:
    #define KRB5_PADATA_PAC_REQUEST 128
    References
    1 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat-kerberos-
    revisions-05.txt, March 10, 2000
    2 Tung, B., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J., Trostle, J., " Public Key Cryptography for
    Initial Authentication in Kerberos", draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    Page 11 of 12
    Legal Notice
    This Specification is provided to you pursuant to the terms and conditions of the Agreement for
    Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems (the
    "Agreement") for the sole purpose of allowing you to review the Specification for security analysis,
    as further specified in the Agreement. If you have not downloaded the Specification from
    Microsoft's website and agreed to the terms and conditions of the Agreement, you are not an
    authorized licensee of the Specification.
    For your reference, the Agreement is reproduced below.
    Agreement for Microsoft Authorization Data Specification v. 1.0
    for Microsoft Windows 2000 Operating Systems
    IMPORTANT--READ CAREFULLY: This Microsoft Agreement ("Agreement") is a legal agreement between you (either
    an individual or a single entity) and Microsoft Corporation ("Microsoft") for the version of the Microsoft
    specification identified above which you are about to download ("Specification"). BY DOWNLOADING,
    COPYING OR OTHERWISE USING THE SPECIFICATION, YOU AGREE TO BE BOUND BY THE TERMS OF THIS
    AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS OF THIS AGREEMENT, DO NOT DOWNLOAD, COPY, OR USE THE
    SPECIFICATION.
    The Specification is owned by Microsoft or its suppliers and is protected by copyright laws and international
    copyright treaties, as well as other intellectual property laws and treaties.
    1. LICENSE.
    (a) Provided that you comply with all terms and conditions of this Agreement, including without limitation
    subsections (b)-(d) below, Microsoft grants to you the following non-exclusive, worldwide, royalty-free,
    non-transferable, non-sublicenseable license, under any copyrights or trade secrets owned or
    licensable by Microsoft without payment of consideration to unaffiliated third parties, to reproduce
    and use a reasonable number of copies of the Specification in its entirety for the sole purpose of
    reviewing the Specification for security analysis. By way of clarification of the foregoing, the
    Specification is provided to you solely for your informational purposes (for review as specified above)
    and, pursuant to this Agreement, Microsoft does not grant you any right to implement this
    Specification.
    (b) The Specification is confidential information and a trade secret of Microsoft. Therefore, you may not
    disclose the Specification to anyone else (except as specifically allowed below), and you must take
    reasonable security precautions, at least as great as the precautions you take to protect your own
    confidential information, to keep the Specification confidential. If you are an entity, you may disclose
    the Specification to your full-time employees on a need to know basis, provided that you have
    executed appropriate written agreements with your employees sufficient to enable you to comply
    with the terms of this Agreement. You are also permitted to discuss the Specification with anyone else
    who has downloaded the Specification and agreed to these terms and conditions.
    (c) You may not remove any of the copyright notices or other legends from any copy of the
    Specification.
    (d) Microsoft reserves all other rights it may have in the Specification and any intellectual property therein.
    Microsoft may have patents or pending patent applications, trademarks, copyrights, trade secrets or
    other intellectual property rights covering subject matter in the Specification. The furnishing of this
    Specification does not give you any license to these patents, trademarks, trade secrets, copyrights, or
    other intellectual property rights, except as specifically set forth in subsection (a) above with respect
    to certain copyrights and trade secrets.

    Windows 2000 Kerberos Authorization Data April 2000
    © 2000 Microsoft Corporation. All rights reserved. Microsoft Confidential.
    Page 12 of 12
    2. ADDITIONAL LIMITATIONS.
    (a) The foregoing license is applicable only to the version of the Specification which you are about to
    download. It does not apply to any additional versions of or extensions to the Specification.
    (b) Without prejudice to any other rights, Microsoft may terminate this Agreement if you fail to comply
    with its terms and conditions. In such event you must destroy all copies of the Specification in your
    possession or under your control.
    3. INTELLECTUAL PROPERTY RIGHTS. All ownership, title and intellectual property rights in and to the Specification
    are owned by Microsoft or its suppliers.
    4. DISCLAIMER OF WARRANTIES. To the maximum extent permitted by applicable law, Microsoft and its
    suppliers provide the Specification (and all intellectual property therein) AS IS AND WITH ALL FAULTS, and
    hereby disclaim all warranties and conditions, either express, implied or statutory, including, but not limited to,
    any (if any) implied warranties or conditions of merchantability, of fitness for a particular purpose, and of
    accuracy or completeness, all with regard to the Specification and any intellectual property therein. ALSO,
    THERE IS NO WARRANTY OR CONDITION OF TITLE OR NON-INFRINGEMENT WITH REGARD TO THE SPECIFICATION
    AND ANY INTELLECTUAL PROPERTY THEREIN.
    5. EXCLUSION OF DIRECT, INCIDENTAL, CONSEQUENTIAL AND CERTAIN OTHER DAMAGES. TO THE MAXIMUM
    EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY
    DIRECT, SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, BUT NOT
    LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR FOR BUSINESS INTERRUPTION) ARISING OUT OF OR IN ANY WAY
    RELATED TO THE USE OF OR INABILITY TO USE THE SPECIFICATION, ANY INTELLECTUAL PROPERTY THEREIN, OR
    OTHERWISE UNDER OR IN CONNECTION WITH ANY PROVISION OF THIS AGREEMENT, EVEN IF MICROSOFT OR ANY
    SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    6. LIMITATION OF LIABILITY AND REMEDIES. Notwithstanding any damages that you might incur for any reason
    whatsoever, the entire liability of Microsoft and any of its suppliers under any provision of this Agreement and
    your exclusive remedy for all of the foregoing shall be limited to the greater of the amount actually paid by
    you for the Specification or U.S.$5.00. The foregoing limitations, exclusions and disclaimers shall apply to the
    maximum extent permitted by applicable law, even if any remedy fails its essential purpose.
    7. APPLICABLE LAW. This Agreement is governed by the laws of the State of Washington.
    8. ENTIRE AGREEMENT. This Agreement is the entire agreement between you and Microsoft relating to the
    Specification and it supersedes all prior or contemporaneous oral or written communications, proposals and
    representations with respect to the Specification.
  • by troyboy (9890) on Tuesday May 02, 2000 @02:01PM (#1096653)
    I am a law student and do not pretend to be qualified to give legal advice, but I think that the above posts which reveal the "secret" eliminate any basis for Microsoft to call this a trade secret. Once it is in the public, it is not a trade secret.

    A similar case was presented in Religious Technology Center v. Netcom, 923 F. Supp. 1231 (N.D. Cal. 1995), where the judge held that RTC was unlikely to succeed in a trade secret suit against someone who had obtained the documents on USENET. The judge said that "although a work posted to an Internet newsgroup remains accessible to the public for only a limited time, once that trade secret has been released into the public domain there is no retrieving it."

    Now, the poster may be liable for breaching the contract, but it is no longer a trade secret...
  • by Thagg (9904) <thadbeier@gmail.com> on Tuesday May 02, 2000 @11:48AM (#1096654) Journal
    I don't blame you if you missed it during the DeCSS imbroglio, but this is so clear that it is unmistakable.

    A way to get *permanent* protection over an idea or an implementation is to cause the secret to be leaked illegally.

    Then, you sue everybody who implements the idea, at any time in the future, saying that they were inspired, or at least tainted, by the illegal release of the information. Trade secret laws do not allow the use of a secret if 'sufficient protections are taken'.

    Previously, I had thought that a company would need a shill to do the publication of the secret; which is of course dangerous if the shill squeals. Microsoft has shown their ability to innovate here; publishing it as a secret sure to be 'improperly' released is a much better scheme.

    thad

  • by Sloppy (14984) on Tuesday May 02, 2000 @11:37AM (#1096655) Homepage Journal

    I did NOT agree (nor did I even SEE) the license, and I now have access to the .pdf file. I will give copies of the .pdf file to anyone who asks, its public domain as far as I'm concerned.

    Surely you jest. If failing to read a license causes me not to be bound by it, then maybe I'll just download the Linux kernel code, ignore the license, and call it public domain. Then, if it's public domain (and no longer GPLed), I can compile it and distribute binaries without source.

    The license exists, and not reading it has no effect on whether you are licensed or not.

    The power of the license, on the other hand, is quite debatable.


    ---
  • Does this hamper legitimate reverse-engineering of the product?

    No more than IBM hampered Compaq from reverse-engineering the original IBM-PC BIOS back in '83.

    IBM actively published the BIOS specifications for exactly the reason you state -- it made it improbably that anyone technically capable of reverse-engineering it had not been exposed to the "trade secret". They thought it would make bulletproof legal protection.

    Compaq had to search wide and far to find a team of engineeres who could swear they had never seen or heard anything about the BIOS "trade secrets". They locked them in a room with a black box version of the IBM-PC, and a second team "outside the room" (since they had been exposed to the trade secrets) would tell them whether they were hot or cold. They reverse-engineered it in one of the most important feats of the computer age.

    And they kept detailed logs & journals of every step along the way so that they could prove beyond a doubt that they had succeeded in reverse-engineering the BIOS without seeing the published "secrets".

    This may be, alas, further proof of Microsoft's fall -- they truly are becoming like IBM was back then, using tricks and traps to protect themselves rather than building a better mousetrap.

    What's sad is that MS, Compaq, et al -- who would not exist without that single feat of engineering -- are more than happy to support laws that would prevent it from happening again (DMCA, etc).
  • by iCEBaLM (34905) <icebalm AT icebalm DOT com> on Tuesday May 02, 2000 @10:52AM (#1096657)
    1. Download the evaluation copy of winzip [winzip.com] if you don't already have it.

    2. Download the dumb exe thing.

    3. Open Winzip, and then open the exe WITH WINZIP.

    4. Extract the PDF without agreeing to the license.

    This is what I have done, I did NOT agree (nor did I even SEE) the license, and I now have access to the .pdf file. I will give copies of the .pdf file to anyone who asks, its public domain as far as I'm concerned.

    -- iCEBaLM
  • by tytso (63275) on Tuesday May 02, 2000 @12:47PM (#1096658) Homepage

    The legal problem with what they're doing is that they're deliberately making their software non-interoperable with published standards. This seems to indicate that they're trying to use their monopoly position to exclude competition, which is illegal.

    Yes, that's it in a nutshell. The game here is that they're trying to use their monopoly in the desktop space to dislodge Unix in the server market. One of the ways they do this is by making the Windows 2000 PDC "look" like it embraces open standards, so that the I/T departments in Fortune 500 departments (which up until now have very often used Unix/Linux systems in their back offices) think that using Windows servers, and the Windows 2000 PDC in particular, is mostly harmless.

    But the Windows 2000 clients have been architected so that you only get a bunch of cool features if you use their propietary protocol extensions. So it's clear that Microsoft is trying to create a monopoly situation with the Windows 2000 PDC, and once they control enough of the servers, they'll have an even tighter lock on the client market, and vice versa.

    In my opinion, the DOJ really should have proposed splitting Microsoft's OS operations into a Client OS company and a Server OS company, in addition to splitting away the Office operations. Unfortunately, given that they've already submitted their proposal, it may be too late to fix things. Simply splitting the Office group away isn't going to stop Microsoft from playing dirty tricks in the client/server OS space, just as they've done here.

  • by ka9dgx (72702) on Tuesday May 02, 2000 @11:52AM (#1096659) Homepage Journal
    http://warot.com/freedom/kerbspec.pdf [warot.com]
    What happens now?
    --Mike--
  • by RickyRay (73033) on Tuesday May 02, 2000 @12:12PM (#1096660)
    Seems to me like we could eliminate the entire issue by convincing the official maintainers of Kerberos to give an official use for the byte M$ took over (in the next release). Then the only way M$ would be able to remain compliant with the spec is to remove their proprietary addon.
  • by Greyfox (87712) on Tuesday May 02, 2000 @10:42AM (#1096661) Homepage Journal
    If they're not conformant with a open and trademarked standard, they should not be allowed to say they are. Actually, even if it's not trademarked, I wonder if you could sue them for fraudulently misleading the customer into believing the OS will work seamlessly in their existing Kerberos network.
  • by Ephro (90347) <ephlind@yahoo.com> on Tuesday May 02, 2000 @01:22PM (#1096662)
    Trade secrets MUST have the following conditions met to be held up in court as a trade secret:
    1) have novelty
    2) represent an economic investment to the claimant
    3) have involved some effort in development
    4) the company must show that it made some effort to keep the information a secret

    In addion to this, although it is not legal to use redistribute trade secrets, the general knowledge that is learned through things that are held under trade secrecy CAN be used in the future. Another point to remember is that if something is held under trade secret copyright and patent laws DO NOT apply. It is debatable in this case whether the company tried to keep it a secret (documents downloaded by hackers have fallen under trade secret laws, but because they were not secured enough so a hacker couldn't get access the hacker has been determined to not be liable for any damages.) Also any country where there are not trade secrecy laws could download this and redistribute it. Once a trade secret is not a secret it falls into public domain.

    Some information gathered from Computer Ethics, Deborah G. Johnson, 1994.

  • by GNUs-Not-Good (130016) on Tuesday May 02, 2000 @10:47AM (#1096663)
    to keep it secret. Put the pdf file on an IIS server. No one will find it there because there are no IIS exploits.

C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341]

Working...