Identity mapping and more

["Kurt D. Zeilenga" <Kurt@xxxxxxxxxxxx>]

While I do not support addition of "new" work, I do concur
that for a access control policy to be evaluated consistency
across multiple replicas that these replicas need to use
common mechanisms and policy for generating those access
control factors which are derived from the LDAP association.
In particular, access control policy commonly acts upon subjects
which are derived from identity the server has associated with
the client.

Some background based upon my particular operational experience
in this area:

Authentication Identity
  The authentication process may or may not be based on
  information held in the directory. The process results
  in some "authentication identity" being associated with
  the user.  It is generally derived from the credential.
  The characteristics of the credential are mechanism
  specific.  In some cases, a credential can be associated
  with multiple identities.

Authorization Identity, no proxy
  The client derives an authorization identity from the
  authentication identity, possibly based upon
  information held in the directory.  If the server
  supports multiple authentication mechanisms, it is
  desirable to map all the authentication identities
  which are associated with the same user to one
  authorization identity.

Authorization Identity, proxy
  The client asserts the desired identity to assume.
  As in the no proxy case, the server need to map
  the authorization identity associated with the
  authentication identity as this generally a factor
  in the proxy authorization policy decision.  The
  desired identity may also need to be mapped into
  an appropriate form needed to make the policy
  decision.  The policy and other information may or
  may not be held in the directory.

Access Control Subject Identities
  The access control system may use as factors identities
  information derived from the authorization identity
  associated with the authentication identity or the
  the authorization identity associated with the assumed
  authorization identity.  I refer this as the subject
  identity namely to imply additional mapping which
  might be involved.

In order to provide consistent mapping of identities
between replicas, the work needs to consider a variety
of identity mappings requirements.  And, obviously,
information supporting the authentication process itself
as well as the mappings needs to be replicated.

Also, note that I only discussed identities above.
There is also other access control factors which
come the authentication/authorization system which
need to be considered.

Solving this problem is a major undertaking.

If this is included as a charter work item, it warrants
specific mention in the description.
   In order to support consistent evaluation of access controls
   across replicas, the working will deliver a specification
   suitable for the Standard Track detailing mechanisms
   supporting consistent authentication/authorization services
   in replicated environments based upon a requirements which
   the WG will document in an Informational RFC.

And what I consider to be ambitious milestones:
   March 2002 Initial Authc/Authz Services Req't I-D submitted
   June  2002 Authc/Authz Services Req't I-D progressed to IESG
              for consideration as Informational
   July  2002 Initial Authc/Authz Services TS I-D submitted
   Dec   2002 Authc/Authz Services TS I-D progressed to IESG
              for consideration as a Proposed Standard

Again, I do not support adding any new work to the LDUP charter.

Kurt