I have started to merge the Samba GSS-API change from Andrew Bartlet and Stefan Metzmacher. As part of that work I have completed most of the basic work of my clone of gssmaggot/gssmaster that David Christansson (Microsoft) have written.
The problem with gssmaster is that its not released in source-code format, so I wrote my own client (gssmask) and server (gssmaestro). gssmaestro is not as complete that I wish, but test most of the context and token functionallity in the gss-space.
I plan to use gssmask/gssmaestro to test with gssmaggot, this way I can make sure I don't break anything, and at the same time still work with Microsofts and MIT gssapi implementations. This is what we do for the interrop events, but usually with new and shiny code.
There is also a new regression test that uses the gssmask/gssmaestro test program in heimdal/tests/gss directory and its hooked up to the regular automake regression tests, so hopefully I wont break the basic gss-api functions ever again.
fredag 21 september 2007
onsdag 4 juli 2007
Symbol versioning
I've started to add symbol versioning to heimdal libraries to avoid exporting symbols all over the place.
This have some bad side effekts. As usual there is not just one format for the file. The gnu ld one is what I currently support, so I have to munch the gnu file and produce a flat-file too (for Mac OS X).
The other that is causing more problems is that its no longer possible to unit test internal functions, because libraries that no longer export those symbols. Right now I have no real solution to the problem. One is to build a library without symbol versoning and test with that. Other is to just build that module, but that doesn't work with libtool since libtool requires object files to be of the same type. Ie a object can't belong to a binary and a library at the same time. Beloning to to two library or two binaries are fine though. But building two files doesn't really appeal to me, I'm waiting long enough as it is already. Currently I just export the function and hope that consumers wont use them.
This have some bad side effekts. As usual there is not just one format for the file. The gnu ld one is what I currently support, so I have to munch the gnu file and produce a flat-file too (for Mac OS X).
The other that is causing more problems is that its no longer possible to unit test internal functions, because libraries that no longer export those symbols. Right now I have no real solution to the problem. One is to build a library without symbol versoning and test with that. Other is to just build that module, but that doesn't work with libtool since libtool requires object files to be of the same type. Ie a object can't belong to a binary and a library at the same time. Beloning to to two library or two binaries are fine though. But building two files doesn't really appeal to me, I'm waiting long enough as it is already. Currently I just export the function and hope that consumers wont use them.
tisdag 3 april 2007
KDIGEST and Heimdal 0.8 release process
In the last few days me and Klas have worked on improving the KDC digest stuff. It will be used together with Radiator to provide 802.1X/EAPOL login at Stockholm University. The interface now supports CHAP, MS-CHAP-V2 and SASL DIGEST-MD5 in addition to the NTLM versions. The only new system is MS-CHAP-V2 but I also changed the digest protocol from experience from the NTLM work.
Heimdal 0.8 release is progressing nicely (wrote code 22 out of 31 days in January), there is not much I feel needs to be fixed before the release and I've been working on portability fixes in addition to the KDIGEST work since the heimdal 0.8 branch was cut. There is some new functionallity on the HEAD that wont be in 0.8 release, like the Kerberos PRF, mainly because there have been no interop testing. That how valueable test vectors in RFCs are.
The info manual pages have been cleaned up and now they are generated each night for the diffrent branches that I maintain. hx509 needs some more text but is a good start, I'm starting to get concerted about the complexity of the hxtool issue-certificate tool, its should be simpler that it is but the X.509 folks have just dreamed up too many options and features. The manual pages (formated in mdoc) still needs to htmlized and published on the web, but that will have to wait util I find a good way to do it (ie part of the build system).
After the Heimdal 0.8 release the CVS tree will be converted into subversion tree and moved to Stockholm University and IT och Media, but because CVS is so bad for us, its mainly because of that subversion is faster to use for large repositories. I can't feel that changing to subversion is a downgrade, subversion doesn't give me O(1) time sandboxes (it provides O(1) branches, that doesn't help me, still need to check out the tree). I want to have a source code revision system, not a revisioned filesystem. Anyway, subversion will have to do for now.
Heimdal 0.8 release is progressing nicely (wrote code 22 out of 31 days in January), there is not much I feel needs to be fixed before the release and I've been working on portability fixes in addition to the KDIGEST work since the heimdal 0.8 branch was cut. There is some new functionallity on the HEAD that wont be in 0.8 release, like the Kerberos PRF, mainly because there have been no interop testing. That how valueable test vectors in RFCs are.
The info manual pages have been cleaned up and now they are generated each night for the diffrent branches that I maintain. hx509 needs some more text but is a good start, I'm starting to get concerted about the complexity of the hxtool issue-certificate tool, its should be simpler that it is but the X.509 folks have just dreamed up too many options and features. The manual pages (formated in mdoc) still needs to htmlized and published on the web, but that will have to wait util I find a good way to do it (ie part of the build system).
After the Heimdal 0.8 release the CVS tree will be converted into subversion tree and moved to Stockholm University and IT och Media, but because CVS is so bad for us, its mainly because of that subversion is faster to use for large repositories. I can't feel that changing to subversion is a downgrade, subversion doesn't give me O(1) time sandboxes (it provides O(1) branches, that doesn't help me, still need to check out the tree). I want to have a source code revision system, not a revisioned filesystem. Anyway, subversion will have to do for now.
torsdag 15 februari 2007
kca
Now that Heimdal can generate certificates I added KCA functionallity to the KDC. KCA is a service that allows you to convert your Kerberos ticket into a X.509 certificate that have the same lifetime as your ticket, its a Kerberosized CA, hence the name, KCA. The wire-protocol in Heimdal in compatible with the orignal KCA/kx509.
Heimdals KCA service is built into the KDC. To configure the service you need to give it a CA certificate to sign the requests with and a template certificate. The KDC will replace variables in the Subject DN in the template certificate, currently there is only one variable, ${principal-name}. This will change in the future when I manged to push in more info into the HDB, like the users real name.
Currently there is no client nor documentation, that will change soon.
Talking about manuals, now there are uptodate (regenerated several times a day) manuals for Heimdal and hx509.
Heimdals KCA service is built into the KDC. To configure the service you need to give it a CA certificate to sign the requests with and a template certificate. The KDC will replace variables in the Subject DN in the template certificate, currently there is only one variable, ${principal-name}. This will change in the future when I manged to push in more info into the HDB, like the users real name.
$ hxtool print FILE:template.pem
cert: 0
private key: yes
issuer: "UID=${principal-name},DC=test,DC=h5l,DC=se"
subject: "UID=${principal-name},DC=test,DC=h5l,DC=se"
serial: 105CB1ACF89E6AFBDC6AF386684B9FEC652E3432
keyusage: keyEncipherment, digitalSignature
Currently there is no client nor documentation, that will change soon.
Talking about manuals, now there are uptodate (regenerated several times a day) manuals for Heimdal and hx509.
torsdag 11 januari 2007
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.
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.
onsdag 10 januari 2007
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.
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.
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.
Prenumerera på:
Inlägg (Atom)