Re: Proposed new features for 1.3

Rich Megginson <rmeggins@xxxxxxxxxx> · Fri, 10 Apr 2009 12:07:55 -0600

David Partridge wrote:
David M. Partridge
Tangible Software Inc.
Sr. Security Engineer
2010 Corporate Ridge
Suite 620
McLean, Virginia 22102
Office     800-913-9901 x 3001
Mobile   571-286-9628
Fax        703-288-1226
dpartridge@xxxxxxxxxxxxxxxxxxxx

-----Original Message-----
From: Rich Megginson [mailto:rmeggins@xxxxxxxxxx]
Sent: Friday, April 10, 2009 10:40 AM
To: General discussion list for the Fedora Directory server project.
Subject: Re:  Proposed new features for 1.3

David Partridge wrote:

Use case example for certmap.conf for end user:

Customer has desire to share Enterprise Directory information across

WAN

for contact information sharing, but has requirement for strong
authentication using PKI.  PKI trust is a PKI Mesh utilizing cross
certification.  Users information in Directory Server One (DS1) are
associated with users issued certificates from PKI One (PKI1).

Users

information in Directory Server Two (DS2) are associated with users
issued certificates from PKI Two (PKI2).

DS1 has no awareness or cross population of entries with DS2, but

PKI1

is cross certified with PKI2 and trusted by both populations.  Users
associated with PKI1 have a business requirement to strongly
authenticate with DS2 to locate and collaborate with population of

users

in DS2, but have no entry in DS2 and vice versa.  By removing

current

capability to strongly authenticate based on TLS configuration but

have

NO DN in DS you are removing capability to use SASL External in a

cross

certified PKI environment.  User of the product will be forced to

use

SASL GSSAPI that causes other security issues or requirements to

setup

all of these Kerberos trust and ticketing handling that should not

be

required, difficult to sustain and place external dependencies on

usage

of the DS product in a federated environment as described.

If directory is utilized as something OTHER than repository for

people

similar challenges will present themselves when certificates are

issued

for devices, roles, and groups.  Examples include but are not

limited to

VOIP device address book capabilities such as CISCO VOIP phones or

call

managers, Potentially for extending security capability in hosts

that

have host based certificates that may require use of the directory

for

backend business processes were Certificate trust and regular

expression

checks of DN utilized for the TLS session may be sufficient to

utilize

for ACI binding rules.

So you want to allow a user from DS1 to authenticate to DS2, without
having a user entry in DS2.  Then use access control, bind resource
limits, groups, roles, CoS, etc. without having a real user entry.  I
think that would be useful for auth in general, not just cert based
auth.  It comes up often in SASL/GSSAPI auth (wanting to use Kerberos
auth without having to have a user entry), and is necessary to support
the types of devices you mention.

[David Partridge] 
DS1 and DS2 for clarity are only containers of information for users to
consume. A user may have data in neither, one or both DS, but has PKI
credentials that are trusted by neither, one or both DS.  If trusted the
user should be authenticated via TLS using mutual authentication using
PKI. If not trusted user is turned away by TLS mutual authentication.

Ok.  So just in general allow authentication if user doesn't exist.
Authentication and access control are two separate and distinct
processes.  

If user is not authenticated why should I allow them to get to the point
of exposing internal directory resources to evaluate access control,
bind resource limits, groups, roles, CoS, etc.  Believe I had this
conversation with Bob Lord long time ago when we discovered a previous
security issue.

Sure.  Unauthenticated users should not be allowed to consume resources 
or discover information.  We have some roadmap items to disallow and 
lockdown anonymous users even more than we do today.
If user is authenticated capabilities of DN mapping with sophisticated
access control, bind resource limits, groups, roles, CoS, etc. continue
to be valuable for providing different privileges and capabilities. But
the ability should not be absolute to requiring a DN in the directory
NOR would I want to try to build rules based on every PKI end user DN
that may have a chain of trust that is acceptable based on adding to NSS
Truststore.  There will be some cases that the fact that they
authenticated regardless of SASL mechanism should be able to provide
'SOME' access.

Ok.  Right - I want to allow those capabilities without requiring a DN 
in the directory.

One of the things that cert based auth does now is to retrieve the
userCertificate from the user's entry and compare it against the cert
presented in the auth request.  But that (verifyCert) can be turned

