The krb5-cc-[gs]et-config API

I've created a new API to the krb5_ functions, its for storing Kerberos related data in the credential cache.

• Realm configuration that is fetched runtime, for that the target is a domain that only should have Kerberos canonlization done and not dns canonlization


• Forwarded tickets, to avoid re-fetching the from the KDC

krb5_cc_get_config
krb5_is_config_principal
krb5_cc_set_config

There is a patch for MIT Kerberos that also includes this interface, so hopefully it will be included in MIT Kerberos 1.7.

ok-as-delegate and GSS-API

Background

To forward your Kerberos credential from a gss-api client to a server you turn on the flag GSS_C_DELEG_FLAG. This will, as part of the authentication, forward your tickets to the server.

The problem is that you don't want to turn on this just for every server your what to authenticate to, because most of them should probably not be trusted with your tickets.

To solve this Microsoft added an extention to the Kerberos, that was added to RFC4120 (The Kerberos protocol RFC). The extention is called ok-as-delegate and is a ticket flag. Using the flag the client can determine that the system administrator thinks about the host, if it should be delegated too or not.

Non Microsoft sites have been using GSS-API implementations that doesn't honor the flag ok-as-delegate and most of them never has set the ok-as-delegate flag. In some cases the sites are using Kerberos implementations that doesn't even support setting the ok-as-delegate flag in the Kerberos database.

Users at these sites have grown accustomed to the behavior ok GSS_C_DELEG_FLAG and changing the GSS-API implementation behind them to make GSS_C_DELEG_FLAG honor the ok-as-delegate flag will only make people upset.

New flag

What we can do it introduce a new flag GSS_C_DELEG_POLICY_FLAG that is defined to honor the flag ok-as-delegate.

The flag GSS_C_DELEG_POLICY_FLAG is a local flag that is never seen on the wire. And, its only used by the initator, the acceptor never see the flag.

There are four cases where GSS_C_DELEG_POLICY_FLAG and GSS_C_DELEG_FLAG interact with each other and the resulting return flags.

• Neither flag set
  do nothing with regard to delegation


• GSS_C_DELEG_FLAG set
  always try go delegate and set GSS_C_DELEG_FLAG in the return flags if successful


• GSS_C_DELEG_POLIY_FLAG set
  try to delegate if ok-as-delegate is set, delegate and set GSS_C_DELEG_FLAG and GSS_C_DELEG_POLICY_FLAG in the return flags if successful


• GSS_C_DELEG_FLAG and GSS_C_DELEG_POLIY_FLAG setalways try to delegate, set GSS_C_DELEG_FLAG if successful in the return flags if successful. Also, if successful and ok-as-delegate was set on the service ticket, set GSS_C_DELEG_POLICY_FLAG in the return flags.

Cross realm ?

What is missing is how ok-as-delegate and GSS_C_DELEG_POLICY_FLAG should work in the cross realm case. RFC4120 is quiet on this issue, the flag on ok-as-delegate doesn't mean anything on the cross realm tgt. The question is how this should be dealt with.

The obvious answer is define a meaning on the cross realm tgt ticket for ok-as-delegate, but how will that interact with existing deployments.

Current behavior is for released MIT and heimdal is that the flag is ignored. For Microsoft clients is that they honor the flag for windows domains, and to external realms they allow delegation is a flag is set on the realm configuration on the client.

Any good ideas out there ?

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