Proprietary Extension to Kerberos in W2K 248
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."
Re:Apparrently Microsoft disagrees (correctly) (Score:1)
http://www.opengroup.org/pubs/catalog/c311.htm
http://www.opengroup.org/dce/download/
Re:And this is surprising because...? (Score:1)
Indeed. All those meetings of the C Standards committee that the GCC maintainers ignore and/or boycott... It just wouldn't do to waste time at meetings when there's embracing and extending of the C language to be working on. (non compatible 'features' of GCC, that aren't even reported with the 'ansi' and 'pedantic' switches on, which causes programmers to write C code for GCC that won't build on any other compiler)
And the Bash shell... which purports to be backwards compatible with the POSIX standard for
Yep. It's a big cruel world out there. And the GNU and the Microsoft "embracers and extenders" are at it again...
More articles (in english) (Score:1)
Re:UCITA test? (Score:1)
The Microsoft Dictionary
interoperability: The ability of a Microsoft product to operate with another Microsoft product.
multi-platform: Works with both Windows NT Workstation and Windows 2000 Professional.
Standards: The way Microsoft does something. However if you do it the same way we will sue you.
legacy: Any product that competes with a Microsoft product or a Microsoft produt that a newer version is available or planned.
Security: Asks for a password. Example: Windows 95 has a high level of security because it asks for a password.
Monopoly: Unknown.
Re: "proprietary" trade secret (Score:1)
What can we do? (Score:1)
We aren't talking about some application that does something differently than everyone else, we're talking about messing with a standard to gain and maintin control of the market.
I just can't beleive this is ethically or legally right. What can we do to deal with this ongoing problem with Microsoft? Class action lawsuit? What are our options?
Brandon Petersen
Don't worry this is already happening... (Score:1)
Unless there's a timebomb in SP6a, we're not likely to change the NT servers to 1900 anytime soon. Anyway, dual P333/256Mb RAM may probably not be enough to cope with the 1900 OS overhead....
Us changing the server to Linux probably has a higher chance than betting on us going for win1900.
Actually, the same happened with 3.51 .... took us some time to decide NT4 was safe enuf... and then we regretted the change for some time :-) Not likely we'll do the same mistake twice!
---
And this is surprising because...? (Score:1)
Bah.
Re:And this is surprising because...? (Score:1)
Well, that's what standards bodies are for. You have to realize that the IETF (and other standards bodies) committees aren't just composed of some sort of godlike beings who hand down edicts, they're composed of people from the various companies that actually implement the standards. So if MS really has a beef with a standard that they want changed, they should take it up with the standards body and get their modifications documented.
Stupid... (Score:1)
Microsoft shows its commitment to embracing and extending open standards once again. Let's see what new and wonderful ideas they don't share with the people working on LDAP, Directory Protocols, etc., etc.
My only reassuring thought is that Microsoft couldn't secure a paper bag, so their implementation of Kerberos should be humorous, at least.
---
pb Reply or e-mail; don't vaguely moderate [152.7.41.11].
Re:Apparrently Microsoft disagrees (Score:1)
Well in my experiance, beliveing MS makes you feel like a sucker later.
-Peace
Dave
Translation.. (Score:1)
What this really means:
"We conducted a think-tank session that included the brightest minds in Microsoft Research Labs, including the famous team that invented the sybbloic link just in time for Windows2000. It was determined that patch-build-1,234,567 broke when we tried to implemt it becuase of inconsistencies between patch-122,239, and patch 569,496, which were, consequently patches for patch 1223,456, which patched patch 22,134. Surely this standard is wrong."
nnnext:
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)"."
This one is not as funny. Seems like they use IETF protocol protocol and process to their advantage, fulfilling process requirements while breaking the spirit of the guidelines.
nnnext:
"Microsoft would be happy to assist any vendors who wish to develop an independent, interoperable implementation."
No doubt. Maybe that's why your draft has been in since 1997 and noone outside of Microsoft is interested in going forward with it.
Re:And this is surprising because...? (Score:1)
int main() { int n = 10; int temp[n]; exit(1); }
23:40:53:~$ g++ -Wall -pedantic -ansi -o a a.c
a.c: In function `int main()':
a.c:1: warning: ANSI C++ forbids variable-size array `temp'
a.c:1: warning: unused variable `int temp[((n - 1) + 1)]'
Guys, they were saying this YEARS ago at a seminar (Score:1)
They said back then that the Borg had co-opted kerb and were doing horrible things to it, and would then use it in their marketing jibberish and tout their 'support of open protocols!'.
Film at 11.
*yawn*
Re:This is not new, secret, or prohibited by the s (Score:1)
What Microsoft clearly intends is that no matter what users want, they're going to do everything in their power to make sure admins have to put up a Windows2000 server on their network. The majority of people using computers (including the administrators of most networks) are not technically competent enough to understand why the incompatibility occurs, and they're almost certainly not competent enough to run around making changes to a lot of their production systems, so they're going to wind up being forced to simply pay someone else to fix it so that the Win2k users can "take advantage" of this wonderful thing called Kerberos. This is the kind of crap that Microsoft lives off of. Make sure all the users are morons, and some of them will eventually be promoted to administrators, and then flood the market with other morons trained in the efficient sales and marketing of Microsoft products, and call them technicians anyway.
...which is about the same time that the local MSCE's will be undoing their belts, ready to deliver the Microsoft "solution".
Frankly, at this point I would rather shove my hands up to the shoulders into a wood chipper than to use Microsoft products anymore.
Re:MIT uses NT source code to fix it (Score:1)
This means that the issue is (mostly) irrelevant to Athena. Since every service is going to run on Unix, we don't care about Windows "extensions" to Kerberos; if Windows machines can access Unix services using a Unix-based Kerberos server, then everything Just Works (TM).
Personally, I think Pismere is just a lost cause. Even if Win2K is "a new standard of reliability", I suspect a test cluster of 10 Windows-based machines would have much more serious problems than the 10 beta Linux-Athena machines currently available for public use in W20-575. Just about everything we need is available now (and has been for several years) on Unix, and people with personal PCs have been able to install SIPB's Linux-Athena to get Athena on their desktop. With an official supported MIT I/S Linux-Athena coming soon, it's clear that MIT isn't planning on pushing Windows as their Intel-based OS of choice.
is this really an issue? (Score:1)
and with the sudden surge of popularity in free stuff, the solution seem kind of obvious.. but this isn't one of those "USE LINUX, LINUX RULES" rants.. there are several other solutions out there.. roll your own.
"Embrace and extend" LIVES!? (Score:1)
Would they really still be working like this, even with the way their trial is going? I know they're not stupid, but maybe they just can't help themselves...
Re:I still say... (Score:1)
This is a Very Bad Idea. If you allow for licenses on how standards are implemented, Microsoft could kill samba, and then demand royalties on any program that can interpret MS Word documents.
What you can do, is trademark the name of the standard, and require that any product bearing that mark pass your test suite. Of course, as soon as you do that, the Open Source community will try to beat you to death with big sticks because your standard isn't open enough. (Consider the Java(tm) or Unix(tm) marks)
And then the embracer and extender just implements their broken version anyway, and quite legally calls it "J", or "Unix-like operating system".
On the other hand, if the DOJ forced Microsoft to publish all their APIs and network protocols, in a similar vein to what was done to IBM, then the problem in this instance would be moot, and few other companies are powerful enough to use embrace and extend in this way.
Charles Miller
--
First it was Apple, now M$. Balkanizing the 'Net (Score:1)
Now you'll have to pay a tithe to M$ to list you site on a (M$) DNS and you may or may not be able to see anyone else's site.
Running
Re:DEC MMJ connectors (Score:1)
When asked, they said "oh, the little plugs fit OK in the big sockets". Then they labelled the jacks as "1" and "2", not as "phone" and "computer".
We explained the idiocy to them, and insisted the replace all the phone jacks with RJ11s. They agreed after some cajoring.
been known for awhile (Score:1)
Re:Kerberos? This isn't Kerberos (Score:1)
And this is a pretty good job?
--
Whitespace doesn't matter. (Score:1)
You don't know what you're talking about. (Score:1)
It uses Kerberos as defined by the standard. If people are going to bitch and moan about Microsoft doing this, then stop writing ambiguities into the standards. Of course, there's a reason why this field was left open, and that's so that vendors (apparently, only vendors other than Microsoft, haha) could could use it for things like vendor-specific or application-specific data. Now that Microsoft uses it to their advantage, everyone's in tears. Well Boo-frickin'-hoo.
Whoops, now that I see your comment that Win2K has only 27 apps avaiable for it, I realize that you have no idea what you're talking about. My post would've been better spent replying to someone with a clue.
Cheers,
ZicoKnows@hotmail.com
Re:And this is surprising because...? (Score:1)
Does the Honorable Thomas Penfield Jackson know? (Score:1)
Oh Well. Our company has 1 application left that runs on NT. And it is a 3rd party app. We have put that 3rd party on notice that we will not be using any new versions of Windows in the future and they have a Linuxified version of this service in test... Just like IBM in the early 80s. You just have to be diligent. Don't use M$ products for your IT solutions.
Re:Totally off topic (Score:1)
This is not new, secret, or prohibited by the spec (Score:1)
It is my understanding that this sort of extension is allowed in the kerberos spec and that MS is not the first implementation to take advantage of it.
If you are going to bash MS, don't bash them for following the rules. With W2K, Microsoft is finally making a fair attempt at following and using the standards.
Cables (Score:1)
This is totally off-topic but you wouldn't know where I could find these "MMJ" cables and a MMJ-->9 pin RS-232 adapter. I just happend to buy an old VT420 for pennies, I intend to connect it to one of my Linux boxen. Unfortunately I have no cable. Learning that the cable type is "MMJ" is a big help. If you have any more info I would love to hear it.
Mark Tinberg
Re: Cables (Score:1)
Re:Yes and No.... (Score:1)
from ZDNet's article:
Shanen Boettcher, Windows 2000 product manager at Microsoft, said last week that the company has only made use of an existing feature of Kerberos and is not undercutting an existing standard. But he acknowledged the change is not documented, noting that some developers may believe they need to know the details of Microsoft's change before they will be able to get their software to work with it.
....
When asked how developers will work with the specifics of Microsoft's implementation, Boettcher said: "The contents of the field are currently not available. We have been asked to document them, and we are trying to figure out what to do with that request."
Sounds to me like they're hiding something...
Re:Open Source License Addendum Suggestion (Score:1)
Cause they know if they use it, or modify it, without giving the source back, they can be sued -- not just for money, but for the public release of the code for that product (and thus the loss of any profit from it).
Few would take that risk.
Re:Totally off topic (Score:1)
Re:You can access unix/linux, but.... (Score:1)
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:GPL.... (Score:2)
In Microsoft's defense, they do have lots of monkeys and keyboards (typewriters did not crash enough).
This is COMPLETELY untrue... (Score:2)
http://support.microsoft.com/support/kb/article
This article may be confusing everything with earlier verions of win2k betas (AKA NT5) which microsoft had openly said would not be fully compliant with the kerberos standard. However, they changed this around the RC2 release I believe. You can find an outdated article with more details on this here: [usenix.org]
http://www.usenix.org/publications/login/1997-1
This older stuff is probably what they're talking about, but they have definitely changed w2k to make it fully compliant with the existing Kerberos standard...
Re:You can access unix/linux, but.... (Score:2)
But I think that was what I wrote when I posted that news, only with less words. :-)
--Carpe diem!
Re:Open Source License Addendum Suggestion (Score:2)
With
The people at Microsoft are no different than us; They deserve their individual right to the source too! If joeblow@eggsucker.microsoft.com wants to submit a patch, or tweak it to his personal liking, he should be able to. Judging him a 'lying scumbag' based on the exploits of his employer are wrong..
Re:Story here as well (Score:2)
You can use < to escape a less-than sign (and & to escape an ampersand). You can also post in plain text instead of HTML formatted if you want to post a code fragment.
--
Using more of the spec? (Score:2)
--
Re:So what can we do about it? (Score:2)
Yeah Baby! Lets sling some FUD! (Score:2)
That's right, I can dish it out as well as I can take it :-)
Re:Totally off topic (Score:2)
sigh... here we go again. (Score:2)
Shall we try to get the word out on various news services? It could be difficult - the people who don't immediately understand the technical issues are likely to see us as "anti-Microsoft zealots," and subsequently dismiss our complaints as so much noise. Not that we've always been so good at advocating our actions - for every 10 level-headed suggestions, we have one rabid nihilistic recommendation that is far more entertaining, and grabs far more media attention. Unfair, but true.
The problem is this - How can we figure out a way to prevent Microsoft from doing this? And how do we do it without looking like a bunch of lunatic-fringe weirdos?
Even dumb by M$ standards (Score:2)
Open Source License Addendum Suggestion (Score:2)
Y'know we'd save a lot of headache if every open source license had the following addendum:
Microsoft, and any subsidiary company or employee thereof, is specifically barred from modifying this source code in any way, shape or form.
If you can't join 'em, beat 'em...preferrably with a big stick.
This is a creative move. (Score:2)
The complaint against Microsoft regarding this issue is that their specific use is a secret.
This is a fairly creative move on Microsoft's part. From appearances, they have fully embraced the standard and have followed it to the letter.
They simply chose to keep a secret.
Why can't Microsoft keep a secret? Sure, it's annoying, but is it illegal or morally/ethically wrong? I don't know. I'm biased, so it seems wrong to me.
I don't think it benefits consumers. It is a barrier to interoperability. It is unlikely that this single secret required a significant amount of research and development, except maybe to identify it as a strategic thing to keep secret.
It won't take long for someone to reverse engineer it or pry the information out of Microsoft, but in the meantime everyone is going to appear to be lagging behind Microsoft in the W2K-compatible server arena, and Microsoft will gain market share. It is unlikely that the DoJ will be able to reverse that.
Regarding traceroute... there is no "right" way to traceroute. Traceroute is a hack. It was not designed into IP. It simply uses conveniently available IP capabilities to accomplish its goal.
Even IF Microsoft's traceroute is not the same as others, their implementation hasn't failed me... so I find any implementation difference to be far less annoying than the fact that they called it "tracert.exe" instead of "traceroute.exe".
None of the operating systems on which "tracert.exe" ships are restricted to 8.3 filesystems. Maybe it's cuz of the ISO9660 filesystem. Whatever the case, it's annoying.
Hmm... I seem to be drifting here... wheee! [submit]
DEC MMJ connectors (Score:2)
the way the MMJ (modified modular jack) came about was to protect devices from being plugged into phone lines. rj11 for comms devices is braindead, IMHO. rj11 is for telco current loop stuff - period! for serial 232 style devices, the MMJ made perfect sense.
and with ethernet being a wider connector (rj45), you have the same benefit as the MMJ - you can't plug a serial cable into a phone jack.
ok - well, a lot of people are using rj45 for phone connectors today. that still doesn't make it right. rj11=phone; rj45=data. why do folks have problems understanding this?
--
Actually the article is wrong (Score:2)
"Windows 2000 clients, either Server or Professional, can be configured to use an MIT Kerberos server. This provides a single sign-on to the MIT KDC and a local Windows 2000 client account"
You can read more about this at http://support.microsoft.com/support/kb/articles/Q 232/1/70.ASP?LNG=ENG&SA=ALLKB&FR=0 [microsoft.com]
So at least they didn't completely break kerberos.
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)