One Time Identification, a request for comments/testing. g.w at
Thu Feb 1 23:30:57 EST 2007

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

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.
	'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

>   Douglas E. Engert  <DEEngert at>
>   Argonne National Laboratory

Best wishes for a pleasant weekend.

}-- End of excerpt from "Douglas E. Engert"

As always,

			 The Hurderos Project
         Open Identity, Service and Authorization Management

"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

More information about the krbdev mailing list