[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Authmeth/DIGEST-MD5

Bob Blakley wrote:

> A more detailed view would be:
> 
>     The client identifies itself
>     The server/acceptor challenges the client to authenticate its
>                 identification
>     The client responds to the challenge, authenticating the
>                 identification 
>     The server/acceptor determines the client's privileges, using the
>                 client's authenticated identification as a key to
>                 retrieve or synthesize said privileges
>     The server/acceptor authoriz(s)es the client by comparing the
>                 client's privileges against an authorization policy rule
>                 for the client's access request.
> 
> Notice I've carefully avoided the use of the term "identity" here; it
> causes way too many problems, including semantics, privacy policy,
> etc...., to be of real use. The client does have an "identification"
> which it authenticates, and it does have a set of privilege attributes
> (not necessarily including any "identifying" information) which are
> used to authorize its access to resources.

I agree that your description above covers the general case acceptably.
However it seems to me that despite the undeniable problems caused by the
"identity" concept in the authorization process, it is widely enough used
that we won't be able to get away from it, either in specifications or
implementations.  Perhaps it's best understood as one common, though
optional, component of the process.

> Hence I'd rewrite your
> summary
> as follows (my amendments are upcased):
> 
> >A client binds as a DN, and presents an
> >authentication token to prove THE AUTHENTICITY OF HIS CLAIM TO BE IDENTIFIED
> BY THIS DN.
> >There then has to be some
> >internal mapping in the server between the AUTHENTICATED DN
> >and SOME authorisation PRIVILEGE ATTRIBUTES. This mapping is beyond the scope
> of
> >the LDAP work, but in the simplest case is null. (In other cases it will
> >be to map a LDAP DN into AN ACCESS-ID as present in an ACI.)

Well, there you have it, an excellent illustration of the problems 
of identity *8^)*.  A client needn't bind as a DN ...

 - RL "Bob"