Kerberos ticket extentions

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.

PKINIT works with Samba4 + windows XP

Today we got a patch from Sho Hosoda that add back the Windows XP SP2 support to Heimdal PK-INIT support. With this we can use smart cards to logins a Samba4 domain, this is way cool and why we started this work several years ago.

http://www.h5l.org/fisheye/changelog/heimdal/?cs=23861

Referrals

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).

GSS_C_DELEG_POLICY_FLAG and cross realm

I've been working on the draft for GSS_C_DELEG_POLICY_FLAG lately. One thing I have added is th reason why we need this document. This was requested by reviewers.

Its for legacy deployments that can't update Kerberos today and can't/don't want to change behavior.

Getting the flag defined and the behavior clarified is only the first step of this process. The second is to make sure it works in the cross realm case too. The proposal I have is to make it an MUST that all intermediate cross realm tgt tickets also have ok-as-delegate flag set. It seems Microsoft does it that was and I've asked them if I've read their spec is correctly.

gssmaestro

I have started to merge the Samba GSS-API change from Andrew Bartlet and Stefan Metzmacher. As part of that work I have completed most of the basic work of my clone of gssmaggot/gssmaster that David Christansson (Microsoft) have written.

 The problem with gssmaster is that its not released in source-code format, so I wrote my own client (gssmask) and server (gssmaestro). gssmaestro is not as complete that I wish, but test most of the context and token functionallity in the gss-space.

I plan to use gssmask/gssmaestro to test with gssmaggot, this way I can make sure I don't break anything, and at the same time still work with Microsofts and MIT gssapi implementations. This is what we do for the interrop events, but usually with new and shiny code.

There is also a new regression test that uses the gssmask/gssmaestro test program in heimdal/tests/gss directory and its hooked up to the regular automake regression tests, so hopefully I wont break the basic gss-api functions ever again.

Symbol versioning

I've started to add symbol versioning to heimdal libraries to avoid exporting symbols all over the place.

 This have some bad side effekts. As usual there is not just one format for the file. The gnu ld one is what I currently support, so I have to munch the gnu file and produce a flat-file too (for Mac OS X).

 The other that is causing more problems is that its no longer possible to unit test internal functions, because libraries that no longer export those symbols. Right now I have no real solution to the problem. One is to build a library without symbol versoning and test with that. Other is to just build that module, but that doesn't work with libtool since libtool requires object files to be of the same type. Ie a object can't belong to a binary and a library at the same time. Beloning to to  two library or two binaries are fine though. But building two files doesn't really appeal to me, I'm waiting long enough as it is already. Currently I just export the function and hope that consumers wont use them.

KDIGEST and Heimdal 0.8 release process

In the last few days me and Klas have worked on improving the KDC digest stuff. It will be used together with Radiator to provide 802.1X/EAPOL login at Stockholm University. The interface now supports CHAP, MS-CHAP-V2 and SASL DIGEST-MD5 in addition to the NTLM versions. The only new system is MS-CHAP-V2 but I also changed the digest protocol from experience from the NTLM work.

Heimdal 0.8 release is progressing nicely (wrote code 22 out of 31 days in January), there is not much I feel needs to be fixed before the release and I've been working on portability fixes in addition to the KDIGEST work since the heimdal 0.8 branch was cut. There is some new functionallity on the HEAD that wont be in 0.8 release, like the Kerberos PRF, mainly because there have been no interop testing. That how valueable test vectors in RFCs are.

The info manual pages have been cleaned up and now they are generated each night for the diffrent branches that I maintain. hx509 needs some more text but is a good start, I'm starting to get concerted about the complexity of the hxtool issue-certificate tool, its should be simpler that it is but the X.509 folks have just dreamed up too many options and features. The manual pages (formated in mdoc) still needs to htmlized and published on the web, but that will have to wait util I find a good way to do it (ie part of the build system).

After the Heimdal 0.8 release the CVS tree will be converted into subversion tree and moved to Stockholm University and IT och Media, but because CVS is so bad for us, its mainly because of that subversion is faster to use for large repositories. I can't feel that changing to subversion is a downgrade, subversion doesn't give me O(1) time sandboxes (it provides O(1) branches, that doesn't help me, still need to check out the tree). I want to have a source code revision system, not a revisioned filesystem. Anyway, subversion will have to do for now.