Heimdal 1.5 and 1.5.1

Release Notes - Heimdal - Version Heimdal 1.5

New features

 - Support GSS name extensions/attributes

 - SHA512 support

 - No Kerberos 4 support

 - Basic support for MIT Admin protocol (SECGSS flavor)

   in kadmind (extract keytab)

 - Replace editline with libedit

Release Notes - Heimdal - Version Heimdal 1.5.1

 Bug fixes
 - Fix building on Solaris, requires c99
 - Fix building on Windows
 - Build system updates


http://www.h5l.org/dist/src/heimdal-1.5.1.tar.gz

Heimdal 1.4

Release Notes - Heimdal - Version Heimdal 1.4

 New features

 - Support for reading MIT database file directly
 - KCM is polished up and now used in production
 - NTLM first class citizen, credentials stored in KCM
 - Table driven ASN.1 compiler, smaller!, not enabled by default
 - Native Windows client support

Notes

 - Disabled write support NDBM hdb backend (read still in there) since
   it can't handle large records, please migrate to a diffrent backend
   (like BDB4)

Heimdal 1.3.0 and 1.3.1

It was over a year ago last release was made, today we have published 1.3.1. We already released 1.3.0 last week but was never announced it.

Here is summary of change that included in the release:

Major changes in 1.3.1

• Make work with OpenLDAPs krb5 overlay

Major changes in 1.3.0

• Partial support for MIT kadmind rpc protocol in kadmind


• Better support for finding keytab entries when using SPN aliases in the KDC


• Support BER in ASN.1 library (needed for CMS)


• Support decryption in Keychain private keys


• Support for new sqlite based credential cache


• Try both KDC referals and the common DNS reverse lookup in GSS-API


• Fix the KCM to not leak resources on failure


• Add IPv6 support to iprop


• Support localization of error strings in


• kinit/klist/kdestroy and Kerberos library


• Remove Kerberos 4 support in application (still in KDC)


• Deprecate DES


• Support i18n password in windows domains (using UTF-8)


• More complete API emulation of OpenSSL in hcrypto


• Support for ECDSA and ECDH when linking with OpenSSL

There are more changes in the patch train, and I assume that you all don't have to wait other year before 1.4 gets out

Release Notes - Heimdal - Version Heimdal 1.3.1

Bug fixes

- Make work with OpenLDAPs krb5 overlay

Release Notes - Heimdal - Version Heimdal 1.3

New features

- Partial support for MIT kadmind rpc protocol in kadmind

- Better support for finding keytab entries when using SPN aliases in the KDC

- Support BER in ASN.1 library (needed for CMS)

- Support decryption in Keychain private keys

- Support for new sqlite based credential cache

- Try both KDC referals and the common DNS reverse lookup in GSS-API

- Fix the KCM to not leak resources on failure

- Add IPv6 support to iprop

- Support localization of error strings in

kinit/klist/kdestroy and Kerberos library

- Remove Kerberos 4 support in application (still in KDC)

- Deprecate DES

- Support i18n password in windows domains (using UTF-8)

- More complete API emulation of OpenSSL in hcrypto

- Support for ECDSA and ECDH when linking with OpenSSL

API changes

- Support for settin friendly name on credential caches

- Move to using doxygen to generate documentation.

- Sprinkling __attribute__((depricated)) for old function to be removed

- Support to export LAST-REQUST information in AS-REQ

- Support for client deferrals in in AS-REQ

- Add seek support for krb5_storage.

- Support for split AS-REQ, first step for IA-KERB

- Fix many memory leaks and bugs

- Improved regression test

- Support krb5_cccol

- Switch to krb5_set_error_message

- Support krb5_crypto_*_iov

- Switch to use EVP for most function

- Use SOCK_CLOEXEC and O_CLOEXEC (close on exec)

- Add support for GSS_C_DELEG_POLICY_FLAG

- Add krb5_cc_[gs]et_config to store data in the credential caches

- PTY testing application

Bugfixes

- Make building on AIX6 possible.

- Bugfixes in LDAP KDC code to make it more stable

- Make ipropd-slave reconnect when master down gown

Using krb5_cc_[gs]et_config

Or how everything turned into a nail

Maybe this should be titled, how everything turned into a nail when I got a hammer. There are a couple of use cases I want to discuss first, and then why krb5_cc_[gs]et_config() isn't useable for everything.

First out is Windows, you just talked to a Windows AD KDC to get your TGT, but you need to do slight tweeks to make it work better on
Windows, so turn on insecure^HWindows behavior when we use this this credential cache. We make it up with a global setting using krb5_cc_[sg]_config().

Next thing that comes is negative caching of TGS requests (fetching service tickets). Now this seems very stupid to do, but for practical reason is not.

If you want to use HTTP Negotiate and have it default turned on in you http client, you can get bad behaviors in case of the webserver announces support for Negotiate and the client can't get service tickets for that realm. You don't want to have the performance loss of having to ask the KDC over and over again for the same ticket that you can't get.

The the state HTTP negotiate doesn't work should probably be in the http client instead, but sometimes that not possible, just think of running curl in a shell script and looping a couple of times, when you are tired enough of DNS timeouts, not answering KDC, referrals that doesn't lead anywhere, etc, you can let me know.

Third problem is ticket forwarding, it will get you into the same problem. If you want to do a lot of forwarding of your ticket, again maybe because of HTTP Negotiate, then you don't want to hit the KDC for every request. Again we can use krb5_cc_[gs]et_config to store the
forwarding credential for this entry.

So when is krb5_cc_[gs]et_config not useful

So when you renew your credentials you loose all your state, so if you want to keep your state you better store it somewhere else. So that said, having the Windows behavior flag in the krb5_cc_[gs]et_config is probably not good idea. There needs to be somewhere else that this kind of information is stored.

The use of of gss_accept_sec_context (ASC)

This is continuation of the previous article about ISC.

The gssapi function ASC (gss_accept_sec_context) is also complicated,
function, one can argue ASC is simpler then ISC since ASC only takes
11 arguments.

OM_uint32
gss_accept_sec_context
           (OM_uint32 * /*minor_status*/,
            gss_ctx_id_t * /*context_handle*/,
            const gss_cred_id_t /*acceptor_cred_handle*/,
            const gss_buffer_t /*input_token_buffer*/,
            const gss_channel_bindings_t /*input_chan_bindings*/,
            gss_name_t * /*src_name*/,
            gss_OID * /*mech_type*/,
            gss_buffer_t /*output_token*/,
            OM_uint32 * /*ret_flags*/,
            OM_uint32 * /*time_rec*/,
            gss_cred_id_t * /*delegated_cred_handle*/
           );

Again, just like ISC the main problem is that consumers if this interface tries to pass in too much information, less is usually better.

Not passing in a credential

If consumers instead of passing a credential checked the name afterward it would work in more situations. For example, using the GSSAPI Kerberos mech as an acceptor: when the client connects the server doesn't know what name the client used, and if the server specifies a credential (thus an implicitly a name) the client have selected another name, ASC will fail.

Do when do server and client not patch up on names ? There are plent of examples, where: HTTP/www, http/www.example.com is the one to start with. Kerberos is case sensitive and client might expect aliases to work.

The logic flow for ASC

The flow of a server part of gss-api negotiation looks like this:

in = null;
do {
   ret = gss_accept_sec_context(in, out);
   if (GSS_ERROR(ret))
      abort();
  send_message(out);
  if (ret == GSS_C_CONTINUE)
      in = read_message();
} while (ret == GSS_C_CONTINUE);

if (check_return_flags())
   abort();

if (check_that_name_is_ok(ctx))
   abort();

/* done */

Cross compiling Heimdal

We got some feedback that it would be good if it was possible to cross compile Heimdal and with some minor works that is now possible.

Its all documented at http://www.h5l.org/compile.html#cross, as usual libtool is somewhat in the way. The current problem that that libtool is not aware of the target's build environment, but it seems to work anyway. Oh well.

The code is all patch of master and will be in the soon to be release Heimdal 1.3.

The use of of gss_init_sec_context (ISC)

ISC

Lets start to dissect some of the GSS-API functions, first out in gss_init_sec_context (ISC for short).

The gssapi function ISC is a very complicated function, just look at the 13 arguments it takes, and for every round its call in an authentication some of them need to be same, and some need to change.

OM_uint32
gss_init_sec_context
           (OM_uint32 * /*minor_status*/,
            const gss_cred_id_t /*initiator_cred_handle*/,
            gss_ctx_id_t * /*context_handle*/,
            const gss_name_t /*target_name*/,
            const gss_OID /*mech_type*/,
            OM_uint32 /*req_flags*/,
            OM_uint32 /*time_req*/,
            const gss_channel_bindings_t /*input_chan_bindings*/,
            const gss_buffer_t /*input_token*/,
            gss_OID * /*actual_mech_type*/,
            gss_buffer_t /*output_token*/,
            OM_uint32 * /*ret_flags*/,
            OM_uint32 * /*time_rec*/
           );

In that 13 that lays the confusion, to make make ISC work you only need to pass in 7 arguments, you can leave the other 6 to a default values, in fact, this will probably make it work better in most cases.

gss_init_sec_context(&minor_status, GSS_C_NO_CREDENTIAL, &ctx, &target_name, GSS_C_NO_OID,
    GSS_C_MUTUAL_FLAG, GSS_C_INDEFINITE, GSS_C_NO_CHANNEL_BINDINGS, &in, NULL, &out, &ret_flags, NULL);

You need to check that ret_flags is what you wanted in flags, the reason is that the server might downgarde your security to a level you don't find acceptiable, like no encryption (leaving out GSS_C_CONF_FLAG).

The logic flow for ISC

The flow of a client part of gss-api negotiation looks like this:

name = gss_import_name("service@server", GSS_C_NT_HOSTBASED_SERVICE);

if (client_name && client_name_type) {
   cname = gss_import_name(client_name, client_name_type);
   cred = gss_acquire_cred(cname, GSS_C_INITIATE);
} else
   cred = NULL;

in = null;
do {
   ret = gss_init_sec_context(in, out);
   if (GSS_ERROR(ret))
      abort();
  send_message(out);
  if (ret == GSS_C_CONTINUE)
      in = read_message();
} while (ret == GSS_C_CONTINUE);

if (check_return_flags())
   abort();

/* done */

Next out is gss_accept_sec_context (ASC)

ASC is the awesome function, mostly every time we have to fix 3rd party code that uses ASC the resolution is mostly always to remove code