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)
Visar inlägg med etikett Heimdal. Visa alla inlägg
Visar inlägg med etikett Heimdal. Visa alla inlägg
söndag 2 oktober 2011
lördag 21 november 2009
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
Major changes in 1.3.0
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
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
torsdag 5 november 2009
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.
måndag 28 september 2009
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.
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.
lördag 14 februari 2009
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.
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.
torsdag 5 februari 2009
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.
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.
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:
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.
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.
fredag 9 januari 2009
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.
The realm name we are going to use is EXAMPLE.ORG, the kdc is named kdc.example.org, the user is user@EXMAPLE.ORG.
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.
Then the user's certificate, here we add the PK-INIT options for a
PK-INIT client.
Last we create the KDC's certificate, here we add the PK-INIT options
for a PK-INIT client.
Just for completeness we are including the setup of your KDC here
Lets add our user to the database.
That all that needs to do to create the database and set up the user.
All KDC configuration is stored in /etc/krb5.conf (or /var/heimdal/kdc.conf), the content should contain this:
Start the KDC
First we need to configure the trust anchors (what certificate authorities) to trust for the client.
Now we can get the ticket.
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
torsdag 25 december 2008
Fetching tickets over EAP
Or how to talk to the Kerberos KDC over your appliation protocol
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:
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:
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 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.
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.
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
Now, someone just need to implement IAKERB to use this functionallity.
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.
lördag 25 oktober 2008
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.
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.
- 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.
söndag 12 oktober 2008
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.
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.
söndag 5 oktober 2008
Do you want Heimdal to speak Swedish to you ?
As part of Heimdal 1.3 we have been adding i18n support to the base libraries and some of the Kerberos user utilites using GNU Gettext. It should also work with other localization packages like the MacOS X CoreFoundation's CFCopyLocalizedString with some minor code hacking.
We that work on Heimdal only know Swedish and English, so can can help translate the error strings. You don't need to download special tool, just go to Heimdal at launchpad and you translate the strings there. Just let us know that you have started to do the work so that we will remember to download your translations before release (or when you want to sync to you can test how it feels to get heimdal in your language.
We that work on Heimdal only know Swedish and English, so can can help translate the error strings. You don't need to download special tool, just go to Heimdal at launchpad and you translate the strings there. Just let us know that you have started to do the work so that we will remember to download your translations before release (or when you want to sync to you can test how it feels to get heimdal in your language.
söndag 21 september 2008
PKINIT works with Samba4 + windows XP
Today we got a patch from Sho Hosoda that add back the Windows XP SP2 support to Heimdal PK-INIT support. With this we can use smart cards to logins a Samba4 domain, this is way cool and why we started this work several years ago.
http://www.h5l.org/fisheye/changelog/heimdal/?cs=23861
http://www.h5l.org/fisheye/changelog/heimdal/?cs=23861
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.
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)