Slashdot Mirror
MIT Launching Kerberos Consortium
alphadogg writes to tell us that next week MIT will be throwing a 20th birthday party for their Kerberos authentication system. In celebration of this milestone they will also be launching a new consortium dedicated to preserving and evolving this standard for years to come. "Kerberos, originally created for MIT's Project Athena, is used mainly by enterprises and MIT's goal is to see the IETF security standard develop into a universal system for single sign-on. [...] 'Kerberos has.... become successful beyond MIT's internal capacity to respond to the world's demands for development, testing and support. So we need a new organizational structure that can accommodate the demand.'"
For the first time, Kerberos will have an official home, supported by MIT and other Consortium members. This is a good thing no matter how you look at it.
This game will waste your life. Don't clicky!
With MS embedding thier version of Kerberos into their OS's it's fairly certain they will try to influence the direction of this in thier favor. Just something to watch out for.
Maybe I will go... I can bring magic cookies!
...so why not me?
Long ago, people were all upset when Microsoft did the ole embrace and extend thing with Kerberos. I haven't heard much about that for years. Has it been a problem for anyone? Will the Kerberos consortium take whatever Microsoft did into account so as not to break what other people have done to work with and around Microsoft?
I don't know much about kerberos, but I do know that it has always been used in the national lab where I worked the last few years (Sandia Natl Labs). So apparently the government trusts it (not sure if that counts for anything)...
If you can ignore the MIT bashing, mod parent up.
My from-the-hip guess is that MIT has realized that they're a)dependent on Kerberos and b)nobody else uses it, so they need to generate some noise, make some unfounded claims, and hope to get some other people onboard. "Used in the enterprise"? Bull...
FYI: Kerberos is the standard authentication protocol used on just about every enterprise network on the planet. All Windows clients that are members of an Active Directory domain use Kerberos to authenticate with fileservers, web services, LDAP servers and just about anything else that has domain credentials. That's probably 80% of Enterprise users alone. And the rest are probably using NFS which is rapidly moving to Kerberos authn' for everything.
I have to agree with the OP. Kerberos was nice when it came out, but there are better authentication mechanisms available out there. It is true that it is widely used in the (mangled) version used under Active Directory, but I find it difficult to believe that NFS is migrating to Kerberos. Would you care to share some figures?
Kerberos is used extensively within Microsoft enterprise scenarios and is used in other non-Microsoft environments as well.
Both Kerberos and PKI present management difficulties as you try to expand across large numbers of domains / forests with diverse security policies.
If quantum computing ever truly breaks classic PKI approaches, the alternatives will be to develop PKI approaches that are more resistant to quantum attacks (problems are known that are believed to be resistant) and/or to use NS / Kerberos with doubled key length (quantum search attacks roughly square root the effective key size).
Kerberos and SSH are not comparable technologies. If you must make a comparison, compare it to SSH's key mechanisms (host based, user key pairs, agents). In those cases there are pros and cons to be debated.
Kerberos's authentication isn't tied to a specific service and the same token can be used across a many daemons. In fact, SSH is one of the daemons supports Kerberos authentication (ie, is kerberized).
Kerberos can be a pain to setup, but once you take the time to understand how it works it's actually pretty nice.
Here is Linux's NFS v4 architecture. Other implementation's use kerberos too. Kerberos is one of the major improvements to NFS v4.
http://developer.osdl.org/dev/nfsv4/site/architecture/
That's some chip on your shoulder; directed toward one of our finer institutions of learning. Let me guess, you either have no formal education or one from some place like DeVry. Well, if you're so wonderful perhaps you could share some of your profound technological genius with us.
As I have demonstrated from some of my previous posts, Kerberos is indispensable in the network administration infrastructure in the Linux world, it connects to SSH, Samba, Apache, and god knows what else. Its something no Linux Admin should be without knowledge of. The MIT Kerberos implementation has been behind for years because of their refusal to implement LDAP support until now. I'm just glad Kerberos finally gets a standard LDAP Connector. I'm sick of having to maintain one database for Kerberos and LDAP for everything else.
Still, Kerberos rocks my world. I couldn't do without it.
Yeah, dumbass. Kerberos is implemented in NFSv4, and it's the only robust way to secure NFS. You, sir, are a clueless slashtard.
"The Kerberos Consortium" makes it sound a lot cooler than it actually is.
You are indeed a slashtard. Kerberos is a mandatory-to-implement feature in the NFSv4 spec and has been part of NFSv3 (optional feature) for many years. Kerberos is hardly outdated. You are a clueless, naive waife who has no real idea what is going on in the world of computer security if you think it is outdated and dying.
Nope, you are confusing authentication with stream encryption. One can even configure SSH to use Kerberos authentication!
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Truth be told, there was a big falling out between MS and MIT over Kerberos. Microsoft, as they are wont to do, tried to take Kerberos and proprietize it. The MIT guys said "not so fast," and took them to court over it. On the eve of what most assumed would be a judgment not in their favor, Microsoft suddenly had an 11th-hour change of heart and revealed their changes (although with poison-pill licensing terms attached, at least initially).
From an article published in 2000:"Joint proposal" my ass. Microsoft got dragged into that kicking and screaming. They would have buried Kerberos long ago if they had gotten their way.
As an eventual result of this, some of Microsoft's changes were written up as an (informational, non-standards-track) RFC, which takes pains to repeat, over and over, that Microsoft's implementation was compatible with the original. The monopolist doth protest too much, I think.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
The Kerberos Konsortium?
I still don't fully grasp this - perhaps someone can explain.
What does Kerberos+LDAP give you that LDAP on its own doesn't? My reading is that with kerberos-capable client software, once the user's entered their password once for one thing they don't have to for everything else - at least until their token expires - but ICBW.
Better authentication mechanisms? Like what?
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
I thought they were a widget set. Or do they name anything Athena that comes out of MIT, thinking it's nice and Greek an' all ?
Religion is what happens when nature strikes and groupthink goes wrong.
...but only if your timepiece matches theirs.
IMHO the future direction taken with Kerberos should be merging the protocol into LDAP (e.g. for the future LDAPv4 revision of LDAP protocol).
Here's my rationale behind this: The problem with Kerberos being a distinct protocol from LDAP is that the distinction causes lots of confusion among the implementors, system architects, developers and administrators. This results in lots of cases where the two protocols are misused.
The correct distinction should be that you use Kerberos for authentication (that is, proving that a user is someone he claims to be) and LDAP for authorization (that is, given an authenticated user, determining information related to granting access to some resources - such as group memberships, possibly some application-specific ACLs etc) and for other data for which a directory is useful (hard to list all possible uses of LDAP, but e.g. mail aliases are a fine example).
But because the protocols are separate and very hard to setup together on a single authentication/authorization/directory server (or a group of servers!), people go along with only one of them, usually using LDAP for authentication instead of Kerberos (see mod_auth_ldap for Apache), effectively prohibiting themselves from implementing usable single sign-on
For an example, let's have a look at available OSS solutions. Apache Directory has Kerberos and LDAP integrated from the start, but it's painfully slow as a server at its current state. A mail server using LDAP for aliases can perform quite a bit of hammering on the LDAP server. MIT Kerberos cannot use LDAP databases. So doesn't Shishi Kerberos, although they plan implementing this in the future. That leaves us with Heimdal Kerberos. Heimdal requires the LDAP server to be on the same machine and support LDAPI connections. So that rules out Fedora Directory Server, whose stable version 1.0.4 doesn't support LDAPI yet (although the CVS development version recently got LDAPI support, finally).
I've tried setting up a Heimdal Kerberos server with OpenLDAP (with SASL2 daemon in the middle), and succeeded, but it was a royal pain in the *ss.
All HOWTOs I've found on the web described a brain-dead design where Kerberos maintains a classic file-based database on its own, separate from OpenLDAP database, and one has to make sure they both are in sync (because it's possible that one can have a user that the other doesn't). In such a setup replication is really troublesome and has to be done using 2 different channels and mechanisms (e.g. LDAP syncrepl + Kerberos' own redundant servers).
I wanted an integrated design, where Heimdal stores its data directly in OpenLDAP.
This way, I couldn't possibly create a Kerberos account without an LDAP account (well, I could if I omitted Kerberos objectclass and attributes, but it would be harder to do and easier to detect). Also, I could use only LDAP's replication mechanisms and easily provide fault-tolerant cluster of LDAP and Kerberos servers.
Unfortunately, the diagram for this setup looks quite daunting for a beginner implementor, as you can see for yourself.
There were also lots of gotchas:
Athena involved setting up a network of workstations so that you could log onto any one of them and have access to your home directory, mail, etc. as if they were local to that machine.
This doesn't sound like a big deal until you find out that it started in 1983. Kerberos and X are children of Project Athena.
Wikipedia is your friend: Project Athena
Mind you, I don't use the Kerberized stuff at work that much, mostly because I prefer to keep everything I need local on a laptop so I can continue to work even when there is *no* network available (still annoyingly often when travelling, alas...)
"Little does he know, but there is no 'I' in 'Idiot'!"
The US seems to be a lot more flexible now about not harassing code websites, and John Gilmore and the EFF beat them up by building a machine to crack DES, but I don't know if you can export full Kerberos now (or at least if you can get official permission.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks