On Jun 5, 2007, at 1:11 PM, Nicolas Williams wrote: > On Tue, Jun 05, 2007 at 11:45:04AM -0700, Henry B. Hotz wrote: >> On Jun 5, 2007, at 11:09 AM, Nicolas Williams wrote: >>> 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? > > Huh? No, the OTP came from the client. It's the KDC's (and the > client's) job to protect it from passive and preferably also active > attackers, but the OTP authenticates the user, not the KDC.
The OTP travels over a TBD link to the KDC. The KDC then uses the vendor-provided software to validate the OTP; in other words the vendor is validating that the KDC has a valid OTP. The OTP vendor never validates the client and has no connection to the client. However that is exactly the problem which needs to be solved. Since I run the KDC, but not the OTP service, I want the OTP vendor to tell me that the client is valid, using an appropriate cryptographically secure protocol (not a password). Only then might I be willing to issue a tgt with the appropriate marking that says who's vouching for the identity and how strongly. Give or take issues with how accessible the marking is, PKINIT actually does what I just said. Likewise if the KDC *IS* the OTP service then the chain-of-custody issues go away and you just use timestamp pre-auth, possibly with some not standardized marking. Of course then the KDCs need to solve the intra-kdc coordination problem to actually enforce the "one-time" requirement as I said at the beginning. The disclaimer actually applies, since what I've said probably doesn't reflect what HSPD-12 interpretations will force me to do (though it might). No offense, but I'm not going to research how to link to the list archive just so I can post a link to the WG, so I can get email from other people besides you that I'll feel obligated to respond to. OTOH I have said things that I wish would be taken into account by the vendors that are pushing OTP standards in the WG. More than one of us have been down this path with RSA, and I'm not going to do it again. They have people who understand the issues, and would like to do the right thing, but it isn't going to happen. ------------------------------------------------------------------------ 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
