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)...
In celebration of this milestone they will also be launching a new consortium dedicated to preserving and evolving this standard for years to come.
That's a wonderful bit of spin.
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"? Bullshit...
Kerberos was an idea for a time when nobody used SSL, nobody had SSH, VPNs were proprietary and could only be done on specialized hardware, and yp/nfs was still considered "acceptable."
Kerberos is an 8-track technology in a MP3 world where one can use an ssh client to proxy any SOCKS client, while mounting their home directory via SSHfs, while tunneling all their IP traffic (yep, latest openssh does full IP tunneling!)
I knew MIT had officially jumped the shark when I saw an alarm clock covered in shag rug with wheels touted as "brilliant", when it was something on the level of kitsch I'd expect from some no-name third-world electronics company.
Another great example of MIT's failure to generate students who have useful, applicable knowledge would be when their underwater robotics team, despite supposedly being the best+brightest, backed by sponsorship from the biggest defense contractors and oil companies...got their asses handed to them by a bunch of high school students from East Nowhere.
Please help metamoderate.
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/
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.
"The Kerberos Consortium" makes it sound a lot cooler than it actually is.
most. Look at the to you by Pe8isbird is dying and its
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.
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
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