Kerberos, PACs And Microsoft's Dirty Tricks 417
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.
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
"
Re:Loophole? (Score:2)
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.
Re:Loophole? (Score:2)
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?
Re:Trade Secrets only as long as they're secret... (Score:2)
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.
Re:Ignore W2K!! (Score:2)
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
Re:Is "Kerberos" trademarked? (Score:2)
--
Re:can this be bypassed? (Score:2)
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.
--
Re:The license is still all over the damn thing (Score:2)
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:
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.
So what's the catch ? (Score:2)
Use M$ Word (Score:2)
Reassemble everything, and you have sources that were published by MicroSoft's own incompetence in a way they can't blame you.
Re:The license is still all over the damn thing (Score:2)
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...)
Re:Defeating Trade Secrets 101: (Score:2)
IANAL, but: This issue is muddy because nobody really knows what the legal position is. There are essentially two possible cases:
Re:Defeating Trade Secrets 101: (Score:2)
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.
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.
Re:Defeating Trade Secrets 101: (Score:2)
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.
Re:Defeating Trade Secrets 101: (Score:2)
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,
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).
Re:Defeating Trade Secrets 101: (Score:2)
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.
Re:Full text (Score:2)
Note that that strategy of posting your comments from different IP addresses every time is not helping you any more to remain anonymous.
Re:Why anyone cares (Score:2)
> 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.
Re:Is "Kerberos" trademarked? (Score:2)
> 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.
RevEng Proof, reasonability etc. (Score:2)
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
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?
Re:Defeating Trade Secrets 101 (Score:2)
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".
Trade Secrets only as long as they're secret... (Score:2)
On the other hand, what's the big deal? If no one uses Microsoft's extensions, it's a non-issue.
Re:Full text (Score:2)
again, IANAL.
Re:Please moderate the previous post down! (Score:2)
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.
Re:Defeating Trade Secrets 101: (Score:2)
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.
--
Jail Gates (Score:2)
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.
--
Re:what's the fud'din difference? (Score:2)
That's what MS is up to. They're offering you the recipie so that they can advertise (falsely) "lemon pie, with recipie".
Doesn't matter. (Score:2)
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.
Re:It's just proof (Score:2)
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
SAMBA in binary. (Score:2)
... but remember, I'm no lawyer.
Re:The answer is simple (Score:2)
Re:Defeating Trade Secrets 101: (Score:2)
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.
Re:It's just proof (Score:2)
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.
Please moderate the previous post down! (Score:2)
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.
Re:Loophole? (Score:2)
So thanks, Microsoft, but no thanks.
Re:How to bypass the pop-up (Score:2)
;-)
--
Question for the Lawyers... (Score:2)
---
And they can probably prove it if you do... (Score:2)
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.
Re:Defeating Trade Secrets 101: (Score:2)
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:
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
Re:Dirty trick.. or just a lapse? Or really dirty? (Score:2)
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.
--
Re:It's just proof (Score:2)
Innovation isn't the kind of thing you want to rush.
--
Re:Full text (Score:2)
Re:Workaround not requiring copyright violations (Score:2)
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.
Re:Bill (Score:2)
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?
I have to wonder.. (Score:2)
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'
Re:Defeating Trade Secrets 101: (Score:2)
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'.
Re:hello (Score:2)
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
Re:can this be bypassed? (Score:2)
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.
--
Re:hello (Score:2)
Re:can this be bypassed? (Score:2)
Actually, the GPL violations in China do not interest me much either - anyone there who really wants the sources could probable get them anyway.
Re:Kerberos? Isn't it Cerebus? (Score:2)
Re:Is "Kerberos" trademarked? (Score:3)
hello (Score:3)
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/kerbero
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)
} 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)
} 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
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.
Re:So what happens if... (Score:3)
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.
Logic flaw (Score:3)
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.
--
Re:Loophole? (Score:3)
Re:Is "Kerberos" trademarked? (Score:3)
> 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.
Re:Is "Kerberos" trademarked? (Score:3)
> (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.
Heh, I like this. Get some teens on it! (Score:3)
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.
Re:Full text (Score:3)
Yes we do. With a +2 rating.
The fud'din difference... (Score:3)
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.
---
Get around the license ... ? (Score:3)
Re:Defeating Trade Secrets 101: (Score:3)
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.
can this be bypassed? (Score:3)
The GPL (for instance) is routinely ignored in China so China would seem be another good candidate.
Does this hamper legitimate reverse-engineering? (Score:3)
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.
--
Re:Dirty trick.. or just a lapse? Or really dirty? (Score:3)
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.
kerberos.pdf unzipped and unlicensed! (Score:3)
You're wish has been granted: kerberos.pdf [free-dvd.org.lu]
Kerberos.pdf unzipped, unfeathered and unencumberd (Score:3)
Why does this rule out a competing implementation? (Score:3)
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.
Re:Full text (Score:3)
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
Why circumvent the license..... (Score:3)
Oh (Score:3)
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.
Re:Kerberos? Isn't it Cerebus? (Score:3)
"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.
Lawyer-judo (Score:3)
Yes! Embrace and extend Microsoft! (Score:4)
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
Posting the data is all well and good, but.... (Score:4)
Ignore Microsoft's release, don't break license (Score:4)
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.
Microsoft Instant Messenger (Score:4)
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.
The license is still all over the damn thing (Score:4)
Extracting it from the cab file doesn't do you any good. It certainly doesn't let you bypass the license.
Loophole? (Score:4)
Well hrm....what if I
Or less crazy, what if the precautions I
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
The freedom to innovate (Score:4)
Trade secret == open season (Score:4)
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
Trade secrets are a poor form of "security".
Not for interoperability! (Score:4)
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...
Re:Seriously... (Score:4)
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]:
(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.)
Ahhhh.... (Score:4)
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
Re:Is "Kerberos" trademarked? (Score:4)
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.
It's just a CAB file (Score:4)
Will scrutiny of MS ever work? (Score:4)
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
Double Blind Reverse Engineer (Score:4)
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.
Full text (Score:5)
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/kerbero
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
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.
Not a trade secret (Score:5)
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...
Better than a patent (Score:5)
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
Re:Defeating Trade Secrets 101: (Score:5)
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.
---
Re:Does this hamper legitimate reverse-engineering (Score:5)
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).
Defeating Trade Secrets 101: (Score:5)
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
-- iCEBaLM
Re:Did Micro$oft have to do this. (Score:5)
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.
Re:Loophole? (Score:5)
What happens now?
--Mike--
Re:Loophole? (Score:5)
Is "Kerberos" trademarked? (Score:5)
Re:Defeating Trade Secrets 101: (Score:5)
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.
An easy way... (Score:5)