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.'"

4 of 62 comments (clear)

  1. Kerberos by gravos · · Score: 3, Insightful

    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.

  2. And how wil MS influence this? by Anonymous+Crowbar · · Score: 3, Insightful

    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.

  3. Re:Someone has to ask it... by KidSock · · Score: 4, Insightful

    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?

    MS and the MIT Kerberos crowd get along just fine. I believe the things MS did are generally thought of as good. Some are starting to make it into the Kerberos distros (e.g. I think Heimdal has support for constrained delegation). The PAC business was a little overblown. The Samba guys were able to figure out how to sign the PAC from the doc MS provided and with some carefull network analysis. Of course the Samba guys are not happy overall. I don't know if they have a problem with their Kerberos code but other modes of communication and the semantics to go with are not adequately documented.

  4. Re:Can someone answer this? by Nurgled · · Score: 2, Insightful

    LDAP is just a directory protocol. Kerberos is a network-wide authentication protocol. I'm a little rusty on Kerberos myself, but I believe the following summary to be a reasonable description of what Kerberos does:

    Kerberos is basically an infrastructure which applies cryptography to the problems of intra-domain and inter-domain authentication. It is based around the concept of "tickets", which are cryptographic tokens that can be presented to services in order to authenticate. Each ticket is applicable only to one service or host.

    The process begins by asking the ticket granting server (or "domain controller", in Microsoft perlance) for a ticket granting ticket, or TGT. A TGT is used to obtain other tickets. These additional tickets are then presented to their respective services as a credential during the authentication process. Since these tickets and the authentication exchanges are maintained by the system's kerberos implementation, it appears to end-users that they are able to hop from system to system and from service to service without logging in to each one separately.

    The upshot of all this is that you aren't constantly sending your password all over the place, and each service is authenticated separately. If you have access to a Windows 2000 or above machine that is on a domain, try typing "klist tickets" at the command prompt and you'll see a selection of tickets that belong to your current session, including the all-important ticket granting ticket, a ticket for the Active Directory LDAP service and a "cifs" ticket for any servers you've connected to using Windows File/Printer Sharing.

    Kerberos domains can also federate so that tickets granted in one can be used to authenticate in another. There is also support for delegation, which allows a user to securely authenticate to a service through another service, such as a webmail client which ultimately logs into an IMAP server. I will confess that I don't know precisely how these two things operate, but I'm sure you can find out more via Google if you're interested.