On Wed, Jun 06, 2007 at 04:32:09PM -0700, Henry B. Hotz wrote: > On Jun 6, 2007, at 12:58 PM, Nicolas Williams wrote: > >I was thinking of pam_otp. > > Ah! Very interesting point. > > I guess we're in violent agreement about the problem, but I guess an
We've converged :) But you see the problem, surely. To do what you want you'd need to spec out: - a new OTP - an SSHv2 userauth method - a SASL/GSS-API mechanism - an EAP method - a Kerberos V pre-auth And get some/all of that implemented, and new tokens manufactured and deployed. By the time you've done the bare minimum the world will have passed OTPs by -- we'll all be using smartcards embedded in our brains by then. > OTP vendor might argue that they've done as much as they can by > supplying such a pam module. Only thing I can say is that the client- > side OTP "thing" really needs to be fastened to the user, not the app > server (telnetd in this example), and that SA's should be smart > enough not to subvert the security model. Less than satisfying. They would say that. Look, it's easy to generate a string of stuff and have the user type it in to software that doesn't know what else to do with that stuff than to just kick it over to some other component, ad naseum till you get to the OTP vendor's components. How many ssh clients and servers do you know that are pluggable w.r.t. userauth methods? How many different SASL and GSS-API plug-in ABIs are there? And how many SASL or GSS-API implementations are not pluggable? How many KDCs are pluggable for pre-auth, right now (I know, MIT is working on it)? So I can't blame the OTP vendors. They did the best they could to get to the point where they got a good ROI. > This discussion is really taking more time than I should devote to > it, I'm afraid. It is.
