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."
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.
What we want stopped?
:P
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.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
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
"How can we figure out a way to prevent Microsoft from doing this?"
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.
A Government Is a Body of People, Usually Notably Ungoverned
"[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