DES will die in Heimdal 1.3

A long long time ago DES was standardized (1973, before I was born). Some 30 years later (2003) is was withdrawn as a standard by NIST, today 5 years later, its time for DES to finally die. Last year you could brute force DES in 6.4 days by buying a machine for $10000. So last year was the time for you to migrate to better encryption types for your Kerberos realm.

If you really are in love with DES and can't stand to be without it, now its the time to add "[libdefaults] allow_weak_crypto = true"to your configuration file so that your love wont die when you upgrade next time. If you want to check your configuration, the code is already commited to trunk in the source repro.

Application that will stop working are old Kerberos 4 tools and telnet/telnetd.

Heimdal-1.3 will deprecate DES

PS there is an exception for AFS to allow it still to use DES encryption types.

Do you want Heimdal to speak Swedish to you ?

As part of Heimdal 1.3 we have been adding i18n support to the base libraries and some of the Kerberos user utilites using GNU Gettext. It should also work with other localization packages like the MacOS X CoreFoundation's CFCopyLocalizedString with some minor code hacking.

We that work on Heimdal only know Swedish and English, so can can help translate the error strings. You don't need to download special tool, just go to Heimdal at launchpad and you translate the strings there. Just let us know that you have started to do the work so that we will remember to download your translations before release (or when you want to sync to you can test how it feels to get heimdal in your language.

Adding support for referrals in GSS-API

We can implement referrals support for Kerberos mk_req API or do it for GSS-API. For me its an easy choice, most consumers uses GSS-API, lets go for that.

DNS canonicalition happens when we pass in a GSS_C_NT_HOSTBASED_SERVICE based name into gss_import_name(), so its only that case we really need to care about. DNS canonlisation is done by krb5_sname_to_principal(), see documentation in Heimdal trunk.

The simple solution is that in gss_import_name() we the hostname to krb5_sname_to_principal(), instead we mark up the principal as magic-unresolved. Now there are some places where we should return the name in its native form, and that is after gss_init_sec_context() is done by gss_inquire_context(), and gss_canonicalize_name(). We also need to deal with these magic-unresolved names in gss_acquire_cred() and gss_export_name().

So lets go over the four cases when we have a magic-unresolved.

gss_init_sec_context(), we try first to get Kerberos credentials using TGS-REQ using the sort name and hope that its an valid alias, if no, we call back to the old way with krb5_sname_to_principal(). Right, we update the name in the context to what we used.

gss_acquire_cred() same thing here, first try literal, then krb5_sname_to_principal().

gss_inquire_context(), this is simple gss_init_sec_context() will have solve the problem for us, just copy out the string.

gss_canonicalize_name() here we don't have a chance, so I guess, we want to have the canonicalized name, so I used the krb5_sname_to_principal() to canonicalize the name.

So where to store this magic-unresolved bit ? Well it happens to be so that the Kerberos gss-api mech uses Kerberos principals (krb5_principal) so there no extra bit where we can save the info. So, instead we hook the krb5_principal name type field and misuse that. Any time we will export or use the principal, we'll convert back to KRB5_NT_SRV_HST that it would have been if we used krb5_sname_to_principal().

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.