Speaking purely personally, I like two possibilities: a) smart cards with PKINIT, or b) a software-only OTP like S/KEY that would be built into the KDC and look like a normal password to the client side. (I think the latter qualifies as "key generating" in your nomenclature.)
If I had my way, any vendor would need to convince me that they have solved the KDC robustness problem. I have a hard time imagining a vendor being able to make money solving this problem unless the market was bigger than just Kerberos servers. I'm not sure I know how to solve the problem. The solution would need a really robust sync service like UBIK, but fast enough that it never times out a traditional kinit, even with multiple, transcontinental kdc's. Is it worth bringing this up on the IETF list? On Jun 4, 2007, at 3:20 PM, Nicolas Williams wrote: > On Mon, Jun 04, 2007 at 03:15:40PM -0700, Henry B. Hotz wrote: >> IMO the interesting technical problem w.r.t. OTP is how you create >> intra-kdc state so a password can't be sniffed and re-used with a >> different KDC. You need to do this in a way that does not degrade >> the robustness of the service. > > I thought the interesting problem was how to protect the > authentication > step given that most OTPs are non-key-generating or, if they do > generate > keys, they generate weak ones. The problem you mention is the OTP > vendor's problem, not the KDC implementor's. > > Nico > -- ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
