tag:blogger.com,1999:blog-43882385022558864842024-03-12T19:30:07.999-07:00HeimdalLove Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.comBlogger27125tag:blogger.com,1999:blog-4388238502255886484.post-21063135302196673992011-10-02T10:16:00.000-07:002011-10-02T10:16:00.423-07:00Heimdal 1.5 and 1.5.1<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">Release Notes - Heimdal - Version Heimdal 1.5</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">New features</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"> - Support GSS name extensions/attributes</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"> - SHA512 support</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"> - No Kerberos 4 support</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"> - Basic support for MIT Admin protocol (SECGSS flavor)</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"> in kadmind (extract keytab)</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"> - Replace editline with libedit</div><br />
Release Notes - Heimdal - Version Heimdal 1.5.1<br />
<br />
Bug fixes<br />
- Fix building on Solaris, requires c99<br />
- Fix building on Windows<br />
- Build system updates<br />
<br />
<br />
<a href="http://www.h5l.org/dist/src/heimdal-1.5.1.tar.gz">http://www.h5l.org/dist/src/heimdal-1.5.1.tar.gz</a>Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com1tag:blogger.com,1999:blog-4388238502255886484.post-12883347856414437452011-10-02T10:14:00.000-07:002011-10-02T10:14:33.434-07:00Heimdal 1.4Release Notes - Heimdal - Version Heimdal 1.4<br />
<br />
New features<br />
<br />
- Support for reading MIT database file directly<br />
- KCM is polished up and now used in production<br />
- NTLM first class citizen, credentials stored in KCM<br />
- Table driven ASN.1 compiler, smaller!, not enabled by default<br />
- Native Windows client support<br />
<br />
Notes<br />
<br />
- Disabled write support NDBM hdb backend (read still in there) since<br />
it can't handle large records, please migrate to a diffrent backend<br />
(like BDB4)Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-70317987092100658602009-11-21T08:21:00.000-08:002011-10-02T10:09:33.363-07:00Heimdal 1.3.0 and 1.3.1It 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.<br/><br/>Here is summary of change that included in the release:<br/><br/><strong>Major changes in 1.3.1</strong><br/><br/><span style="font-family: Tahoma, sans-serif; line-height: 16px; font-size: small;"><br/><ul><br/> <li>Make work with OpenLDAPs krb5 overlay</li><br/></ul><br/></span><br/><br/><span style="font-family: Tahoma, sans-serif; line-height: 16px; font-size: small;"><br/><div class="action unit"><br/><div id="1.3.0" class="install-description" style="display: block;"><br/><br/><strong>Major changes in 1.3.0</strong><br/><ul><br/> <li>Partial support for MIT kadmind rpc protocol in kadmind</li><br/> <li>Better support for finding keytab entries when using SPN aliases in the KDC</li><br/> <li>Support BER in ASN.1 library (needed for CMS)</li><br/> <li>Support decryption in Keychain private keys</li><br/> <li>Support for new sqlite based credential cache</li><br/> <li>Try both KDC referals and the common DNS reverse lookup in GSS-API</li><br/> <li>Fix the KCM to not leak resources on failure</li><br/> <li>Add IPv6 support to iprop</li><br/> <li>Support localization of error strings in</li><br/> <li>kinit/klist/kdestroy and Kerberos library</li><br/> <li>Remove Kerberos 4 support in application (still in KDC)</li><br/> <li>Deprecate DES</li><br/> <li>Support i18n password in windows domains (using UTF-8)</li><br/> <li>More complete API emulation of OpenSSL in hcrypto</li><br/> <li>Support for ECDSA and ECDH when linking with OpenSSL</li><br/></ul><br/></div><br/>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</div><br/></span><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">Release Notes - Heimdal - Version Heimdal 1.3.1</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">Bug fixes</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Make work with OpenLDAPs krb5 overlay</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">Release Notes - Heimdal - Version Heimdal 1.3</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">New features</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Partial support for MIT kadmind rpc protocol in kadmind</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Better support for finding keytab entries when using SPN aliases in the KDC</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support BER in ASN.1 library (needed for CMS)</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support decryption in Keychain private keys</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support for new sqlite based credential cache</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Try both KDC referals and the common DNS reverse lookup in GSS-API</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Fix the KCM to not leak resources on failure</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Add IPv6 support to iprop</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support localization of error strings in</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">kinit/klist/kdestroy and Kerberos library</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Remove Kerberos 4 support in application (still in KDC)</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Deprecate DES</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support i18n password in windows domains (using UTF-8)</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- More complete API emulation of OpenSSL in hcrypto</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support for ECDSA and ECDH when linking with OpenSSL</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">API changes</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support for settin friendly name on credential caches</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Move to using doxygen to generate documentation.</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Sprinkling __attribute__((depricated)) for old function to be removed</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support to export LAST-REQUST information in AS-REQ</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support for client deferrals in in AS-REQ</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Add seek support for krb5_storage.</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support for split AS-REQ, first step for IA-KERB</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Fix many memory leaks and bugs</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Improved regression test</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support krb5_cccol</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Switch to krb5_set_error_message</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Support krb5_crypto_*_iov<span style="white-space: pre;"> </span></div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Switch to use EVP for most function</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Use SOCK_CLOEXEC and O_CLOEXEC (close on exec)</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Add support for GSS_C_DELEG_POLICY_FLAG</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Add krb5_cc_[gs]et_config to store data in the credential caches</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- PTY testing application</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">Bugfixes</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Make building on AIX6 possible.</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Bugfixes in LDAP KDC code to make it more stable</div><br/><div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">- Make ipropd-slave reconnect when master down gown</div>Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-18481161048998955442009-11-05T17:44:00.000-08:002011-10-02T10:09:33.363-07:00Using krb5_cc_[gs]et_config<h2>Or how everything turned into a nail</h2><br/>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 <a href="http://www.h5l.org/blog/index.php/2008/10/the-krb5-cc-gset-config-api/">krb5_cc_[gs]et_config()</a> isn't useable for everything.<br/><br/>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<br/>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().<br/><br/>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.<br/><br/>If you want to use <a href="http://www.rfc-editor.org/rfc/rfc4559.txt">HTTP Negotiate</a> 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.<br/><br/>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 <a href="http://curl.haxx.se/">curl</a> 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.<br/><br/>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<br/>forwarding credential for this entry.<br/><h2>So when is krb5_cc_[gs]et_config not useful</h2><br/>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.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-49077913039254408872009-10-05T18:40:00.000-07:002011-10-02T10:09:33.363-07:00The use of of gss_accept_sec_context (ASC)This is continuation of the <a href="http://www.h5l.org/blog/index.php/2009/09/the-use-of-of-gss_init_sec_context-isc/">previous article about ISC</a>.<br/><br/>The gssapi function ASC (gss_accept_sec_context) is also complicated,<br/>function, one can argue ASC is simpler then ISC since ASC only takes<br/>11 arguments.<br/><pre>OM_uint32<br/>gss_accept_sec_context<br/> (OM_uint32 * /*minor_status*/,<br/> gss_ctx_id_t * /*context_handle*/,<br/> const gss_cred_id_t /*acceptor_cred_handle*/,<br/> const gss_buffer_t /*input_token_buffer*/,<br/> const gss_channel_bindings_t /*input_chan_bindings*/,<br/> gss_name_t * /*src_name*/,<br/> gss_OID * /*mech_type*/,<br/> gss_buffer_t /*output_token*/,<br/> OM_uint32 * /*ret_flags*/,<br/> OM_uint32 * /*time_rec*/,<br/> gss_cred_id_t * /*delegated_cred_handle*/<br/> );</pre><br/>Again, just like ISC the main problem is that consumers if this interface tries to pass in too much information, less is usually better.<br/><h2>Not passing in a credential</h2><br/>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.<br/><br/>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.<br/><h2>The logic flow for ASC</h2><br/>The flow of a server part of gss-api negotiation looks like this:<br/><pre>in = null;<br/>do {<br/> ret = gss_accept_sec_context(in, out);<br/> if (GSS_ERROR(ret))<br/> abort();<br/> send_message(out);<br/> if (ret == GSS_C_CONTINUE)<br/> in = read_message();<br/>} while (ret == GSS_C_CONTINUE);<br/><br/>if (check_return_flags())<br/> abort();<br/><br/>if (check_that_name_is_ok(ctx))<br/> abort();<br/><br/>/* done */</pre>Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-8707477144417295242009-09-28T02:55:00.000-07:002011-10-02T10:09:33.364-07:00Cross compiling HeimdalWe got some <a href="http://article.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/4782">feedback</a> that it would be good if it was possible to cross compile Heimdal and with some minor works that is now possible.<br/><br/>Its all documented at <a href="http://www.h5l.org/compile.html#cross">http://www.h5l.org/compile.html#cross</a>, 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.<br/><br/>The code is all patch of master and will be in the soon to be release Heimdal 1.3.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-38409667348096511772009-09-05T13:02:00.000-07:002011-10-02T10:09:33.364-07:00The use of of gss_init_sec_context (ISC)<h2>ISC</h2><br/>Lets start to dissect some of the GSS-API functions, first out in gss_init_sec_context (ISC for short).<br/><br/>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.<br/><pre>OM_uint32<br/>gss_init_sec_context<br/> (OM_uint32 * /*minor_status*/,<br/> const gss_cred_id_t /*initiator_cred_handle*/,<br/> gss_ctx_id_t * /*context_handle*/,<br/> const gss_name_t /*target_name*/,<br/> const gss_OID /*mech_type*/,<br/> OM_uint32 /*req_flags*/,<br/> OM_uint32 /*time_req*/,<br/> const gss_channel_bindings_t /*input_chan_bindings*/,<br/> const gss_buffer_t /*input_token*/,<br/> gss_OID * /*actual_mech_type*/,<br/> gss_buffer_t /*output_token*/,<br/> OM_uint32 * /*ret_flags*/,<br/> OM_uint32 * /*time_rec*/<br/> );</pre><br/>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.<br/><pre>gss_init_sec_context(&minor_status, GSS_C_NO_CREDENTIAL, &ctx, &target_name, GSS_C_NO_OID,<br/> GSS_C_MUTUAL_FLAG, GSS_C_INDEFINITE, GSS_C_NO_CHANNEL_BINDINGS, &in, NULL, &out, &ret_flags, NULL);</pre><br/>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).<br/><h2>The logic flow for ISC</h2><br/>The flow of a client part of gss-api negotiation looks like this:<br/><pre>name = gss_import_name("service@server", GSS_C_NT_HOSTBASED_SERVICE);<br/><br/>if (client_name && client_name_type) {<br/> cname = gss_import_name(client_name, client_name_type);<br/> cred = gss_acquire_cred(cname, GSS_C_INITIATE);<br/>} else<br/> cred = NULL;<br/><br/>in = null;<br/>do {<br/> ret = gss_init_sec_context(in, out);<br/> if (GSS_ERROR(ret))<br/> abort();<br/> send_message(out);<br/> if (ret == GSS_C_CONTINUE)<br/> in = read_message();<br/>} while (ret == GSS_C_CONTINUE);<br/><br/>if (check_return_flags())<br/> abort();<br/><br/>/* done */</pre><br/><h2>Next out is gss_accept_sec_context (ASC)</h2><br/>ASC is the awesome function, mostly every time we have to fix 3rd party code that uses ASC the resolution is mostly always to <strong>remove</strong> codeLove Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com1tag:blogger.com,1999:blog-4388238502255886484.post-4830891431787652312009-02-14T12:31:00.000-08:002011-10-02T10:09:33.364-07:00Support for ECDSA and ECDH in PK-INITHeimdal 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.<br/><br/>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.<br/><br/>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.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-40648812198349059512009-02-05T19:04:00.000-08:002011-10-02T10:09:33.364-07:00New PKINIT bits, anonymous and enterprise supportI've just added <strong>anonymous Kerberos/pkinit</strong> to the KDC and the client libraries. Still only AS-REQ, what is missing is TGS-REQ and GSS-API support.<br/><pre>kinit --anonymous REALM</pre><br/>What have been implemented is <a href="tools.ietf.org/id/draft-ietf-krb-wg-anon-04">draft-ietf-krb-wg-anon-04</a>.<br/><br/>At the same time support for <strong>enterprise names when using PK-INIT </strong>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.<br/><pre>kinit --windows --pk-enterprise --canon -C FILE:w2k8.pem WINDOWS2008.DOMAIN</pre><br/>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.<br/><br/>There is a query language in hx509, but its not something that you want to expose users too. Here are some examples:<br/><pre>%{certificate.issuer} == "C=SE,CN=hx509 Test Root CA"<br/>%{certificate.subject} TAILMATCH "C=SE"<br/>%{certificate.hash.sha1} EQ "412120212A2CBFD777DE5499ECB4724345F33F16"</pre><br/>Heimdal will show up for the Interop event in Redmond at the end of March, part of that we will do PK-INIT testing.<br/><br/>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.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com1tag:blogger.com,1999:blog-4388238502255886484.post-38901385470088112312009-01-09T21:51:00.000-08:002011-10-02T10:09:33.364-07:00Setting up PK-INIT with HeimdalSetting 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.<br/><h3>Some facts</h3><br/>The realm name we are going to use is <strong>EXAMPLE.ORG<span style="font-weight: normal;">, the kdc is named </span><strong>kdc.example.org</strong><span style="font-weight: normal;">, the user is </span><strong>user@EXMAPLE.ORG</strong>.</strong><br/><h3>Create the certificates needed</h3><br/><span style="font-weight: normal;">First we create the CA certificate. The create file ca.pem contains both </span><span style="font-weight: normal;">private key and the certificate</span><span style="font-weight: normal;">, you should make sure the private key is removed when distributing the certificate to clients and the KDC.</span><br/><pre>hxtool issue-certificate \<br/> --self-signed \<br/> --issue-ca \<br/> --generate-key=rsa \<br/> --subject="CN=CA,DC=example,DC=org" \<br/> --certificate="FILE:ca.pem"</pre><br/><span style="font-weight: normal;">Then the user's certificate, here we add the PK-INIT options for a<br/>PK-INIT client.</span><br/><pre>hxtool issue-certificate \<br/> --ca-certificate=FILE:ca.pem \<br/> --generate-key=rsa \<br/> --type="pkinit-client" \<br/> --pk-init-principal="user@EXAMPLE.ORG" \<br/> --subject="cn=user,DC=example,DC=org" \<br/> --certificate="FILE:user.pem"</pre><br/><span style="font-weight: normal;">Last we create the KDC's certificate, here we add the PK-INIT options<br/>for a PK-INIT client.</span><br/><pre>hxtool issue-certificate \<br/> --ca-certificate=FILE:ca.pem \<br/> --generate-key=rsa \<br/> --type="pkinit-kdc" \<br/> --pk-init-principal="krbtgt/EXAMPLE.ORG@EXAMPLE.ORG" \<br/> --subject="cn=kdc,DC=example,DC=org" \<br/> --certificate="FILE:kdc.pem"</pre><br/><h3>Creating the database</h3><br/><span style="font-weight: normal;">Just for completeness we are including the setup of your KDC here</span><br/><pre>kadmin -l -r EXAMPLE.COM<br/>kadmin> init EXAMPLE.ORG</pre><br/><span style="font-weight: normal;">Lets add our user to the database.</span><br/><pre>kadmin> add user<br/>kadmin> modify --pkinit-acl=cn=user,DC=example,DC=org --attribute=+requires-pre-auth user</pre><br/><span style="font-weight: normal;">That all that needs to do to create the database and set up the user.</span><br/><h3>Setting up the KDC configuration</h3><br/><span style="font-weight: normal;">All KDC configuration is stored in /etc/krb5.conf (or /var/heimdal/kdc.conf), the content should contain this:</span><br/><pre>[kdc]<br/> enable-pkinit = true<br/> pkinit_identity = FILE:kdc.pem<br/> pkinit_anchors = FILE:ca.pem</pre><br/><h3>Start the KDC</h3><br/><span style="font-weight: normal;">Start the KDC</span><br/><pre>/usr/heimdal/libexec/kdc --detach</pre><br/><h3>Get tickets using PK-INIT</h3><br/><span style="font-weight: normal;">First we need to configure the trust anchors (what certificate authorities) to trust for the client.</span><br/><pre>[appdefaults]<br/> pkinit_anchors = FILE:ca.pem</pre><br/><span style="font-weight: normal;">Now we can get the ticket.</span><br/><pre>kinit -C FILE:user.pem user@EXAMPLE.COM</pre>Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-87982456901757823312008-12-25T07:00:00.000-08:002011-10-02T10:09:33.365-07:00Fetching tickets over EAPOr how to talk to the Kerberos KDC over your appliation protocol<br/><h2>Talking to the KDC with no network</h2><br/>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.<br/><br/>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.<br/><br/>First the when you login to the network using EAP the network topology looks like this:<br/><pre>Client ---[EAP over wavelan]---> Wavelan access point ---[radius]---> Radius server</pre><br/>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.<br/><br/>In the classial appliation the world looks like this:<br/><pre>Application -> GSS-API -> Kerberos mechanism <--[Kerberos protocol]--> KDC<br/> |<br/> [token]<br/> |<br/> appl <---------/<br/> |<br/> |<br/> \<br/> ------[application protocol]----> server</pre><br/>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.<br/><br/>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.<br/><h2>The problem with Kerberos krb5_get_init_creds()</h2><br/>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.<br/><br/>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.<br/><h2>The replacement function, krb5_init_creds()</h2><br/>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<br/>krb5_init_creds_step() with whatever the KDC returned. There is a helper function that does all this: krb5_init_creds_get().<br/><br/>So krb5_get_init_creds_password() is now implmented in terms of the new functions. And is as described below.<br/><pre>krb5_get_init_creds_password()<br/>{<br/> krb5_init_creds_init(&ctx);<br/> krb5_init_creds_get(ctx);<br/> krb5_init_creds_free(ctx);<br/>}<br/><br/>krb5_init_creds_get(ctx)<br/>{<br/> while(1) {<br/> ret = krb5_init_creds_step(ctx,inpacket, &outpacket);<br/> if (ret != CONTINUE)<br/> break;<br/> krb5_send_to_kdc(outnpacket, &inpacket);<br/> }<br/>}</pre><br/><h2>GSS-API usage of krb5_init_creds_step()</h2><br/>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. <br/><br/><span style="font-family: 'Courier New'; line-height: 18px; white-space: pre;">Application -> GSS-API <--> Kerberos mechanism</span><br/><pre> |<br/> [token]<br/> |<br/> appl <---------/<br/> |<br/> |<br/> \<br/> ------[application protocol]----> server <--[Kerberos protocol]--> KDC</pre><br/>Now, someone just need to implement IAKERB to use this functionallity.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-8119493183229875852008-10-25T21:15:00.000-07:002011-10-02T10:09:33.365-07:00The krb5-cc-[gs]et-config APII've created a new API to the krb5_ functions, its for storing Kerberos related data in the credential cache.<br/><ul><br/> <li>Realm configuration that is fetched runtime, for that the target is a domain that only should have Kerberos canonlization done and not dns canonlization</li><br/> <li>Forwarded tickets, to avoid re-fetching the from the KDC</li><br/></ul><br/><a href="http://www.h5l.org/manual/HEAD/krb5/group__krb5__ccache.html#g89f51b75326b1119ed104c329c8aa66f">krb5_cc_get_config</a><br/><a href="http://www.h5l.org/manual/HEAD/krb5/group__krb5__ccache.html#g9218c86e2fdea6c7e7b6a81ed8a8eb08">krb5_is_config_principal</a><br/><a href="http://www.h5l.org/manual/HEAD/krb5/group__krb5__ccache.html#gf58b1c3a297bda69c7a69be4679a684e">krb5_cc_set_config</a><br/><br/>There is a patch for MIT Kerberos that also includes this interface, so hopefully it will be included in MIT Kerberos 1.7.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-73157138430288288522008-10-19T14:33:00.000-07:002011-10-02T10:09:33.365-07:00ok-as-delegate and GSS-API<h2>Background</h2><br/>To forward your Kerberos credential from a gss-api client to a server you turn on the flag <strong>GSS_C_DELEG_FLAG</strong>. This will, as part of the authentication, forward your tickets to the server.<br/><br/>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.<br/><br/>To solve this Microsoft added an extention to the Kerberos, that was added to RFC4120 (The Kerberos protocol RFC). The extention is called <strong>ok-as-delegate</strong> 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.<br/><br/>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.<br/><br/>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.<br/><h2>New flag</h2><br/>What we can do it introduce a new flag <strong>GSS_C_DELEG_POLICY_FLAG</strong> that is defined to honor the flag ok-as-delegate.<br/><br/>The flag <strong>GSS_C_DELEG_POLICY_FLAG</strong> is a local flag that is never seen on the wire. And, its only used by the initator, the acceptor never see the flag.<br/><br/>There are four cases where GSS_C_DELEG_POLICY_FLAG and GSS_C_DELEG_FLAG interact with each other and the resulting return flags.<br/><ul><br/> <li>Neither flag set<br/>do nothing with regard to delegation</li><br/> <li>GSS_C_DELEG_FLAG set<br/>always try go delegate and set GSS_C_DELEG_FLAG in the return flags if successful</li><br/> <li>GSS_C_DELEG_POLIY_FLAG set<br/>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</li><br/> <li>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.</li><br/></ul><br/><h2>Cross realm ?</h2><br/>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.<br/><br/>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.<br/><br/>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.<br/><br/>Any good ideas out there ?Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com3tag:blogger.com,1999:blog-4388238502255886484.post-68744672912153441722008-10-12T16:57:00.000-07:002011-10-02T10:09:33.365-07:00DES will die in Heimdal 1.3A long long time ago <a href="http://en.wikipedia.org/wiki/Data_Encryption_Standard">DES</a> was standardized (1973, before I was born). Some 30 years later (2003) is was withdrawn as a standard by <a href="http://www.nist.gov/">NIST</a>, today 5 years later, its time for DES to finally die. Last year you could brute force DES in <strong>6.4 days</strong> by <a href="http://www.hyperelliptic.org/tanja/SHARCS/talks06/copacobana.pdf">buying a machine</a> for $10000. So last year was the time for you to migrate to better encryption types for your Kerberos realm.<br/><br/>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 <a href="http://www.h5l.org/manual/heimdal-1-2-branch/info/heimdal.html#Configuration-file">your configuration file</a> 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.<br/><br/>Application that will stop working are old Kerberos 4 tools and telnet/telnetd.<br/><br/>Heimdal-1.3 will deprecate DES<br/><br/>PS there is an exception for <a href="http://www.openafs.org/">AFS</a> to allow it still to use DES encryption types.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com3tag:blogger.com,1999:blog-4388238502255886484.post-11549113548282769862008-10-05T16:52:00.000-07:002011-10-02T10:09:33.365-07:00Do 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 <a href="http://www.gnu.org/software/gettext/">GNU Gettext</a>. It should also work with other localization packages like the MacOS X CoreFoundation's <a href="http://developer.apple.com/documentation/CoreFoundation/Reference/CFBundleRef/Reference/reference.html#//apple_ref/c/macro/CFCopyLocalizedString">CFCopyLocalizedString</a> with some minor code hacking.<br/><br/>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 <a href="https://translations.launchpad.net/heimdal">Heimdal at launchpad</a> 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.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-19395880742737455102008-10-05T13:19:00.000-07:002011-10-02T10:09:33.365-07:00Adding support for referrals in GSS-APIWe can implement referrals support for Kerberos mk_req API or do it for GSS-API. For me its an easy choice, most consumers uses GSS-API, lets go for that.<br/><br/>DNS canonicalition happens when we pass in a <em>GSS_C_NT_HOSTBASED_SERVICE</em> based name into gss_import_name(), so its only that case we really need to care about. DNS canonlisation is done by krb5_sname_to_principal(), see documentation in <a href="http://www.h5l.org/manual/HEAD/krb5/group__krb5__principal.html">Heimdal trunk</a>.<br/><br/>The simple solution is that in gss_import_name() we the hostname to krb5_sname_to_principal(), instead we mark up the principal as <strong>magic-unresolved</strong>. Now there are some places where we should return the name in its native form, and that is after gss_init_sec_context() is done by gss_inquire_context(), and gss_canonicalize_name(). We also need to deal with these <strong>magic-unresolved</strong> names in gss_acquire_cred() and gss_export_name().<br/><br/>So lets go over the four cases when we have a <strong>magic-unresolved</strong>.<br/><br/>gss_init_sec_context(), we try first to get Kerberos credentials using TGS-REQ using the sort name and hope that its an valid alias, if no, we call back to the old way with krb5_sname_to_principal(). Right, we update the name in the context to what we used.<br/><br/>gss_acquire_cred() same thing here, first try literal, then krb5_sname_to_principal().<br/><br/>gss_inquire_context(), this is simple gss_init_sec_context() will have solve the problem for us, just copy out the string.<br/><br/>gss_canonicalize_name() here we don't have a chance, so I guess, we want to have the canonicalized name, so I used the krb5_sname_to_principal() to canonicalize the name.<br/><br/>So where to store this <strong>magic-unresolved</strong> bit ? Well it happens to be so that the Kerberos gss-api mech uses Kerberos principals (krb5_principal) so there no extra bit where we can save the info. So, instead we hook the krb5_principal name type field and misuse that. Any time we will export or use the principal, we'll convert back to <em>KRB5_NT_SRV_HST</em> that it would have been if we used krb5_sname_to_principal().Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-50445174417062508742008-09-27T07:11:00.000-07:002011-10-02T10:09:33.366-07:00Kerberos ticket extentionsLast Sunday I updated the draft <a href="http://tools.ietf.org/html/draft-lha-krb-wg-ticket-extensions">Kerberos ticket extensions</a> to version -02.<br/><br/>Ticket extentions are to enable PK-CROSS and other applications that want to send clear text data in the ticket between the KDC and the server.<br/><br/>The update included and extension to the Kerberos protocol, a much cleaner extention protocol wise, at the same time it requires update clients. The reason I did both was the comment from Ken Raeburn that though the new protocol was horrible (which it is) and Kerberos should stay pretty, so I made the protocol stay pretty.<br/><br/>There is still the issue with protection, may I just should just give up making it truly extensionally and just include a checksum using the same key as the Ticket.enc-data is encrypted with.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-58797621745132740622008-09-21T23:43:00.000-07:002011-10-02T10:09:33.366-07:00PKINIT works with Samba4 + windows XPToday 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.<br/><br/><a href="http://www.h5l.org/fisheye/changelog/heimdal/?cs=23861">http://www.h5l.org/fisheye/changelog/heimdal/?cs=23861</a>Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com1tag:blogger.com,1999:blog-4388238502255886484.post-63109531443208171452008-09-19T05:10:00.000-07:002011-10-02T10:09:33.366-07:00ReferralsThis is something I brough up at IETF72 in Dublin, Ireland.<br/><br/>Kerberos (in the non Microsoft world) have always used DNS map to Kerberos principals. Sam Hartman describes the issue more here: <a href="http://www.painless-security.com/blog/2008/08/krb-dns/">http://www.painless-security.com/blog/2008/08/krb-dns/</a><br/><br/>My idea doesn't come from how to secure Kerberos (I already know that using DNS is bad), it comes from how to make Kerberos useful for users in the transition. Having client configuration really sucks, its horrible and a really pain to upgrade, and when you think you solved it, someone installs a old krb5.conf that "have always worked" and was "needed for some reason I can't remember". The reason it worked was because they forced the client to not upgrade, and the reason is that they have a broken application that can't do the right thing. Do I sound bitter, well, kind of.<br/><br/>My idea is that the realm annouces in the krb5tgt that is support referrals and all entires are populated that the clients are supposed to be allowed to use. Ie, both <strong>host/shell@EXAMPLE.COM</strong> and <strong>host/shell.example.com@EXAMPLE.COM</strong> are in the Kerberos database. So when then user types in <em>ssh shell</em>, the library should just ignore that.<br/><br/>I've been experimenting with Heimdal to do this and have come some futher then when I talked at IETF with regard to practical problem.<br/><br/>First its hard to know what realm you are going to end up in, mostly because the interactions between name selection, dns canonlisation and referrals. The old way was simple:<br/><ol><br/> <li>host = getnamebyaddr(getaddrbyname(hosthost))</li><br/> <li>target = { service, host } @ getrealmforhost(host)</li><br/> <li>ticket = get-service-ticket(target)</li><br/></ol><br/>Using what the user provided seems simple.<br/><ol><br/> <li> target = { service, hostname } @ get-realm(client-tgt)</li><br/> <li> ticket = get-service-ticket(target)</li><br/> <li> if ticket == null and compat: then ticket = old-method(hostname)</li><br/> <li> use ticket</li><br/></ol><br/>where get-service-ticket is this:<br/><ol><br/> <li> tgt = get-tgt(client-principal)</li><br/> <li> service-ticket = tgs-req(tgt, target, [canon])</li><br/> <li> if (referrals(service-tkt)): then update(target, tgt = service-ticket), goto 2</li><br/> <li> return service-ticket</li><br/></ol><br/>So lets say we are the user <strong>foo@FOO.COM</strong> and we want to login to<br/>the machine <strong>shell</strong>.<br/><br/>shell (aka shell.foo.com) is really part of BAR.COM service and since FOO.COM's KDC knows that, its going to return a referral.<br/><br/>We are getting a referrals back, and the referral say that we should go to BAR.COM and what target principal to use.<br/><br/>In the AD world this is simple, all SPNs are part of the global catalog, so all KDC in the forest can figure out what the user really wanted. IN a pure Kerberos enviroment, its not that simple since this helicopter-view of the worlds doesn't exist. So in the pure environment we can't use short names when the short name is in another realm. We can only do hostname to realm mappings. Also note that the Global catalog on spans a forest, so in the multi-forest environment, Windows KDC also resolves to mapping full names into DNS names.<br/><br/>So a flag in the credential cache is probably a good idea to tell the client to turn off DNS-canon, but on the other hand, if the KDC turns on this flag, it also better support referrals and have a global view for its referral world if it want to support non-fqdn types of names.<br/><br/>Heimdal have had server referral for quite some time now, MIT Kerberos have not (they have it in the client though).Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com1tag:blogger.com,1999:blog-4388238502255886484.post-22994120394347842302008-09-15T08:09:00.000-07:002011-10-02T10:09:33.366-07:00GSS_C_DELEG_POLICY_FLAG and cross realmI've been working on the draft for GSS_C_DELEG_POLICY_FLAG lately. One thing I have added is th reason why we need this document. This was requested by reviewers.<br/><br/>Its for legacy deployments that can't update Kerberos today and can't/don't want to change behavior.<br/><div><br/><div>Getting the flag defined and the behavior clarified is only the first step of this process. The second is to make sure it works in the cross realm case too. The proposal I have is to make it an MUST that all intermediate cross realm tgt tickets also have ok-as-delegate flag set. It seems Microsoft does it that was and I've asked them if I've read their spec is correctly.</div><br/></div>Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com1tag:blogger.com,1999:blog-4388238502255886484.post-72530189366847058522007-09-21T15:00:00.000-07:002011-10-02T10:09:33.366-07:00gssmaestroI 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.<br/><br/> 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.<br/><br/>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.<br/><br/>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.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com1tag:blogger.com,1999:blog-4388238502255886484.post-83506676929397244722007-07-04T05:04:00.000-07:002011-10-02T10:09:33.367-07:00Symbol versioningI've started to add symbol versioning to heimdal libraries to avoid exporting symbols all over the place.<br/><br/> 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).<br/><br/> 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.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com3tag:blogger.com,1999:blog-4388238502255886484.post-36459833201113741122007-04-03T13:51:00.000-07:002011-10-02T10:09:33.367-07:00KDIGEST and Heimdal 0.8 release processIn the last few days me and Klas have worked on improving the KDC digest stuff. It will be used together with Radiator to provide <a title="EAPOL" href="http://en.wikipedia.org/wiki/Eapol">802.1X/EAPOL</a> 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.<br/><br/>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.<br/><br/>The <a title="Heimdal documentation" href="http://www.pdc.kth.se/heimdal/#documentation">info manual pages</a> have been cleaned up and now they are generated each night for the diffrent branches that I maintain. <a title="hx509 manual" href="http://www.h5l.se/manual/HEAD/info/hx509.html">hx509</a> 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).<br/><br/>After the Heimdal 0.8 release the CVS tree will be converted into <a title="Subversion homepage" href="http://subversion.tigris.org/">subversion</a> 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.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-26843653371310139372007-02-15T14:00:00.000-08:002011-10-02T10:09:33.367-07:00kcaNow that Heimdal can generate certificates I added <a title="kx509" href="http://www.kx509.org/">KCA</a> 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 <a title="umich kx509" href="http://www.citi.umich.edu/projects/kerb_pki/">KCA/kx509</a>.<br/><br/>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.<br/><pre>$ hxtool print FILE:template.pem<br/>cert: 0<br/>private key: yes<br/>issuer: "UID=${principal-name},DC=test,DC=h5l,DC=se"<br/>subject: "UID=${principal-name},DC=test,DC=h5l,DC=se"<br/>serial: 105CB1ACF89E6AFBDC6AF386684B9FEC652E3432<br/>keyusage: keyEncipherment, digitalSignature</pre><br/>Currently there is no client nor documentation, that will change soon.<br/><br/>Talking about manuals, now there are uptodate (regenerated several times a day) manuals for <a title="Manuals" href="http://www.pdc.kth.se/heimdal/#manuals">Heimdal and hx509</a>.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0tag:blogger.com,1999:blog-4388238502255886484.post-47538656218072401322007-01-11T14:00:00.000-08:002011-10-02T10:09:33.367-07:00hx509 and hcryptohx509 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.<br/><br/>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.<br/><br/>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.<br/><br/>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.<br/><br/>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).<br/><br/>What hxtool do for us then ? It will let you issue certificates with a simple interface using default templates.<br/><br/>To generate a CA certifiate with RSA key that is valid for 10 years, this is the command you would use.<br/><br/>hxtool issue-certificate \<br/> --self-signed \<br/> --issue-ca \<br/> --generate-key=rsa \<br/> --subject="CN=CA,DC=h5l,DC=se" \<br/> --lifetime=10years \<br/> --certificate="FILE:ca.pem"<br/><br/>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.<br/><br/>hxtool issue-certificate \<br/> --ca-certificate=FILE:ca.pem \<br/> --generate-key=rsa \<br/> --type="pkinit-kdc" \<br/> --pk-init-principal="krbtgt/H5L.SE@H5L.SE" \<br/> --subject="uid=kdc,DC=h5l,DC=se" \<br/> --certificate="FILE:kdc.pem"<br/><br/>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.<br/><br/>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.<br/><br/>There will always be missing functionallity to hx509, the PKIX people have started to write standard too long ago for me to catch up.Love Hörnquist Åstrandhttp://www.blogger.com/profile/11495057674217412023noreply@blogger.com0