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) Hello, 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. 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) - Security layer support changes in liblber - 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 - 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 - 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 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
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.