Slashdot Log In
Proprietary Extension to Kerberos in W2K
Posted by
emmett
on Thu Mar 02, 2000 10:59 AM
from the surprise-surprise dept.
from the surprise-surprise dept.
st.n. writes "Heise News is
reporting
that Microsoft made its own proprietary extension (and incompatibility)
to the Kerberos authentication protocol, which was developed at MIT as
an open standard. Supposedly a W2K client will only work with a W2K
server, not any other kerberos server, because MS uses a yet unused data
field and the W2K client relies on that field being present. For those
of you who don't speak German, I found it also at
Yahoo."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
ZDnet had this story a few days ago. (Score:2)
Re: "proprietary" trade secret (Score:2)
I am not a lawyer. I do not actually know American law. This is just a bunch of uneducated guesses.
That sucks hard. (Score:2)
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
Reverse engineer? (Score:2)
IIRC, doesn't Australia (and possible elsewhere) speicifically allow reverse engineering to mainting interopribility (or somesuch)?
Do the reverse-engineering in the US, or wherever, and get an Aussie friend to publish the results on an Australian web server.
What, you mean the rest of the world can see that web server? Oh well, too bad...
...j
Why Stallman created the GPL (Score:2)
MIT (as well as every other educational institution) should release all code under the GPL, or similar licenses with protection against proprietary extensions.
False Advertising (Score:2)
Kerberos is a well defined standard. If they misimplemented it in such a way that their product will not interoperate with existing Kerberos domains, then they didn't implement Kerberos.
If Microsoft chooses to lie to their customers, no amount of IP whining is going to help--oh, unless this UCITA thing happens to pass...oh.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
Re:legal? (Score:2)
Re:Apparrently Microsoft disagrees (correctly) (Score:2)
> admits of a nasty race condition, where a second
> user uses a first user's workstation token to
> get at his or her user ACL entry.
Huh ? This doesn't make sense. All the packets used in kerberos are integrity and privacy protected. The scenario you describe is simply not possible. Also, there is no such thing as a 'workstation token'. Kerberos principals are users and services, not machines.
The "MS hack", as you describe it, has *nothing* to do with any potential race conditions in DCE.
I would suggest reading "Network Security", by Perlman, Kaufman and Spencer for an excellent introduction to these topics.
Regards,
Jeremy Allison,
Samba Team.
Re:Win2K Kerberos (Score:2)
Every time I ask (and I've asked *many* times, publically as well as privately) Microsoft have said "yes we are committed to documenting this". I believe them. I just want to *see* the documentation first....
Regards,
Jeremy Allison,
Samba Team.
Re:And this is surprising because...? (Score:2)
That sentence lends itself to another reading, which is that it's in MS's interest not to interoperate with anyone else's stuff, except at a minimal level insofar as you need to (say) speak TCP/IP. This is the same sort of thinking that helped IBM sew up 90+% of the mainframe market well into the 70's, and earned them (a) widespread enmity from customers and competitors, (b) a federal antitrust investigation, and (c) carte blanche to unilaterally carry the state of the art in whatever direction they wished. There's a gray area between intentional incompatibility and actual anticompetitive behavior when you have the market share IBM did then (or Microsoft does now).
If they really care about increasing the utility of technology in the larger sense, which I'd argue they must if they know what's good for them long-term, they should participate reasonably in standards definition processes. I know that a lot of what you decry as "interorganizational posturing" involves companies being inflexible on just these sorts of issues, and that Microsoft is as bad an offender as any--when they deign to participate at all.
Anecdote: My friend was the Lucent delegate to an IETF Working Group. For three consecutive meetings no work at all was completed, because every time the Microsoft rep opened his mouth it was to say "I move that the entire text of the proposed section be stricken and replaced with: 'Bla bla bla....'." That is not what I would call playing well with others.
I am not a blindly Microsoft-hating zealot. I do take exception to many of their business practices.
Re:This was discussed on NTBugTraq (Score:2)
Ha ha, trolling, I like that. In fact the only way I ever caught fish was by trolling, but I digress. Yes it doesn't pertain directly to the issue, however I felt it did provide some information regarding Kerberos, so indirectly it helped. Howver I did fail to post all the links at the end of the message, which do mention more of the Kerberos issue. Here they are, if any are interested:
The DNSEXT working group home page [ietf.org]RFC 2065 [ietf.org]
RFC 2137 [ietf.org]
RFC 2535 [ietf.org]
Secret Key Transaction Authentication for DNS (TSIG) [ietf.org]
Secret Key Establishment for DNS (TKEY RR) [ietf.org]
GSS Algorithm for TSIG (GSS-TSIG) [ietf.org]
White paper on Kerberos interoperability [microsoft.com]
Press release on Kerberos interoperability [microsoft.com]
S imple Secure Domain Name System (DNS) Dynamic Update [ietf.org]
Re:sigh... here we go again. (Score:2)
I had the same kind of questions last month. It lead to an essay [wgz.org] called "Barbarians in the Library" [wgz.org].
The gist of my argument is that, if open standards and protocols benefit any one person or organization more than that person or organization contributes to everyone else (as is the case for pretty much everybody!), perhaps removing those benefits will help convince a rogue organization to stop trying to embrace, extend, deform, and extinguish those standards and protocols. It would be nice to get some suggestions and critiques and comments on it. :)
--
MIT uses NT source code to fix it (Score:2)
MIT has campus computing labs with solaris and
IRIX. To get future NT client to work with the
existing Kerberos Authentication server, they
are forced to modify NT source code.
(Part of project Pismere http://web.mit.edu/pismere/)
They will also have NT mount user home
directories off of the Andrew File System (AFS).
Re:License Kerebros (Score:2)
No, it's actually the other way around. Windows clients could get their connections to printers and files refused because of this. Kerebros is supposed to authenticate once, and the let you have access to all resources you have permission to, without continually reauthenticating. However, It'll end up that Windows clients will only have access to resources on Windows servers. So you can't have Samba running as your server. Microsoft profusely apologizes for the inconvinience. (Yeah, right!)
-BrentRe:Better standards (Score:2)
Why can GNU call their version of a standard "make", even though it has numerous incompatible extensions, but Microsoft is not allowed to call their version of Kerberos by the name of "Kerberos", even though it has far fewer extensions and incompatibilities than does GNU Make?
LDAP? (Score:2)
Is their LDAP....er, I mean Active Directory, implementation compatable within a standard LDAP environment, or did they "customize" it as well?
Re:legal? (Score:2)
I thought pretty much any Win32 app other than games would run on Win2k fine, is that not true?
according to Microsoft... (Score:2)
The MS droid mostly skipped security but spent quite some time on Kerberos. He insisted the MS Kerberos was fully compatible. He even said (translation from Dutch): "the implementation was clean of incompatible Microsoft additions".
According to him the use of the extra field was according to RFC 1510 and would work with all other clients and servers.
This is true (Score:2)
An MS plugin for Netscape [microsoft.com] exists, if you're running Netscape on a system which is compatible with the plugin.
Actually, even Exchange Server has problems [microsoft.com] if not running on same server as IIS.
yeah (Score:2)
Re:Yes and No.... (Score:2)
When your kid brother punches you, that's annoying.
When an 800lb gorilla punches you, that's evil. (because unless you figure out a way to soften the blow, you're dead)
--
Re:Totally off topic (Score:2)
Personally, I happen to think it's funny as hell.. and if I had any mod points left, I'd moderate it up as such.
Re:And this is surprising because...? (Score:2)
Re:And this is surprising because...? (Score:2)
Regardless, it really ins't microsoft's job to ensure compatability with anyone but themselves. How many vendors will authenticate users for a VMS system? When you have a different paradigm it is often useless and futile to try and maintain 100% compatability with every little OS under the sun. Really documentation is the only issue here.
Re:LDAP? (Score:2)
Paul.
Re:I still say... (Score:2)
They should be made to stick to standards, or to submit their ideas into the standard. There should be some kind of "Open Standards Licence", like the GPL, so that if you take a standard and make some changes to it, you have to release the changed to that standard.
Copyleft patent license (Score:2)
Of course, that might not have helped either; maybe they'd just have opted for something entirely different.
Clarification (Score:2)
This simply means that only W2K can talk Kerberos with W2K servers. It doesn't mean W2K cannot talk to other OSes. The other implementations will just disregard the field. However, if you are attempting to integrate any other systems with W2K server, you are SOL, and apparently Microsoft wants to force you to buy W2K.
Obviously Kerberos is not implemented in W2k (Score:2)
It's enough that ONE business successfully sues MS even if it's only for some K$ worth of unscheduled downtime and worktime needed to 'fix' this 'feature'.
Re:Apparrently Microsoft disagrees (correctly) (Score:3)
MS-Extensions. - This is the vendor data that is allowed as part of the spec. Same place the IBM/Transarc/SecurityDynamics/Entrust/etc put there propriatory data.
3. Won't talk to other Kerb'5 boxes. BULLSHIT on client and server.
4. No real interobrility. If you don't read the damn docs and keep your head up your a**. otherwise it works like this:
Unix Realm MitK5 manual secured vpn type link Win2000 KDC Win2000 AD -> backlevel NT4 domains.
if you want you NT4 box to Authenticate in Unix kerb5 go right ahead. The user ticket will be fine on a trusted NT based kerb realm. same goes true in reverse.
What you lose. Same problems as with all -legal-but-not-required things; no matters who extension it is one side can't process the vendor data. Solve the problem by static mapping trusted and untrusted principles in the kerb realms. It can be a pain and is really only a small scale fix. Same as the other K5 vendors solutions.
no, ou can't make a host part of two realms at once. this is true on all kerb versions
silver-lineing. The K4 world sucked and K% suckes less. The problems of the vendor data have been ignored by most vendors (hello IBM) untill MS starting showing code to the Win2000 Kerb modules and working with MIT and the standards group to get the vendor spec closed. No one wan't to say the MS-Kerb is spec clean and that they aren't. hence the recent intrest other vendors have displayed about joining in cleaning up kerb5
btw, there is a big bug in cross-realm auth that is (hopefully) fixed in sp1 (eta march-april). It hits Win2k to Win2k just as well
It might be a legitimate use? (Score:3)
Apparrently Microsoft disagrees (Score:3)
This really CHAPs my ass! (Score:3)
I've had to fight Microsofts CHAP implementation in the past. At a prior company I worked I used to have to dial in to support our EDI software(24 hour support, but seldom needed to call in). I used my OS/2 system to access our AS/400. For some reason they changed our dial-up hardware to NT and all of a sudden I was no longer able to dial in.
I eventually tracked it down to the MS version of CHAP not liking my standard CHAP routines. They wouldn't change the settings to accept standard CHAP as "it would make the system less secure". They didn't like my question of "If 90% of the systems are using Windows, then how does MS-CHAP make it more secure?"
I refused to change my home system to Windows due to work requirements(what I use on my own time is my choice, not theirs). For a few months I didn't provide support from home until I stumbled across a new PPP dialer, Injoy [www.fx.dk], that had MS-CHAP support.
Extend and embrace? (Score:3)
Heh. Don't get too worried: we've got 'em under control. Be happy they're using the core of kerberos so it won't be hard to detect and fix the changes they made.
Ah, the irony... (Score:3)
Does anyone else see the irony here? MS-Kerberos forces Win2k clients to use a Win2k server...
Kerberos keeps the damned in Hades. Film at eleven.
Re:sigh... here we go again. (Score:3)
Microsoft throwing a bunch of crud into open protocols, cluttering up the procotol JUST so they can put their names on it, say "look! microsoft did something in creating this standard!" Microsoft does not do extend these things to get a technical benefit from the extention; they do it to show people who's boss, to point out that MIT, the linux community, et all, is NOT in control here; this is MICROSOFT'S world, not theirs, and if they think that a community decision is going to be allowed to dictate what happens, then they have another thing coming. And, of course, in the process of extending, they propeitarize, which directly hurts the community currently using the protocol because it means that for a longish while, the original supporters of the protocol will be unable to adapt their software to be operable with microsoft's supporters; and even after the original supporters support microsoft's extention, the way they do this will more than likely be reverse-engineered and highly dodgy (*cough *cough *SAMBA* cough*).
We don't really want microsoft to stop extending; more importantly what we want is microsoft to design their extentions to the standards in such a way as to ENCOURAGE INEROPABILITY. If you are going to be extending a standard, this is not evil in itself; if you are going to add something to the standard in order to get some kind of feature or benefit that you would not get without the extention, this is almost certainly a good thing. But if whatever is on the other side of the protocol from you does not comply with your extention, the result should be that neither side benefits from the presense of the extention. The result should NOT be interopability. All recent extendable standards i can think of-- HTML being the first to come to mind-- attempt to stress methods by which failure by both ends to support the same extention results in the extention not being used, NOT in the standard becoming nonfunctinonal between the two sides.
a better way to phrase the original question, i think, woudl be: How do we get the media, the public, and everything to the point where microsoft can no longer get away with doing this? Microsoft does not neccicarily need to be stopped in this respect; but what needs to happen is people need to be _aware_ that microsoft is doing this; that microsoft is purposefully breaking functionality in a product _they paid for_ in a situation where that functionality that could have easily be retained. People need to begin asking themselves the question of why microsoft is doing this. People need to be aware of the extent to which microsoft wants everything propeitary to them. If people in general were aware of what was going on, and more importantly UNDERSTOOD it, they would almost certainly disapprove; but instead we wind up with the people (who probably never go to anything requiring more authentication than My Yahoo) just going, "Kerberos? Huh?". You think "propeitary" is even in most people's vocabulary?
I apologize if my writing here is somewhat unwieldy. I've had a bad day.
-mcc-baka
MIT-MAGIC-COOKIE-1. PH33R.
You can access unix/linux, but.... (Score:3)
Microsoft used the semi-documented (but not in the official spec) data authorization field in the kerberos ticket to their own purposes and refuses to tell anyone what they did.
By the way ... (Score:3)
---
UCITA test? (Score:3)
I get the distinct impression that the word "interoperability" has a different definition for MS... basically:
"All of MS's products work with MS products... how much more do you want?
The best part! (Score:3)
Its retarded, It still relies on the old screwed up MS Security junk, which is *STILL* compatible with the ancient LanMan authentication. Something that is still easily crackable. Don't throw away that old L0phtcrack yet, there is still use for it.
About the only good thing about Win2k is that you don't *HAVE* to reboot for the almost 100 things you used to have to, now its just like 10-15 things that you do. And that its got IPSec built in, but apparently you still need to have a Win2k Cert server for that to work, so its the same old story. *sigh*
Better standards (Score:3)
Stadnards could be written in such a way that any extended features must be requested before thier use. If they aren't available, then the client / server MUST continue without the use of that extended feature.
This would eliminate incompatabilities like this, since any closed (or otherwise) implementation that doesn't function without a certain extended feature could not claim to conform to the standard. At this point micros~1 could not claim they've got an 'enhanced implementation of standard X' when their version is incompatable with everyone else's. They could only claim to have an 'incomplete implementation of standard X'. The key is placing portability implicitly in the standard.
---
script-fu: hash bang slash bin bash
More info available... (Score:4)
Re:sigh... here we go again. (Score:4)
What exactly do you want to stop? If you want to stop Microsoft from extending standards, then your only recourse to to make those standards proprietary. Even if Kerberos were under the GPL, Microsoft could still add an extension to it and release the modifications back. But there would STILL be an extension to Kerberos! It would then be up to the Kerberos team to incorporate the Microsoft extensions or not. Only by disallowing modifications can this be stopped.
But the Kerberos license is unrestricted, and not copyleft. Their goal was to get Kerberos used as widely as possible. W2K with Kerberos extensions is much more compatible than W2K with no Kerberos at all.
This is obviously an attempt to break Samba (Score:5)
"[Windows 2000 product manager] Boettcher added that both Unix workstations and Win2000 desktops may log in to the Win2000 server. But Win2000 desktops cannot log in to a Unix Kerberos server and receive access to Win2000 resources such as file and print, he said."
Every new release of Windows NT to date has added "extensions" to SMB designed to prevent third party vendors from acting as SMB servers. Since Samba is a better SMB implementation than Micro$oft's, obviously MICROS~1 marketing were afraid Samba was cutting into NT Server sales. Hence this transparent attempt to render Samba worthless for Win2K clients.
The only credible response to this is a complete boycott of Win2K until Microshaft provides the Samba development team with the information they need to make Samba interoperate with Win2K clients.
Re:Apparrently Microsoft disagrees (correctly) (Score:5)
Yep. The O'Reilly book, "DCE Security Programming" by Wei Hu, ISBN 1-56592-134-8 (just don't buy it from Amazon
Page 37, section entitled "How PAC's are used" explains how a standard Kerb5 TGT is obtained, then a ticket to the privillage service is obtained, then a second TGT (called a PTGT) is obtained from the privillage service. This PTGT contains the authorisation data (user and groups in the form of DCE UUIDs) stored in the "application data" field.
It was done this way so a *standard* kerb5 server could be used as a authentication source, with a secondary server used as an *authorization* source.
Microsoft could have done the same. They didn't, but modified the Kerb5 KDC directly and put authorization data into the TGT. That's what the fuss is about.
Regards,
Jeremy Allison,
Samba Team.
Re:Apparrently Microsoft disagrees (correctly) (Score:5)
> allowed as part of the spec. Same place the
> IBM/Transarc/SecurityDynamics/Entrust/etc put
> there propriatory data.
This is incorrect. The DCE PAC's are created by first getting a *standard* TGT from a Kerb5 KDC, then using that to get an additional TGT containing the PAC. Microsoft could have done the same. They chose not to. That is what people are objecting to.
Regards,
Jeremy Allison,
Samba Team.
This was discussed on NTBugTraq (Score:5)
When RFC 2137 "Secure Domain Name System Dynamic Update" was written, it was
based on the then-current DNSSEC spec, RFC 2065 "Domain Name Security
Extensions". RFC 2535, a re-write of DNSSEC based on implementation and
deployment experience, obsoletes RFC 2065. A side-effect of the deprecation
of RFC 2065 is the invalidation of RFC 2137. RFC 2137 is not safe for
implementation.
Upshot: there is no IETF standard for DNS secure dynamic update.
Two years ago we had to make a call on whether or not we should implement
DNSSEC (RFC 2065) in Windows 2000. DNSSEC - which is a public key
infrastructure unto itself - is very complex. In our judgment, at the time,
it was not ready for implementation and deployment. It followed that RFC
2137 was also not ready for implementation and deployment.
Still, we needed a solution for secure dynamic update. As it happened, the
DNSIND working group in the IETF had already recognized that DNSSEC was not
appropriate in all situations, and that there was a demand for a lightweight
(shared secret) alternative. Two complementary Internet-Drafts were
published to satisfy this requirement: "Secret Key Transaction
Authentication for DNS (TSIG)", and "Secret Key Establishment for DNS (TKEY
RR)".
TSIG and TKEY alone do not solve the key distribution problem inherent in
any secret key system. However, both mechanisms allow for extension, which
permitted us to publish a third complementary draft, "GSS Algorithm for TSIG
(GSS-TSIG)". The GSS-API mechanism enables us to use integrated Windows
security to solve the key distribution problem, and ensure our customers
will have no additional key management burden associated with secure update.
The GSS-TSIG draft has been available since November of 1997. Microsoft
would be happy to assist any vendors who wish to develop an independent,
interoperable implementation. We have already demonstrated GSS-API/Kerberos
interoperability between Windows 2000 and other GSS/Kerberos implementations
(see below for more information).
The DNSEXT working group (a consolidation of the DNSIND and DNSSEC working
groups) is currently working on an Internet-Draft to replace RFC 2137. This
draft, called "Simple Secure Domain Name System (DNS) Dynamic Update",
separates the authentication of an update from the later DNSSEC
authentication of the data. The draft acknowledges the TSIG/TKEY method as
a way to authenticate updates. When TSIG, TKEY, GSS-TSIG, and Simple Secure
Dynamic Update reach standard status, there will be an IETF standard for DNS
secure dynamic update.
Microsoft is continuing to evaluate the viability of and demand for
DNSSEC/public key-based security for DNS.
Note especially the third paragraph from the end, where MS will gladly 'help' you write a standard
Cheers
Yes and No.... (Score:5)
Actually, MS's implimentation interoperates to a certain degree with the reference MIT one. The difference that people are pointing out is that MS implimented one of the "optional" features that the reference implimentation doesn't.
Now, this is good and bad. What it means is that MS clients can authorize to an MIT-based server's realm, and that UNIX clients can authorize to a MS-based realm, though you really need to run an MS server as the "native" realm for the MS clients, in order to have this extra field for the MS clients to use. I think they use it for something in Active Directory, but I'm not sure.
It is MS being their usual "we work with them (almost)" self, but in this case, they're not hiding anything. They just happen to use more of the spec than the reference one.
There's nothing keeping someone from taking the MIT software and adding the optional feature that MS uses. In fact, it's not hard to do (we once looked at doing exactly this). IASMOP (It's A Simple Matter Of Programming). The hitch is that you have an installed base that needs to be upgraded, which is kinda a bummer.
And no, this isn't new. I found out about this almost 2 years ago.
Nothing Evil about this, just annoying.
-Erik
More information (Score:5)
In a nutshell, Kerberos is a *network* authentication mechanism, not a system authentication mechanism. That means that when John Smith sits down at his terminal and acquires a Kerberos ticket, it's validated against a central site *with no cross-reference to local information.*
In an ideal world, the principal name and local user name would be identical. The local system could then look up the principal name in its local user database and acquire user information from
Other alternatives are getting that information out of NIS, LDAP, etc., or Kerberos-enhanced versions of the same if they're paranoid about someone trying to spoof that information.
(AFAIK) what MS did with W2Kerberos is put the equivalence of
However, for reasons that make no sense to anyone in this reality they decided to digitally sign that information. From a security standpoint, this is utterly insane - Kerberos tickets already use strong encryption and session keys, so there's nothing to be gained by adding an additional layer of encryption to the payload. Furthermore, the KDC should be physically and electronically secured, so it should not be a significant risk to maintain unsigned user authority information on the KDC in plaintext. Assuming you don't simply colocate those services, of course!
However, digitally signing that data and failing to disclose the details is an excellent way to control market share, if the user community doesn't rip their head off for this trick. In this case it's a possibility since the sites that use Kerberos are more security-aware than your average site, and they might not be willing to compromise their security by maintaining two realms (or worse, replacing their Unix KDCs with Windows KDCs).
Totally off topic (Score:5)