One Time Identification, a request for comments/testing.

[g.w@hurderos.org]

On Feb 2,  9:48am, Ken Renard wrote:
} Subject: Re: One Time Identification, a request for comments/testing.

Hi Ken, thanks for the note, hope the week went well for you.

> > The identity token is included in an identification payload which  
> > is symmetrically encrypted and included in the AS_REQ authorization  
> > field.

> Any reason why this couldn't be implemented as a preauthentication
> type (especially with the PAL in 1.6)?  Might give you more
> flexibility with respect to multiple exchanges or when a principal
> requires this type of authentication.  This might even fit into the
> SAM(2) preauth type.

A well taken and valid observation, certainly something we've been
thking about.  Just a couple of comments.

First, to be perfectly honest, the reason it went into the AS_REQ
authorization field in the prototype implementation was that most of
our work is focused on authorization theory and I knew the code path
well.... :-)

In a larger, and perhaps more philosophical context, we view OTI as
authorization rather than pre-authentication.  It is of course one of
those hundreds of semantic differences one can argue about in
technology.

All of the thinking in OTI was driven by our work in identity linked
authorization.  In the IDfusion authorization model the auth_data
payload fields of Kerberos tickets get loaded with identities which
consist of 160 bit numbers.  The identity token in OTI contains just
one of the 160 bit identities which can be assigned to a user.

If the OTI identity payload is successfully processed the TGT gets
loaded with the two-factor/OTI identity from the token sent in the
AS_REQ.  When a service ticket is granted against the user credentials
the service and service instance identities get generated for the
service ticket while the user identity propagates from the TGT.

The end result of all this is that the application has the ability to
determine the quality of authentication based on the user identity in
the service ticket.  So an organization can require two-factor for
access to sensitive resources such as HR/finances etc. while
implementing a more relaxed policy for something like e-mail.

So if Jeff uses OTI and forgets his token he can still read e-mail
while he's in Europe, but he can't run PeopleSoft..... :-)

> Operationally, users might just stick their USB key in and leave it
> there (same as copying to filesystem).  From there, it's just
> filesystem privileges that separate an attacker from the real user.

Certainly another threat scenario for USB flash dongle based
two-factor.

As we've been discussing OTI is not only about two factor but also
about an alternate paradigm for Kerberos centric multi-factor.  The
identity token only implements the user's identity when it operates in
concert with the user's password.

> -Ken Renard

Thanks for the observations and comments.

Have a good weekend.

}-- End of excerpt from Ken Renard

As always,
Greg

------------------------------------------------------------------------------
			 The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org

"True.  When your hammer is C++, everything begins to look like a thumb."
                                -- Steve Haflich