changed notes
changed state Open to Suspended
moved from Incoming to Software Enhancements

At 05:54 PM 4/11/00 GMT, gombasg@inf.elte.hu wrote:
>Full_Name: Gábor Gombás
>Version: 2.0-devel
>OS: Debian Linux 2.2
>URL: http://valerie.inf.elte.hu/~gombasg/ldap/openldap-sasl.patch
>Submission from: (NULL) (157.181.161.14)
>
I won't have significant time to review the changes for a bit...
I just make a few quick comments (without looking at the code).
>
>I've managed to get SASL authentication, authorization and data encryption
>working for
>OpenLDAP 2.0-devel. It was inspired by (and contains code from) the patch
>created
>by Mark Adamson.

Great.  Please ping with Mark to ensure any changes he's made
since submitting his patch are appropriately integrated.

>The patch contains:
>
>- SASL support for the programs in the clients/tools directory. New command line
>flags:
>  '-C' to use Cyrus SASL authentication (the small letter 'c' was already used
>for
>  other purposes in some of the programs), '-m mech' to specify the SASL
>mechanism and
>  '-Z authzid' to specify an authorization ID (see below)

We had a prior discusson on which flags to use for various SASL/TLS
options.  It may have been private.  I'll see if I can locate the
post (and provide it to -devel).  Modification to use the previously
choosen flags *should* be a straight forward...

>- Security layer support changes in liblber

I'll assume you've read previous posts about LDAP/LBER layering
issues [just to be aware of "the vision"... need not be implemented
by your code]

>- 3 new config. options for slapd: SASLMinSSF, SASLMaxSSF and SASLDefaultDb. The
>first
>  two enables the setting of the minimal/maximal SSF. SASLDeafultDb marks a
>database
>  definition to be used when the client does not provide a DN for SASL bind and
>the DN
>  needs to be determined from the authentication ID

Note that the client provided DN MUST NOT be used to locate the entry
to authenticate as.  The DN MUST only be used to select a subset of
the possible realms returned.  See previous discussions (in response
to Marks patch, likely in -bugs or -devel archives).

>- I've added a new mutex to the Connection structure to block all input between
>sending
>  the final result of the SASL bind and installing the security layer functions
>to
>  the socket. Without it ber_get_next() tries to interpret encrypted data and
>fails which
>  causes the connection to be dropped just after the bind

Hmmm... well... I think there a better approach [connection state
machine] to resolving this issue... but don't mind the mutex approach
for now.

>- The ldbm backend supports SASL authentication and two forms of authorization.
>If the
>  client did not specify a DN to bound to, it's determined from the given
>authorization
>  ID using the "externalAuthName" attribute.

The provided DN MUST NOT be used to determine the authorization ID.
The authorization ID, if not provided by the client, MUST be derived
from the authentication ID.

I have some thoughts on this should be implemented... (basically
configuration options which map authentication id to DN via
regex).  I'll dig up the private discussions and post a summary
to -devel.

>The authorization ID can be
>specified
>  either as "dn:<dn>" or as "u:<userid>" as the authmech draft says. The
>permissions
>  for the authorization can be stored in either the authenticated entry's
>"allowAuthorizeAs"
>  attribute or in the target entry's "allowAuthorizationTo" attribute. Both are
>regular
>  expressions which the authorized/authenticated DN must match
>
>What's missing:
>- Client-side configuration of the desired data integrity and encryption level
>
>Gabor
>
>
>

On Tue, 11 Apr 2000, Kurt D. Zeilenga wrote:

> We had a prior discusson on which flags to use for various SASL/TLS
> options.  It may have been private.  I'll see if I can locate the
> post (and provide it to -devel).  Modification to use the previously
> choosen flags *should* be a straight forward...

Ok, I've read it now. I plan to change my version of the code soon and
submit the changes.

> I'll assume you've read previous posts about LDAP/LBER layering
> issues [just to be aware of "the vision"... need not be implemented
> by your code]

I've read some messages in the archives but I'm not sure if you are
talking about the same thing. Please tell me exaclty which thread were you
thinking of. Actually, I had my own opinion of what could be done: a
mechanism which enables independent I/O functions to be stacked on top of
each other, something like the BIOs in OpenSSL. With this approach,
liblber should know nothing about security, it would just call the I/O
functions in the order they were added to the socket and pass data between
them. Whether a layer does encryption, read-ahead buffering or something
else, liblber should not care anything about. But supporting this
functionality would require the complete rewrite of the I/O routines in
liblber. 

