Heimdal

Last Sunday I updated the draft Kerberos ticket extensions to version -02.

Ticket extentions are to enable PK-CROSS and other applications that want to send clear text data in the ticket between the KDC and the server.

The update included and extension to the Kerberos protocol, a much cleaner extention protocol wise, at the same time it requires update clients. The reason I did both was the comment from Ken Raeburn that though the new protocol was horrible (which it is) and Kerberos should stay pretty, so I made the protocol stay pretty.

There is still the issue with protection, may I just should just give up making it truly extensionally and just include a checksum using the same key as the Ticket.enc-data is encrypted with.

This is something I brough up at IETF72 in Dublin, Ireland.

Kerberos (in the non Microsoft world) have always used DNS map to Kerberos principals. Sam Hartman describes the issue more here: http://www.painless-security.com/blog/2008/08/krb-dns/

My idea doesn’t come from how to secure Kerberos (I already know that using DNS is bad), it comes from how to make Kerberos useful for users in the transition. Having client configuration really sucks, its horrible and a really pain to upgrade, and when you think you solved it, someone installs a old krb5.conf that “have always worked” and was ”needed for some reason I can’t remember”. The reason it worked was because they forced the client to not upgrade, and the reason is that they have a broken application that can’t do the right thing. Do I sound bitter, well, kind of.

My idea is that the realm annouces in the krb5tgt that is support referrals and all entires are populated that the clients are supposed to be allowed to use. Ie, both host/shell@EXAMPLE.COM and host/shell.example.com@EXAMPLE.COM are in the Kerberos database. So when then user types in ssh shell, the library should just ignore that.

I’ve been experimenting with Heimdal to do this and have come some futher then when I talked at IETF with regard to practical problem.

First its hard to know what realm you are going to end up in, mostly because the interactions between name selection, dns canonlisation and referrals. The old way was simple:

1. host = getnamebyaddr(getaddrbyname(hosthost))
2. target = { service, host } @ getrealmforhost(host)
3. ticket = get-service-ticket(target)

Using what the user provided seems simple.

1. target = { service, hostname } @ get-realm(client-tgt)
2. ticket = get-service-ticket(target)
3. if ticket == null and compat: then ticket = old-method(hostname)
4. use ticket

where get-service-ticket is this:

1. tgt = get-tgt(client-principal)
2. service-ticket = tgs-req(tgt, target, [canon])
3. if (referrals(service-tkt)): then update(target, tgt = service-ticket), goto 2
4. return service-ticket

So lets say we are the user foo@FOO.COM and we want to login to
the machine shell.

shell (aka shell.foo.com) is really part of BAR.COM service and since FOO.COM’s KDC knows that, its going to return a referral.

We are getting a referrals back, and the referral say that we should go to BAR.COM and what target principal to use.

In the AD world this is simple, all SPNs are part of the global catalog, so all KDC in the forest can figure out what the user really wanted. IN a pure Kerberos enviroment, its not that simple since this helicopter-view of the worlds doesn’t exist. So in the pure environment we can’t use short names when the short name is in another realm. We can only do hostname to realm mappings. Also note that the Global catalog on spans a forest, so in the multi-forest environment, Windows KDC also resolves to mapping full names into DNS names.

So a flag in the credential cache is probably a good idea to tell the client to turn off DNS-canon, but on the other hand, if the KDC turns on this flag, it also better support referrals and have a global view for its referral world if it want to support non-fqdn types of names.

Heimdal have had server referral for quite some time now, MIT Kerberos have not (they have it in the client though).