hx509 and hcrypto

hx509 and hcrypto have both in the last two months been given an overhaul and are now self bootstraping. Needless to say, neither of the two packages are perfect, but we are getting to closer to same level of functionality as the rest of the Heimdal suite of applications and libraries.

hxtool can now both read and create PEM and PKCS11 files containing both certificates and private keys. Neither of formats will end up containing encrypted keys (ie shrouded PKCS8 keys), so that is a feature that must be added.

And talking about private keys, hcrypto now uses RSA key blinding and CRT for private key operations, makes quite a lot difference in performance and security. I also added RSA key generation, that is really the last two missing bits that makes hcrypto useful.

The coolest feature is also the most basic in the X.509 world. libhx509 and hxtool now can print certificates. It would be boastful to call is a CA software because some important tools are not there yet, for example a CRL and OSCP generation tools and certificate store handling.

There is two reason why I wrote this extension to hx509. First reason was I wanted a simple way to setup a PK-INIT realm and using OpenSSL as a CA only causes pain for most users, its very hard to get the generated certificates right and openssl lets you get away with it too. Second reason is that I needed a simple way to generate certificates for another part of Heimdal, kca (more about that later).

What hxtool do for us then ? It will let you issue certificates with a simple interface using default templates.

To generate a CA certifiate with RSA key that is valid for 10 years, this is the command you would use.

hxtool issue-certificate \
    --self-signed \
    --issue-ca \
    --generate-key=rsa \
    --subject="CN=CA,DC=h5l,DC=se" \
    --lifetime=10years \
    --certificate="FILE:ca.pem"

Now you have a CA certificate with its private key in the PEM file ca.pem. Now you say, what makes this hx509 so much simpler to use then OpenSSL. The answer is the default values and builtin profiles, let take the example with the KDC PK-INIT certificate. It needs to have this EKU (extended key usage) and a special SAN (Subject Alternative Name) for PK-INIT. hxtool will help you generate that certificate with some simple command options, it wont give you total control over the certificate creation process, but for most users that is not really interesting, they just want to have certificates.

hxtool issue-certificate \
    --ca-certificate=FILE:ca.pem \
    --generate-key=rsa \
    --type="pkinit-kdc" \
    --pk-init-principal="krbtgt/H5L.SE@H5L.SE" \
    --subject="uid=kdc,DC=h5l,DC=se" \
    --certificate="FILE:kdc.pem"

Writing a certificate issuing code when you have a X509 verifier, a crypto library and a sane ASN.1 compiler is very simple. It took me about 3 days from no code to a somewhat working software, now, 12 days later while also working with other thing, its good enough to tell people about it.

Next item will be to write a sane manual how to use this software. Since hxtool is such a small tool the manual will be short too, it will be another texinfo manual about how to use hxtool to serve your basic CA needs. Creating a CA and issueing certificates to user and services.

There will always be missing functionallity to hx509, the PKIX people have started to write standard too long ago for me to catch up.

kdigest

For some time now I've been working on a new subsystem in the KDC for remotely validating digest credentials for a user. Right now it support CHAP (MD5), SASL DIGEST-MD5, HTTP DIGEST and NTLM (version 1 and 2)

It allows a server to validate a users digest without knowing the password directly, it can delegate the authentication to the KDC.

A coworker of mine used to build a proof-of-concept patch till the radius server Radiator that uses the new digest protocol to support the EAP-CHAP mechanism.

The digest protocol also support sending back Kerberos credentials in the protocol, so for example a WEB-DAV server using HTTP digest authentication can get an AFS ticket back that it can use to authenticate to AFS. This way the user limited service ticket (not the full KRBTGT) will get exposed to service, and only services that the user actually authenticated too.

The NTLM authentication is a slight different beast. After the context exchange (The NTLM type 1, 2 and 3 packets) the KDC sends back the session key material (if that was negotiated) to the server. This way the server also can provide session security to the client without dealing with the KDC any more. To test this I wrote a GSS-API mechanism that looks like the NTLMSSP in SSPI, it support both initiators and acceptors, session security. It was really really useful to debug SPNEGO so it have defiantly served its purpose even if it never will get used.

The interface is exposed in the library as the krb5_digest and the krb5_ntlm interfaces, its not a very large interface and it only uses opaque data types to enable us to add new digest types in the future. There is also a binary, <b>kdigest</b> that let the server access this from a shell/Perl script without interfacing with any c-code.

Status of Heimdal and Samba integration

After more then a year of hard work from me, Andrew Bartlett and the rest of the samba folks we have finally merged all major changes from the Samba tree into Heimdal. The diff between the two tree are now less the 400 lines which is nothing compare to the 50000+ line diff that we ended up with from the begining.

Heimdal have grown itself new subsystem, the PAC handling, and hooks for processing in other application and improvements to GSS-API.

In the future I'll work on canonicaliztion since this is the next big item. It already exists in the KDC and Kerberos library today, but it needs to expanded to support all the new functionallity that a domain controller require. To be able to support this I'll need to a large regression test to test how the canonicalization actully works in Windows and along with that come many new tests how Windows deals with Kerberos.