Re: Authentication of both proxy and client

[Stig Venaas <Stig.Venaas@uninett.no>]

Thanks for your answer. I'll try to explain a bit further what I'm
thinking below. I'm not really looking for people to do the thinking
for me, but some comments on what is possible, or what could be
worth implementing would be good.

On Mon, Oct 22, 2001 at 09:52:50AM -0700, Kurt D. Zeilenga wrote:
> mechanism specific.  The gateway can play man-in-the-middle
> (with weak mechanisms) or the gateway must authenticate the
> client itself but may use information stored in the directory.
> The latter (with simple password mechanisms) can be accomplished
> today through use of an LDAP-enabled SASL features at the
> gateway.

Right, my idea was the former, but will consider the latter. I would
like to restrict who can act like gateways. The former combined with
TLS (no SASL) and client certificate verification, satisfy my wishes
if I create my own special CA to sign certificates for the gateways,
and make only that CA known to the LDAP server. If I could restrict
simple bind based on contents of the TLS client certificate (the CN
perhaps), I could use a CA that also issues certificates to others. 
Ideally I think as much as possible of the context/state should be
available as ACL subjects. Right now I'm looking for the best
solution regardless of what is currently implemented...

In my case the gateway is a resource, and I want to control access
to the resource based on data in LDAP, that is, I want to do both
authentication and authorization of users based on LDAP data. I was
hoping to do all the work in LDAP with ACLs. If I use SASL to
authenticate the user at the gateway, I can still have the LDAP
server do the user authorization when the gateway tries to do a
SASL bind and specifies the user as authorization id maybe? That
is, gateway G should only be able to bind as user X if data
associated with X has certain values.

Stig