open-source cryptocard libraries

[Troy Benjegerdes]

On Fri, Jan 19, 2007 at 04:21:03PM -0500, Ken Hornstein wrote:
> >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?
> 
> So, we use Cryptocard here (no secret), and we have two KDCs.  What do
> we do about it?  Nothing.
> 
> It turns out something like 99.92% of the total requests go to our
> first KDC (we do weekly auditing of our KDC requests, so I feel pretty
> confident about that number).  It just doesn't end up being a problem
> in practice ... and I think we have 5+ years of experience.  You could
> beat youself up and come up with some multi-master solution ... or you
> could just ignore the problem like I did, and you'll probably discover
> that it's a non-problem.

oooohhh... Can I be part of the next tiger-team audit of your network :)

If I implemented KB-1 cryptocard support with no updates of the seed
value, and posted the code, I'd expect someone to publish a
timing/replay attack based on talking to the slave KDC(s) within about 6
months.