off

now.  Would you want the ability to compare the cert presented for

auth

against the known cert for that identity?

[David Partridge] Depends - For our use cases identity certificates [
digital signature, nonrepudiation key usage] are NEVER published or
stored outside of PKI CA infrastructure (will let the Dogtag team
explain reasons).  Therefore the certificate used for SSL will NEVER be
a match to the certificate attribute in the directory which is merely
one or more email encryption certificates [key encipherment key usage]
that corresponds to mail attribute in directory.

If directory was for PKI CA infrastructure matching the certificate
binary value may be useful, but unnecessary if implementation of PKI
done correctly.  Matching binary contradicts why the PKI exists in the
first place.  In most cases PKI exists so you do not need prior
knowledge of the end user of the certificate to know that the
individual/system met identity vetting requirements and is the only
individual/system that possessed private key to make it do what it does.

Ok.

David M. Partridge
Tangible Software Inc.
dpartridge@xxxxxxxxxxxxxxxxxxxx

-----Original Message-----
From: Rich Megginson [mailto:rmeggins@xxxxxxxxxx]
Sent: Thursday, April 09, 2009 11:47 PM
To: General discussion list for the Fedora Directory server

project.

Subject: Re:  Proposed new features for 1.3

David Partridge wrote:

Would like to see additional monitoring flexibility for snmp -

when

configuring multiple ds instances with same port on single

multihomed

host

monitoring information is agregated by port in the monitoring not

by

instance and port.

Please provide more information on deprecation of certmap.conf.

We would instead use the SASL mapping functionality to map the

subjectDN

in the cert to a DN that the DS knows about.  The SASL mapping code

is

much more powerful and flexible than the certmap.conf code.
*http://tinyurl.com/cqe42v
*

Need flexibility to not rely on dn in cert mapping to anything in

directory and rely on successful tls mutual authentication and

truststore

configuration.

I'm not sure I understand - do you want the ability to do cert auth
without having to have a real entry in the directory server that
corresponds to the subjectDN?

Script to provide index analysis based on data in  the directory

to

provide the following info:

Search performance efficiency of index and index type based on

return

limits, and scanidslistlimit.

Compressed ldif(gzip) capability for export, import, and

initialization

usage.

Ok - Thanks - this is all good stuff.

Dave Partridge
Sent from my Windows Mobile(r) phone.

-----Original Message-----
From: Rich Megginson <rmeggins@xxxxxxxxxx>
Sent: Thursday, April 09, 2009 7:23 PM
To: General discussion list for the Fedora Directory server

project.

<fedora-directory-users@xxxxxxxxxx>

Subject: Re:  Proposed new features for

1.3

Andrey Ivanov wrote:

I continue with my list

Thanks - I've added many of these to the list - questions below.

* the server should be able to return the members of dynamic

groups

"on the fly" as if it were real members, the membership attribute
should be configurable - uniqueMember, member or another

I put this on the Future list:
Dynamic group expansion

    * Define a dynamic group, and have the member/uniqueMember

attribute

      of this group automatically be populated by the server
    * clients can then just search for member like with a regular

static

      posix group

* support of other virtual attributes generated "on the fly"

Can you explain this a little more?

