open-source cryptocard libraries

[Roland Dowdeswell]

On 1169011200 seconds since the Beginning of the UNIX epoch
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..
>
>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.

I just checked the web site and found a KT-1 token.  Is that what you
mean?

There are a few vendors who implement IETF RFC 4226: An HMAC-Based
One-Time Password Algorithm.  If my memory serves.  They might be
worth checking out as well, as their algorithm is unencumbered.

There are a number of interesting questions around this and how
you would want to implement it.  I was thinking a little bit about
this a while ago and came to the conclusion that it would be much
better if the client libraries did not know that a token was in
use so that the solution could be rolled out without having to go
through the pain of updating an entire enterprise's install base
which includes such messy topics as Windows, Java, etc. not just
your UNIX infrastructure.

So, to do this, you'd probably want to do something like (very high
level):

	1.  client types in Password P and Tokencode T at a single
	    prompt,

	2.  normal aes256-cts or rc4 is used to generate the preauth,

	3.  request is sent to the KDC,

	4.  the KDC validates it,

		i.   now we have a sticky wicket insofar as you
		     must be able to recognise multiple different
		     tokencodes in various situations, e.g.:

			a.  time based tokens (SecurID) get clock
			    skew issues between the servers and the
			    tokens,

			b.  event based systems skip tokencodes
			    if a user presses the button multiple
			    time,

		ii.  so, what you do is you use the preauth packet
		     against a short list of probably valid token
		     codes,

		iii. then you'll have to update the state:

			a.  if using a time based token then some
			    repository must be updated with new time
			    skew info,

			b.  if an event based system is being used
			    then you need to update the system to
			    indicate what the latest event nymber
			    is,

		iv.  this state needs to be quickly propagated around
		     the rest of the system:

			a.  tradeoffs between the one timeness of the
			    password and robustness of the final solution
			    must be made,

			b.  I'd imagine that I would prefer to allow a
			    certain level of possible password reuse in
			    exchange for not dealing with the reliability
			    issues that you suffer by trying to ensure
			    no tokencode is ever repeated in many production
			    environments,

	5.  The KDC now knowing what you typed can easily generate a
	    AS_REQ and send it back to you.

For this to work, the KDC would need to store the user's actual
password (a minus) so that it could be pushed through PKCS#5 PBKDF2
with the individual token codes.  It would also be rather more CPU
intensive than any other AS_REQ type and that might raise some
issues.  But, if you want to be able to support existing clients
without running around getting all of your vendors to implement a
new standard (a ten year process---an unnamed vendor of a very
widely adopted graphical operating system still hasn't released
AES support, right?) then something like this is your only choice.

I'd probably shy away from LDAP because LDAP and reliability don't
seem like they belong in a sentence together.  And KDCs are the
kind of service that all thoughts should be peppered with words
like five and nines in rather close proximity...

Anyway, this is just a few quick thoughts about how I'd start
thinking about this problem.  If I really spent some time, I'm sure
that a lot more issues would crop up.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/