Support for ECDSA and ECDH in PK-INIT

Heimdal now support support for ECDSA (Elliptic curve, signature mode) and ECDH (Elliptic curve, key exchange mode) when compiled with OpenSSL, no hcrypto support yet. Using ECDSA is turned on when using EC certificates, both the signature verification and CMS is done using EC certificate.

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.

New PKINIT bits, anonymous and enterprise support

I've just added anonymous Kerberos/pkinit to the KDC and the client libraries. Still only AS-REQ, what is missing is TGS-REQ and GSS-API support.

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.

Setting up PK-INIT with Heimdal

Setting up Heimdal with PK-INIT is very easy. Heimdal by itself contains all the tools so you can do the setup. We assume that you don't have CA when we do the setup.

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

Fetching tickets over EAP

Or how to talk to the Kerberos KDC over your appliation protocol

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.

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.