Win2000 PAC-Credentials Implementation

[Dr. Greg Wettstein]

On Sep 4, 11:54pm, "James F.Hranicky" wrote:
} Subject: Re: Win2000 PAC-Credentials Implementation

Good afternoon James, thanks for the note.  I apologize for the delay
in responding back.

For convenience and 'cut to the chase' issues I took the liberty of
re-arranging your note a bit.

> So, what I'm asking in my long post is, "Does Hurderos plan on
> setting up a system like this?" :->

The description that James provided was one which poses the Reciprocal
Identity Management (RIM) problem.  The short answer to the above
question is that, yes, the Hurderos identity and authorization model
was explicitly designed to provide infra-structure to support this
type of environment.

Additional comments follow below, for those that are interested.

> It dawned on me while searching for the ultimate open-source calendaring
> program that if I were to write my own, I'd want to be able to set up my
> own groups consisting of anyone, anywhere:
>
>       Group FullCalendarAccess:
>               mom at somewhere.com
>               dad at somewhereelse.com
>               friend at example.com
>
> etc. Then I figured, hey, wouldn't it be cool if you could generalized access
> to all parts of your system/network/services that way, say, sharing files
> with specific users anywhere on the net, etc.

The type of system which you describe would be 'cool'.  In fact I
would argue that it is the actual Holy Grail that people are looking
for from the INTERNET.  The difficulty is that managing this type of
environment requires solving, or making tractable, RIM problem.

The industry acronyms, especially IBM, are talking about Grid Services
or computing on demand.  The problem is that for any of this stuff to
occur a federated identity system needs to be in place.  A federated
identity system is in turn predicated on each member organization
having systems in place which can manage, not only their
organizational identities, but ultimately the identities of
individuals in partnering organizations hence the RIM problem.

The RIM problem arises from something which I refer to as the
'bullshit predicate'.  Systems which allow organizations to support a
federated identity model must deploy infra-structure which supports
predicate.  The following diagram may be useful:



     +-------------+   Identity Verification    +-------------+
     |  Company A  |  ----------------------->  | Company B   |
     +-------------+                            +-------------+
                   \                           /
      Authorization \                         /  Authorization  
                     \                       /
                      \             +----------+
                       ------------ | User B   |
                 Service Request    +----------+


The pictures tries to depict a classic federated identity model.  A
user from Company B wishes to access resources (services) at Company
A.

Provided that a suitable trust relationship is in place there needs to
be a mechanism for Company A to ask Company B whether or not User B is
who they say they are.  This is the classical identification and
authentication step.

One of the difficulties in this model is handling the authorization
phase.  Its fairly simple for Company B to answer the identification
and authentication question.  The reality of corporate security is
that Company A is going to want to retain rights to say 'bullshit'
this user isn't going to access services.

>From this arises the need for infra-structure to support or be based
on the 'bullshit predicate'.  The problem ultimately stems from the
fact that authorization is a separate and orthogonal issue from
identification and authentication.

The actual problem that needs to be addressed in a federated identity
system such as this is what I refer to as the 'bi-lateral
authorization problem'.  Each participant in a paired identity
exchange must exercise authorization rights over whether or not a user
can obtain or access services in that particular context.

All of this seems a little much for simple calendar sharing and it
certainly is.  The problem is that when money or fiduciary
responsibility become involved things get a bit more serious.  Hence
the legal beagles and the like will ultimately drive the security
requirements for this type of collaboration.

> I figured what was needed was a distributed identity management
> system which allowed any individual organization to authenticate any
> of its users to any service/user/machine/program on the internet,
> and allow remote sites to manage their own authorization data. In
> essence, I'd allow mom at somwhere.com access to my calendar at
> www.thisplace.org. In order to do so, someone claiming to be mom
> would send me a set of credentials which I'd pass on to the
> authentication server for somewhere.com, and they'd return yes or
> no. Once mom was authenticated with a yes, I'd allow her access to
> my calendar. In other words, Kerberos for anyone on the 'net.

Not strictly Kerberos actually.  Kerberos implements just one small
piece of the puzzle, ie. authentication, the problems go much deeper
than that.

One of the fundamental requirements for a system such as the above is
for Company A to have a system which supports strict isolation between
the intrinsic and representational identities of the user.  For
something like this to scale there needs to be a minimum amount of
interaction between Company A and Company B for setting up the
'account' or trust agreement for each user.

The requirement for bi-lateral authorization means that Company A
needs to track internally the identity of User B.  The identity that
User B uses to identify his/herself to Company A probably has no
guarantee of remaining invariant.  So Company B needs to export an
intrinsic and invariant identity token to Company A for this purpose.

The debate over personal privacy and identity theft issues is going to
pretty much require that the invariant identity token convey no actual
meaning about the user.  Things like FERPA and HIPAA already require
organizations to support identity revocation so having meaningful
representational identities is problematic.

So there are bunches of issues that need to be addressed.  Asking and
answering the identification and authentication questions is probably
the simplest and most straight forward step.

> I suppose all this would require things like authentication servers
> listed in DNS, a large PKI scheme to authenticate them (or maybe
> DNSSEC?), plus you'd need the ability to mark your authentication
> server as compromised in the event of a breakin, returning the
> appropriate value/error message when asked for authentication...I
> haven't really thought all the details through. What you get is the
> ability grant access to services on your systems to anyone on the
> Internet without requiring them to have a local account, i.e.,
> authentication remains local and distributed as it is now, while
> authorization and access become Internet-wide. Ultimately, for all I
> know, this may not be a practical scheme.

There are those of us who have thought a great deal about how to make
this a practical scheme.... :-)

As you noted there are a host of issues that make distributed identity
and authorization management an issue.  The reality of the situation
is that organizations haven't even begun to think about all the issues
involved with making this work.  Despite all the talk and hype about
Grid/WEB Services there are huge challenges and barriers that must be
overcome.

> Jim

Thanks for the interest in the Hurderos perspective on all this.

}-- End of excerpt from "James F.Hranicky"

As always,
GW

The Hurderos Project - Open Identity and Authorization Management
------------------------------------------------------------------------------
"The greatest pleasure in life is doing what other people say you cannot do."
                                -- W. Bagehot