Re: Working on a security best practices document

[Michael Richardson <..hidden..>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Chris" == Chris Travers <..hidden..> writes:
    Chris> I was thinking more along the lines of authenticating that
    Chris> the certificate maps to a specific user, short of requiring
    Chris> the username in the cert.  LDAP might make it easier to avoid
    Chris> problems.

    >> LDAP is neutral to the problem.  It's just a database with a poor
    >> interface, and an inflexible schema.  We have a much more
    >> sophicated database :-)

    Chris> Don't get me wrong: I think that both LDAP and SSL suck.
    Chris> However, the original concept was that the system which SSL
    Chris> was ported from (X.501) would be based fundamentally on the
    Chris> system LDAP was ported from (X.500), so I think a proper SSL
    Chris> certificate system for a company will probably depend on
    Chris> LDAP.

  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... )

  It's good thinking, but it just isn't important.

    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...

    >> You can map the certificate by DN (no matter what is there), by
    >> just adding a column to the users table.  Or you can be more
    >> ssh/spki-like and just use the sha1 of the public key in the
    >> certificate.  There are pros and cons of each method.
    >> 

    Chris> True.  However, there are some things you can do here via
    Chris> LDAP which are beyond the mechanism you propose.  For
    Chris> example, using LDAP and OpenSSL, one could allow new
    Chris> certificates to be issued, check the cert info against the
    Chris> ldap info, and then apply other standard checks.  This
    Chris> provides a single-point check to show that the certificate
    Chris> was issued to the correct user and that it is valid.

  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.

    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.
  (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.
  
    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.

    >> 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.
 
  If one wanted to stick with HTTP Basic, one could encrypt the database
access columns with the user's password and if they decrypt okay, then
we use that to connect to the database. The downside of this is that it
only works with HTTP Basic.
  I think we are better off going to HTTP Digest authentication,
encrypting the database columns involved (the users' password and the
database access passwords) with a per-dataset password.
  Store the per-database password somewhere: if it's in another table,
then encrypt that colume with a password from a file.  If it's stored
in a flat file, great.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] ..hidden.. http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS2qB5ICLcPvd0N1lAQKTMwf/dUF0dVLw5lnN/MozfnBcUq16h2e40XPG
S4xdSUk/V56lZ87A6MMv1rhazWCo4pMu8sJRng1lozmuCliIrhd7Qa7/PoQ6mMRe
Zc3WsHxpqm60NSJiPcO0xJwe/JMHZllFbJ5C7OTVWEex0T/K5bI4nQ9aLEPEFMCO
Od8e/jbJy3PlBSwkX28qBjuTxBy0qqo+NnR8y7xebFjPBf6uCiICQSsPDyK0lXNe
QNcsG1pB4A0pXaZoe/LUy/kolo2k5SL5OvOr9nOW3SJZXvsazwfPMFh9o9bBtIUl
pCnSV54t7UKl+XBMV0hpamKXgSM3VaXNzWb5dSb03uSCYQGyb0stqA==
=XcGJ
-----END PGP SIGNATURE-----