> Note that the client provided DN MUST NOT be used to locate the entry
> to authenticate as.  The DN MUST only be used to select a subset of
> the possible realms returned.  See previous discussions (in response
> to Marks patch, likely in -bugs or -devel archives).

It can be done by simply elimitating my find_by_dn() function in
back-ldbm/sasl.c. However, the only threat of using the bind DN is a false
authentication failure when the specified DN and the authentication ID do
not match (the check is based on the value of the "externalauthname"
attribute - if it contains the given authentication ID, authentication is
OK, else authentication fails).

I think the realm selection is already done in do_bind() when it calls
select_backend() with the given bind DN.

> The provided DN MUST NOT be used to determine the authorization ID.
> The authorization ID, if not provided by the client, MUST be derived
> from the authentication ID.

Agreed. If the client does not provide an authorization ID or the provided
ID matches the authenticated entry, authentication is accepted and no
further checks regarding authorization are made.
 
> I have some thoughts on this should be implemented... (basically
> configuration options which map authentication id to DN via
> regex).  I'll dig up the private discussions and post a summary
> to -devel.

I'd like to see this information represented in the directory itself, it
gives more flexibility.

I'd also like to hear comments about checking if authorization should be
accepted or rejected. Suppose A is the authenticated entry, and the client
wants to authorize as entry B. My code supports two forms of access
checking now: 

1. If the "allowauthorizeas" attribute of entry A contains a regexp which
maches the DN of entry B, then authorization is accepted (I called it
"forward authorization"). Pro: easy setup for proxy-like clients. Contra:
maybe TOO powerful; anyone who can modify the "allowauthorizeas" attribute
of an entry it can authorize as has nearly full control of the database.

2. If the "allowauthorizeto" attribute of entry B contains a regexp which
maches the DN of entry A, then authorization is accepted (I called it
"reverse authorization"). Pro: fine-grained access control. Contra: needs
much more administration for proxy-like clients.

Personally I prefer the second approach (everyone can decide whether
he/she trusts a proxy or not), but for many setups the first one would be
satisfactory and much easier to administer.

Gabor

---
Gabor Gombas                                       Eotvos Lorand University
E-mail: gombasg@inf.elte.hu                        Hungary

At 12:10 AM 4/13/00 +0200, GOMBAS Gabor wrote:
>> I'll assume you've read previous posts about LDAP/LBER layering
>> issues [just to be aware of "the vision"... need not be implemented
>> by your code]
>
>I've read some messages in the archives but I'm not sure if you are
>talking about the same thing. Please tell me exaclty which thread were you
>thinking of.

http://www.openldap.org/lists/openldap-devel/199906/msg00068.html

>Actually, I had my own opinion of what could be done: a
>mechanism which enables independent I/O functions to be stacked on top of
>each other, something like the BIOs in OpenSSL. With this approach,
>liblber should know nothing about security, it would just call the I/O
>functions in the order they were added to the socket and pass data between
>them. Whether a layer does encryption, read-ahead buffering or something
>else, liblber should not care anything about.

Exactly!

>But supporting this
>functionality would require the complete rewrite of the I/O routines in
>liblber. 

Yes.  This is why I said you did not need to resolve this problem
today.  I don't mind if the solution today is not terrible flexible
or extensible as long as it allows for implementation of SASL
(security layer), TLS, or IPSEC.  The implementation need only to
support one layer at a time.

>> Note that the client provided DN MUST NOT be used to locate the entry
>> to authenticate as.  The DN MUST only be used to select a subset of
>> the possible realms returned.  See previous discussions (in response
>> to Marks patch, likely in -bugs or -devel archives).
>
>It can be done by simply elimitating my find_by_dn() function in
>back-ldbm/sasl.c.  However, the only threat of using the bind DN is a false
>authentication failure when the specified DN and the authentication ID do
>not match (the check is based on the value of the "externalauthname"
>attribute - if it contains the given authentication ID, authentication is
>OK, else authentication fails).
>
>I think the realm selection is already done in do_bind() when it calls
>select_backend() with the given bind DN.

I'm about to change this code.  In particular, the sasl_bind()
call will be moved to the frontend.

	Kurt

[discussion regarding in-directory representation of authorization
information ducked].

moved from Software Enhancements to Development

changed notes
changed state Suspended to Closed

Not committed.