On Thu, Feb 4, 2010 at 12:14 AM, Michael Richardson
<..hidden..> wrote:
I've been there, done that.
(I'm the author of Openswan... IPsec key management daemon.
If we could have found a real use for LDAP, we would have. It just
doesn't make sense -- certificates contain everything you need, that's
the point of them. LDAP is only useful for email, when you need find
the other guys' certificate, and you are online... )
IPSec has no use for LDAP. On that we agree. Much better to find a way to use DNS and skip the OSI protocol family entirely.
The issue with LDAP and SSL as a PKI have a lot to do with the fact that SSL certificates include pretty much the full DAP info from an X.500 server. For this reason, it can be helpful to manage the SSL certificates in DAP or an approximation of it (LDAP).
It's a very specific issue for SSL and IMO SSL is worse for that dependency.
Chris> Really, I wish the old OSI-derived protocols (X.500, X.501,
Chris> H.323, T.101, etc) would all die and we could get proper
Chris> replacements steeped in more TCP/IP or UNIX-like ways of
Chris> working. The OSI concept of networking doesn't match the way
me too. Go read rfc2692/rfc2693...
This looks promising.
okay, I agree that you could this.
The "valid" point is just about retrieving a CRL from an LDAP URL
(rather than from an HTTP URL, or using OSCP)...
The other part, "correct user" depends upon a great deal of goop in
the DN, and honestly... if you have three guys named "John Smith" in the
company, and only one of them is the comptroller, it won't help you.
Yep. My thinking was that if one were to do this, one would have a schema extension mapping the LSMB username to the LDAP entry.
Chris> I am of the opinion that a proper corporate SSL
Chris> implementation would almost certainly be based on LDAP (and
Chris> that is probably the only valid use or LDAP out there).
The reports I have is that the only X.509 certicate system worth using
in a corporate environment is the one from microsoft (yes, they do
things correctly sometimes). Yes, it's kinda LDAP in that
ActiveDirectory is LDAP++, but to get the benefit you really need AD
integration, not just LDAP.
What's really funny is that my sense of Active Directory is that it does the X.509 side really, really well, but the Kerberos side is lacking in some important areas (because the kerberos server stores principle names in the LDAP db in a rather inflexible way). I wrote some papers on AD interop for Microsoft a while back. I will have to review my thoughts there.
(Like Fermilab's Dr.Leadermen once said to a group of young
physicists, "Some of my friends talk to Chemists, but not me")
The simplest system is to:
a) be able to provide the right _javascript_ to the browsers to get
them to generate a public key pair.
b) be able to upload the certificate request and store it in a
database column/file on disk.
c) admin be able to run a script to generate a certificate
d) bind it to a user.
e) return the certificate to the browser
f) be able to authenticate against the client certificates.
Thawte and Verisign and cacert.org all provide (a),(b), (c) and (e)
already free for personal certificates, so they can be deferred.
We just need (d) and (f) for now.
The question of LDAPness can be dealt with on the command line: the
admin can retrieve the certificate via LDAP with a command line tool if
they have such a thing.
Sure.
Chris> The basic point is that if you use a negotiated auth against
Chris> a Kerberos KDC, then the concern about password disclosure is
Chris> more or less gone.
Yes... I don't think it's worth the time.
I do not recall if there is a standard HTTP/SSL authentication
mechanism that uses Kerberos. I know that MS published their NTLM
mechanism that basically just uses Kerberos to generate a digest
authentication token.
mod_auth_kerberos for Apache supports IE, and there is a plugin to allow the Firefox to provide the same sort of auth data. I suspect that this is one area where MS's publication will essentially be the de facto standard fairly quickly.
>> HTTP Digest Authentication is the obvious "better choice", and
>> recently some people have done some work such that you do not
>> need to store the passwords in the clear to make digest
>> authentication work.
>>
Chris> How would this work in the way we are going with 1.3 (where
Chris> PostgreSQL provides all authentication control and permission
Chris> enforcement)?
Chris> How would one take an HTTP Digest Authentication token and
Chris> log into the db with it?
From what I understand about the users' table (in 1.2 and SL)...
The user connects, provides a password, and if it checks out, we use
the database credentials from the users' table to connect. The columns
are not encrypted AFAIK.
Right, but that isn't how we do things in 1.3. The users table doesn';t include password information at all in 1.3.
Instead we take the credentials sent by the browser and use them to log into the db. If the login is successful and a user configuration exists, the user is allowed to use the application. The password data in 1.3 is stored in the pg_catalog.pg_authid table because the users are full database users.
Hope this clarifies the problem. Pg supports Kerberos auth so if we get a kerberos ticket we can use that. However, I can't see a secure way of doing http-digest auth in this environment.
Best Wishes,
Chris Travers