On Feb 1, 11:11am, "Douglas E. Engert" wrote: } Subject: Re: One Time Identification, a request for comments/testing.
Good evening, I hope the day has gone well for everyone. A follow up to the mail I sent earlier today. Nicolas Williams wrote: > > That doesn't stop a softtoken from being useful though. > I was trying to get the authors of the note to say this, as it > appears that their approach is equivalent to soft tokens but may > have some advantages with regard to password policies. > > Compare softtokens to passphrase-protected ssh private key files in > > users' home directories :) > These suffer form policy control of the passphase used to encrypt > the key. The user can change the passphrase, or remove it all > together! This is a problem for oraganizations that need to enforce > password quality rules. It all so allows for offline guessing > attacks. (A smart card at least enforces some rules on the pin, and > defeats the guessing attack buy turring off the card after some > small number of guesses.) > It sounded like the identity token approach required the use of a > password as well, so it might get around some of the password policy > issues, as the KDC gets to enforce the policies. I would like the > authors to comment more on this. The central tenant which has consistently shaped our thinking in all this goes something like this: 'The dirty little secret about information security is that there is always a dirty little secret which needs to be kept secret.' Ultimately the only way an organization guarantees security is by guaranteeing the quality of the secret. As Doug noted the only way an organization can exert control over this is by centralized management of the secrets. We wanted to preserve and extend that model in OTI which is why we focused on a model which preserved what Kerberos does very well, centralized management and control of secrets. That being said we also wanted to address a central problem with this which, paraphrasing Hutzelman, goes something like this: 'Oh damn, I hate typing in long stupid passwords, I'll just use my dog's name Rover. and 'Damnit, they won't let me use Rover. I'll just type in some junk and write it down so I can remember it'. The logical solution to this problem is one of the central tenants of OTI's design and is something we refer to as 'password amplification' or the concept of using the identity token to increase the complexity of the key selection process. The identity token does this by providing a reasonably large secret (the hash of the encrypted identity) and a perturbation factor, the authentication/identity epoch time offset. So in OTI two positive things happen. The complexity of the secret is increased. In addition a different expresion of the secret is needed for each authentication. Ultimately the only effective keys are dependent on the user's password (key) which is centrally controlled in the OTI model. So the organization still exerts control over the quality of passwords and can enforce their use. The SSH soft-token model provides an interesting contrast and underscores the difference in philosophy. The actual authentication secret is the private RSA key. Anyone who posesses the private key can implement the user's identity. The user's password only serves to protect implementation of the identity. In OTI posession of the identity token is insufficient to implement the identity. Actual implementation is dependent on the user expressing his secret in combination with the contents of the identity token. > Douglas E. Engert <[EMAIL PROTECTED]> > Argonne National Laboratory Best wishes for a pleasant weekend. }-- End of excerpt from "Douglas E. Engert" As always, Greg ------------------------------------------------------------------------------ The Hurderos Project Open Identity, Service and Authorization Management http://www.hurderos.org "I had far rather walk, as I do, in daily terror of eternity, than feel that this was only a children's game in which all of the contestants would get equally worthless prizes in the end." -- T. S. Elliot ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos