open-source cryptocard libraries

[Douglas E. Engert]

Troy Benjegerdes wrote:
> I have been talking to some people at Cryptocard, and it looks like they
> have finally gotten tired of handing out sample code to customers to do
> a one-off implementation of kerberos support, and decided they want to
> go ahead and release the libraries for the initializer as well as sample
> code for generating OTP's as open source. It's not clear what the actual
> liscence will be, but one of the goals seems to be the ability to have
> native cryptocard support released as part of MIT and Heimdal kerberos.
> 
> In my case, I'd like to support the KB-1 token, which has a secret AES
> key, known only to the token and the authentication server (in this case
> the KDC). There is also a shared secret seed value which is re-encrypted
> at every successfull authentication to generate the next seed value.
> The problem I can see at the moment, is that this requires that slave
> KDCs now be able to replicate the last seed value back to the master
> KDC. I could see this being a relatively minor hack to Heimdal's iprop
> protocol. How to do this with MIT kerberos seems a bit more .. messy..

The latest MIT has plugins, for preauth on both the client and KDC
sides, as well as DB plugins. The KDC can use LDAP. So it may not be as
messy as you think.

> 
> What thoughts do people have on this problem? Multi-master LDAP backends
> would provide an 'enterprise-class' backend, but something about putting
> critical secret keys in LDAP seems wrong to me.. In some cases it's
> necessary, but I would like to be able to implement two factor and
> replicated KDC's without having to resort to an LDAP backend to support
> it.
> 

There was a discussion on the IETF krb-wg mailing list last year on
whether the KDC knows the next OTP or if it request an OTP server to
verify that the user used a correct OTP. (For example sent the
preauth encrypted time stamp to the OTP server.)  Think of a federated
Radius servers across organizations with a local site realms without
cross realm between them.  This would also allow the same OTP token to
be used with Radius and with Kerberos.

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444