Slashdot Mirror
Proprietary Extension to Kerberos in W2K
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."
Here it is.
Trade secrets have very limited legal protection compared to copyrights or patents. As I understand it, as long as you haven't actually had access to the secret information, you can divulge it all you want. So reverse engineering would be perfectly legal. That's why there are both trade secrets and patents. With a patent, you get protection for a limited time. With a trade secret, the protection lasts until someone figures the secret out (as opposed to ferreting it out).
I am not a lawyer. I do not actually know American law. This is just a bunch of uneducated guesses.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Anyone wanna take bets on how long it'll take for someone to reverse engineer the MS extensions?
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
Not wishing to speak for RMS, but isn't this *exactly* why he created the GPL - because the MIT license allowed companies to try these stupid tricks.
MIT (as well as every other educational institution) should release all code under the GPL, or similar licenses with protection against proprietary extensions.
-- Mike Greaves
Windows 2000 either supports Kerberos authentication or it doesn't.
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
The reference implementations of Kerberos 4 & 5 are available under a BSD-style license, so there's nothing wrong with what Microsoft has done, even if they do use Kerberos code in Windows. (I'm not sure if they've said they use any MIT code or if they did a ground-up implementation based on the specs)
> More importantly, the standard DCE approach
> 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.
No, actually it is still an issue. I have been requesting that Microsoft document this extension (Hi Peter :-) ever since I heard about Win2k (then WinNT5) being kerberos based back in '97. I was porting MIT Kerberos 5 to Windows NT 4.x at the time for Cygnus (now RedHat).
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.
Regardless, it really ins't [sic] microsoft's job to ensure compatability [sic] with anyone but themselves.
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.
spawn_of_yog_sothoth
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 pageRFC 2065
RFC 2137
RFC 2535
Secret Key Transaction Authentication for DNS (TSIG)
Secret Key Establishment for DNS (TKEY RR)
GSS Algorithm for TSIG (GSS-TSIG)
White paper on Kerberos interoperability
Press release on Kerberos interoperability
S imple Secure Domain Name System (DNS) Dynamic Update
I had the same kind of questions last month. It lead to an essay called "Barbarians in the Library".
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. :)
--
how to invest, a novice's guide
You can even fix NT, if you have the source code.
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).
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!)
-BrentIs there anything in the Kerberos license that demands they not call it "Kerberos"?
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?
A Government Is a Body of People, Usually Notably Ungoverned
Is their LDAP....er, I mean Active Directory, implementation compatable within a standard LDAP environment, or did they "customize" it as well?
I thought pretty much any Win32 app other than games would run on Win2k fine, is that not true?
I just returned (less than an hour) from a Microsoft briefing about W2K (hey it was free and fun).
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.
An MS plugin for Netscape exists, if you're running Netscape on a system which is compatible with the plugin.
Actually, even Exchange Server has problems if not running on same server as IIS.
Not to mention I submitted the story 4 days ago, and it was rejected in a matter of minutes. Who cares anymore...
Nothing Evil about this, just annoying
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)
--
+&x
I know two people with MS: one of them is me, and the other one is my mother (yes, really.)
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.
GCC has typeof which nobody else does. It also has builtin functions for alloca, abort, exit, and _exit. Which by the standards should be in a library allowing for a linktime replacement of the standard C versions. In g++ there is the headof extension. And those are just the obvious.
That's not really an answer. It may be a use that is related to a property that only W2K has. It also may have been the sort of thing that was developed in 6-12 months rather than 6-12 years. Some of these standards take way too damned long to settle, often because of interorganizational posturing.
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.
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.
Yes. However, if Kerberos had been patented, and then use of the patent was granted under some copyleft license, then Microsoft couldn't have done this.
Of course, that might not have helped either; maybe they'd just have opted for something entirely different.
perl -e 'fork||print for split//,"hahahaha"'
I believe they use a field for which there is no specified use.
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.
It's 10 PM. Do you know if you're un-American?
Obviously MS has choosen to implement a standard that, while pretty similar to Kerberos, actually isn't Kerberos. The current standard is available from enough sources and Microsofts changes are not part of it. Thus any company using W2K for which Kerberos is a critical application should sue MS on the grounds that their product W2K isn't able to use Kerberos, contrary to advertising.
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'.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
MS sure did release a browser fast when Mr. Gates realized the internet was important.
:)
In Microsoft's defense, they do have lots of monkeys and keyboards (typewriters did not crash enough).
Folks, this article about w2k Kerberos incompatibility untrue. I have set up a Win2k RC2 workstation last month at my job for testing purposes. We have a Unix KDC on the network running the standard MIT Kerberos distribution. I configured the win2k workstation to authenticate against the unix KDC - and it worked perfectly. As a matter of fact, I configured the workstation using microsoft's own step by step instructions for doing so, which can be found ats /Q232/1/70.ASP?LNG=ENG&SA=ALLKB&FR=0. See the part entitled "Using an MIT KDC with a Windows 2000 Workstation".
1 /embraces.html.
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:
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...
But I think that was what I wrote when I posted that news, only with less words. :-)
--Carpe diem!
Replace in any way, shape or form.
...in the common course of business, or for gain of economic interest
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..
.sig: Now legally binding!
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.
--
Time is Nature's way of keeping everything from happening at once... the bitch.
--
Time is Nature's way of keeping everything from happening at once... the bitch.
I'm afraid we've been seeing MS-TCP/IP for a while now. No version of Windows currently supports the full TCP/IP spec. In fact, Linux only got full support recently.
That's right, I can dish it out as well as I can take it :-)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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?
Strike while the irony is hot! -- The Freethinker
Reminds me of the old DEC days when they made proprietary RJ-11 connectors, they had the tab on the side so you could only use sanctioned DEC cables, which were twice as expensive. I can see parallels in what M$ is doing, for obvious reasons, but when will M$ learn that every time they do something like this they really create long term damage to their products and alienate their customer base. Whatever PHB's at M$ who supported this should be canned, this is even bad by M$ standards.
More race stuff in one place,
than any one place on the net.
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.
Let's give proper credit. For once, Microsoft has NOT perverted the standard. They have used a field in the way the RFC described. I believe the RFC actually states that the field is free-form, and that its contents should be defined by the application.
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]
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?
--
--
"It is now safe to switch off your computer."
"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
So at least they didn't completely break kerberos.
First things first. The mag is wrong, we did Kerb5/Win2000 testing most of last year and it was sometimes broken in the -betas-. Final product does work as stated.
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
--
I had heard this rumour long before W2K came out. However, according to this document, such interoperability is possible. I'm not sure who to believe.
sigs are a waste of space
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, that had MS-CHAP support.
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.
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.
Actually you can use W2K kerberos to access Unix/Linux kerberos systems. But you can't use Unix/Linux kerberos clients to access W2K servers. Typical Microsoft "embrace-and-extend" crap.
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.
according to Microsoft Mythology, Kerberos is a cat and it's got four heads. It guards the gates of heck.
---
maybe MS will test the UCITA and not allow reverse-engineering of this "proprietary" tradesecret that they obviously enhanced...
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?
... hi bingo
The best part is that the MS Kerberos extensions *STILL* Rely on the old insecure Domain Authentication system. They actually pass tickets between machines with that. We all know how wonderful that system is, and of course how secure it is. You still won't find MS Kerberos to be useful, the only way for Win2k to correctly authenticate to a Kerberos domain, is to make it part of a guest/second domain, in which the W2k PDC is the KDC for a second domain!
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*
There is a solution to this. Or at least to stop it from happening in the future.
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
[ approaching AI ]
You can get some more info on this issue in the Kerberos FAQ
"[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.
> Can you link to any hard data?
:-).
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.
> 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.
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.
mailing list several days previous. Here is the 'relevant' information, posted by a rep from Microsoft:
:)
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
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
There are always four sides to every story: your side, their side, the truth, and what really happened.
A lot of people are reacting to MS's "breaking" yet another standard, and don't understand the real problem that MS is trying to solve.
/etc/passwd and /etc/groups, or their local equivalents. In the real world, this isn't always possible but many sites use a (standard?) secondary mechanism that maps Kerberos principals to local user names, and again you acquire user information from /etc/passwd and /etc/group.
/etc/passwd and /etc/group information into the "authorization" field. That's unusual, but not inappropriate -- and arguably an elegant solution to the crippled NT environment.
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).
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken