Here is summary of change that included in the release:

Major changes in 1.3.1

• Make work with OpenLDAPs krb5 overlay

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 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 */

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.

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

ECDH is turned used when using ECDSA, so also its also used when using EC certificates on the client. There is missing negotiation of EC curves, so the code is not future safe, but its something that we’ll add in the future.  Part of the regression test now uses the EC certificate. hxtool needs support for generating EC keys and exporting the SubjectPublicKeyInfo before its can sign certificates, neither of them too hard.

Too much of the OpenSSL EC implementation is hidden, so right now its not possible to load plugins. So no support for PKCS11 or Keychain based private keys.

kinit --anonymous REALM

What have been implemented is draft-ietf-krb-wg-anon-04.

At the same time support for enterprise names when using PK-INIT slipped it. This is very cool, just point a cert, and the kinit will search the cert for a windows nt-name, use that with a client referrals (enterprise name) and return you a ticket for your real principal name. The only problem is that right now windows 2008 DC doesn’t return client referrals PA-DATA, so that why we use –windows in the example below, it disable the client check.

kinit --windows --pk-enterprise --canon -C FILE:w2k8.pem WINDOWS2008.DOMAIN

The implementation show that the krb5_get_init_creds and friends need to be more aware PK-INIT and certificate selection. The reason the interface look the way it does is to avoid exposing that we are using hx509 beneath the kerberos library. So far I’ve not come up with a good langauge to express what certificate to select.

There is a query language in hx509, but its not something that you want to expose users too. Here are some examples:

%{certificate.issuer} == "C=SE,CN=hx509 Test Root CA"
%{certificate.subject} TAILMATCH "C=SE"
%{certificate.hash.sha1} EQ "412120212A2CBFD777DE5499ECB4724345F33F16"

Heimdal will show up for the Interop event in Redmond at the end of March, part of that we will do PK-INIT testing.

One things that really should be working by the is support for EC certificate and ECDSA, right now that support it not there in hx509 or hcrypto.

Some facts

The realm name we are going to use is EXAMPLE.ORG, the kdc is named kdc.example.org, the user is user@EXMAPLE.ORG.

Create the certificates needed

First we create the CA certificate. The create file ca.pem contains both private key and the certificate, you should make sure the private key is removed when distributing the certificate to clients and the KDC.

hxtool issue-certificate \
          --self-signed \
          --issue-ca \
          --generate-key=rsa \
          --subject="CN=CA,DC=example,DC=org" \
          --certificate="FILE:ca.pem"

Then the user’s certificate, here we add the PK-INIT options for a
PK-INIT client.

hxtool issue-certificate \
          --ca-certificate=FILE:ca.pem \
          --generate-key=rsa \
          --type="pkinit-client" \
          --pk-init-principal="user@EXAMPLE.ORG" \
          --subject="cn=user,DC=example,DC=org" \
          --certificate="FILE:user.pem"

Last we create the KDC’s certificate, here we add the PK-INIT options
for a PK-INIT client.

hxtool issue-certificate \
          --ca-certificate=FILE:ca.pem \
          --generate-key=rsa \
          --type="pkinit-kdc" \
          --pk-init-principal="krbtgt/EXAMPLE.ORG@EXAMPLE.ORG" \
          --subject="cn=kdc,DC=example,DC=org" \
          --certificate="FILE:kdc.pem"

Creating the database

Just for completeness we are including the setup of your KDC here

kadmin -l -r EXAMPLE.COM
kadmin> init EXAMPLE.ORG

Lets add our user to the database.

kadmin> add user
kadmin> modify --pkinit-acl=cn=user,DC=example,DC=org --attribute=+requires-pre-auth user

That all that needs to do to create the database and set up the user.

Setting up the KDC configuration

All KDC configuration is stored in /etc/krb5.conf (or /var/heimdal/kdc.conf), the content should contain this:

[kdc]
	enable-pkinit = true
	pkinit_identity = FILE:kdc.pem
	pkinit_anchors = FILE:ca.pem

Start the KDC

Start the KDC

/usr/heimdal/libexec/kdc --detach

Get tickets using PK-INIT

First we need to configure the trust anchors (what certificate authorities) to trust for the client.

[appdefaults]
	pkinit_anchors = FILE:ca.pem

Now we can get the ticket.

kinit -C FILE:user.pem user@EXAMPLE.COM

Talking to the KDC with no network

Sometimes you want to talk to the KDC when there is limited or direct network. Or your application simply knows better how to communicate with the KDC.

For example, if it was possible to use EAP with GSS-API so it run Kerberos initial ticket fetching over the EAP channel, this is not so far off given the new IAKERB gss-api mechanism that Larry Zhu is proposing (currently in last call). With his mechanism you can talk to the KDC and get initial and service tickets for a service over a gss-api channel.

First the when you login to the network using EAP the network topology looks like this:

Client ---[EAP over wavelan]---> Wavelan access point ---[radius]---> Radius server

First you authenticate to the radius server, and the radius server tells the access point to let you out on the network, and then you get a IP address from the DHCP server. So why doesn’t this fit together with the Kerberos stack.

In the classial appliation the world looks like this:

Application -> GSS-API -> Kerberos mechanism <--[Kerberos protocol]--> KDC
                 |
              [token]
                 |
  appl <---------/
   |
   |
   \
    ------[application protocol]---->  server

But when you are in an about to use EAP to login to the network, theKerberos mechanism have no way to talk to the KDC, the only channel you have EAP the channel to the Radius server.

So the obvious solution is to let the Kerberos mechanism talk though the EAP channel over the the Radius server, and have the radius server forward over the packets over the the KDC.

The problem with Kerberos krb5_get_init_creds()

The Kerberos function krb5_get_init_creds() is that it expect to be able to resolve the DNS information to the KDC and then talk to the KDC to get initial tickets, so deep inside the function there is a function that will send of a packet the the KDC.

As described above, this wont work since the Kerberos library have no network connection to the KDC, it have to talk to the KDC thought the GSS-API layer.

The replacement function, krb5_init_creds()

So the new function krb5_init_creds() and krb5_init_creds_step() instead of sending of the packet to the KDC, return the packet that is supposed to be sent off to the KDC, and the expect the caller to call
krb5_init_creds_step() with whatever the KDC returned. There is a helper function that does all this: krb5_init_creds_get().

So krb5_get_init_creds_password() is now implmented in terms of the new functions. And is as described below.

krb5_get_init_creds_password()
{
   krb5_init_creds_init(&ctx);
   krb5_init_creds_get(ctx);
   krb5_init_creds_free(ctx);
}

krb5_init_creds_get(ctx)
{
    while(1) {
       ret = krb5_init_creds_step(ctx,inpacket, &outpacket);
       if (ret != CONTINUE)
         break;
       krb5_send_to_kdc(outnpacket, &inpacket);
    }
}

GSS-API usage of krb5_init_creds_step()

This way GSS-API mech can take advantage of the split stack and instead of sending the packet to the KDC, send of the packet over to GSS-API peer and when it get back the reply, stuff the answer back into krb5_init_creds_step() to continue the dance. 

Application -> GSS-API <–> Kerberos mechanism

                 |
              [token]
                 |
  appl <---------/
   |
   |
   \
    ------[application protocol]---->  server <--[Kerberos protocol]--> KDC

Now, someone just need to implement IAKERB to use this functionallity.

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