On Jun 5, 2007, at 11:09 AM, Nicolas Williams wrote: > On Tue, Jun 05, 2007 at 10:51:31AM -0700, Henry B. Hotz wrote: >> On Jun 4, 2007, at 9:36 PM, Nicolas Williams wrote: >>> On Mon, Jun 04, 2007 at 04:48:25PM -0700, Henry B. Hotz wrote: >>>> 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 >>> >>> The OTP robustness problem, you mean. >> >> Same thing if you build the OTP into the KDC. I'm not personally >> interested in OTP that doesn't get you a Kerberos ticket. > > No, the two are not the same thing. The KDC could have a pluggable > pre-auth framework and the OTP implementation could be a third > party's, > as I've already explained. In that case the OTP robustness issue > would > be the third party's, not the KDC implementor's. Really, it would be.
OK. > The same applies to OTPs and PAM, for example. > > Usually the way this is addressed is by having an OTP vendor provided > API that sends the OTP to a remote server for verification, and that > remote server is clustered. The problem with this is that your OTP system is validating the KDC, not the real client. Why should I pay an OTP vendor to validate my KDC? This is the problem that the Krb WG is worried about, but it gets into what I said at the beginning. I don't think they're addressing the real problem. They're going down that path because they have vendors working on the standards that want to validate my KDC, and they think they can make it work, not because it's the right solution. You may bring this discussion up with whatever IETF groups are relevant. I'm afraid I've come to the conclusion ATM, that I don't have the time to pursue a real solution in either the standards or the implementation senses of the word. ------------------------------------------------------------------------ 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