* pam passthrough plug-in should take into account at least the
account activation/desactivation (bug *470684*
<https://bugzilla.redhat.com/show_bug.cgi?id=470684> ). There is

a

comment about some additional useful features it in th README

file

of

this plug-in :
We need to worry about account expiration or lockout e.g. the

user's

credentials are valid but the user has been locked out of his/her
account, or the password has expired, or something like that.

Some

of

this can be handled by LDAP e.g. returning password policy

control

values when the password has expired.

* a way to synchronise the configuration of indexes (each time we

add

an index on one of the replicated servers we need to make it

manually

on all the others) and some other parameters in "cn=config"

between

the replicated servers  (a little like the "configuration"

partition

in active directory), the schema changes are already replicated

which

is very good

I'm calling this feature "Configuration replication" - I think it

could

be useful for other sorts of configuration.

* enforced attribute syntax validation

Already on the list - Syntax validation checking

* re-verify and validate conformance of the syntaxes, case

sensitivity

and their matching rules to RFC
(https://www.redhat.com/archives/fedora-directory-users/2008-

July/msg00041.html)

Already on the list

* unix socket autobind still does not seem to work (ldapi) -
https://www.redhat.com/archives/fedora-directory-users/2009-

February/msg00112.html.

It could be very useful for various maintenance scripts running

on

the

server.

We tested this with 1.2.0 and it seems to work.  You tested a

build

from

source?  Did you use --enable-autobind with configure?  Did you

restart

the server after configuring your autobind and sasl mapping?

* verification of the server from the viewpoint of memory leaks.

Th

size of the memory used by the server grows with time (normally

we

don't restart the sevrr during several months, so i can follow

the

stats)

We regularly run the server test suite with valgrind enabled.  I'm

not

aware of any per connection or per operation leaks.  What exactly

are

you seeing?

* logconv.pl - very useful script, add some more options/

adjustments

(for example, a switch to hide unindexed searches in verbose

mode).

We

use it as logwatch.

* a perl script to show the replication statistics (there is one

for

the we page generation statistics, something more basic,

text-only

would be very welcome) in text mode - to receiveth reports by

mail

once per day like logwatch for example

What sort of information are you looking for?  ldapsearch can

provide

most of the useful information.

* regular expressions in ACIs (i know, it is very difficult to

do,

so

maybe somewhere in the timescale of the version 10.0 ? :)) - for
example, allow a user to add or modify a value just in case the

new

value mathes the regex. Or the group or dn of the user matches

the

regex...

You can do some of that currently with targetattrfilters - see
*http://tinyurl.com/3yo88r

We added support in 1.2.0 to allow you to specify group membership

with

LDAP search specifications, which does allow some wildcarding, so

that

might help too.
*

* simplify the creation of new syntaxes and their validation/
enforcement (version 11.0? :))

Can you elaborate?

* virtual views allowing to map not only the trees but also the
attributes ('cn' instead of 'uid' in a subtree, for example)

Can you elaborate?

* enable regex in certmap.conf for mapping the CNs of the

certificates

during the certificate authentification of users

This is on the list as
Get rid of certmap.conf - use SASL mapping (cert auth is really

just

SASL/EXTERNAL)
The sasl mapping code uses regular expressions

Other than that i just want to emphasize the great job you are

doing

adding new features and especially the fantastic reactivity in

fixing

some critical server bugs (usually it takes only one or two days

to

have the necessary diff in bugzilla!)

Thank you and please continue the development of this directory

server!

And thank you for your suggestions.

        Thanks - I've added these notes to

http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3

        Anyone else?  C'mon - surely you have an opinion about a

new

        feature.

            Thanks for all your hard work on this!

-----------------------------------------------------------------------

-

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

This e-mail and any attachment is intended for the above name

recipient(s) only and may contain confidential or privileged

information.

If you are not an intended recipient, please notify the sender and

delete

the message.  Failure to maintain the confidentiality of this

e-mail

and

any attachment may subject you to penalties under applicable law.

CONFIDENTIALITY NOTICE: This e-mail message, including any

attachments,

is for the sole use of the intended recipient(s) and may contain
confidential and privileged information or otherwise be protected

by

law.

Any unauthorized review, use, disclosure or distribution is

prohibited. If

you are not the intended recipient, please contact the sender by

reply

e-

mail and destroy all copies of the original message.

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

This e-mail and any attachment is intended for the above name

recipient(s) only and may contain confidential or privileged

information.

If you are not an intended recipient, please notify the sender and

delete

the message.  Failure to maintain the confidentiality of this e-mail

and

any attachment may subject you to penalties under applicable law.

CONFIDENTIALITY NOTICE: This e-mail message, including any

attachments,

is for the sole use of the intended recipient(s) and may contain
confidential and privileged information or otherwise be protected by

law.

Any unauthorized review, use, disclosure or distribution is

prohibited. If

you are not the intended recipient, please contact the sender by reply

e-

mail and destroy all copies of the original message.

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

This e-mail and any attachment is intended for the above name recipient(s) only and may contain confidential or privileged information.  If you are not an intended recipient, please notify the sender and delete the message.  Failure to maintain the confidentiality of this e-mail and any attachment may subject you to penalties under applicable law.

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

<<attachment: smime.p7s>>
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users