openssh unix dev - Jul 2001 - openssh keys in ldap

Is there any work going into placing keys in a central directory such as
LDAP ?

Jeff McElroy
jmcelroy at dtgnet.com

On Monday 16 July 2001 15:16, you wrote:
> Is there any work going into placing keys in a central directory such as
> LDAP ?
We're doing it ...

I've got a script which uploads the keys to the LDAP server (over a Kerberos
authenticated connection) and generates the ssh_known_hosts file (again using 
a Kerberos authenticated connection). We drive this from an rc.d style script 
which generates and uploads the key as necessary, and updates the known_hosts 
file nightly. All of this doesn't require touching the ssh code base at all.

Our LDAP map is RFC2307-compliant - we add a new 'sshHost' auxiliary
object
class to the host records in it, which adds 'sshKey' and
'sshRSAKey'
attributes to each host's information. These are used for version 2 and 
version 1 host keys respectively - the sshKey attribute is multi-valued 
allowing the use of different types of version 2 keys.

If you're interested I can package up the script, our schema definitions,
and
the (OpenLDAP) server configuration thats required to make all of this work
and make it available.

Cheers,

Simon.

-- 
Simon Wilkinson            <simon at sxw.org.uk>         
http://www.sxw.org.uk
"I don't want to live on in my work, I want to live on in my
apartment."
 -- Woody Allen

> we assume the ldap server is secure, 
If you manage the LDAP server, then you can assume it is secure.  Are you 
willing to hand your private keys to a server you don't control?  Maybe I 
am just paranoid, but in my line of work... ;-)

My private key stays on a machine which I control and it never traverses 
the network, encrypted or not.  I generated it, I protect it and so I 
trust it.  We should educate our users to treat their private keys with 
the same respect.

Simple, clear rules are most likely to be followed.

--------------------------------------------------------
  Doug Manton, AT&T EMEA Commercial Security Solutions

               E:  demanton at att.com
--------------------------------------------------------
"If privacy is outlawed, only outlaws will have privacy"

> If the keys stay encrypted (not counting ssl) until ssh-add decrypts 
them (in the
> same manner that it decrypts the private keys off the filesystem). Would 
we need to
> trust the LDAP server or transport protocol.  What problems would we 
encounter with
> this?
The private key encryption is a fallback position -- the first line of 
protection is to keep the key private!  This is the same reason that most 
UNIX systems use shadow password files.

If we rely on the key encryption, can we trust our users to select strong 
passphrases?  We can't enforce passphrase rules because of the nature of 
key generation.  Dictionary attacks demonstrate that users will do 
anything in their power to select poor passphrases!

My personal preference is the exact opposite approach.  Stick the private 
key onto some kind of smartcard.  The ideal smartcard would run the 
SSH-agent itself and never reveal the key to anyone, you just initialise 
it with your passphrase before use -- and when you unplug it or a timeout 
occurs, it forgets the key and prompts upon next use.

Doug.

On Mon, 16 Jul 2001, jeff mcelroy wrote:
> Is there any work going into placing keys in a central directory such as
> LDAP ?
I see a problem with finding out what ldap server that has the key for
host.example.com? and then communicate securly and fast enough with that
server.

I would rather consider the dnssec support to be the preferred key
distribution mechanism in the future.


	jakob, dnssec advocate

On Wed, 18 Jul 2001, Jakob Schlyter wrote:
> On Mon, 16 Jul 2001, jeff mcelroy wrote:
>
> > Is there any work going into placing keys in a central directory such
as
> > LDAP ?
>
> I see a problem with finding out what ldap server that has the key for
> host.example.com? and then communicate securly and fast enough with that
> server.
>
> I would rather consider the dnssec support to be the preferred key
> distribution mechanism in the future.
I think the original meant placing keys of all servers _within
organization_ to a central _internal_ directory.

This is what I though of it at any rate.

For "global" secure key access, dnssec is the way to go (if you want
to
put them in a database at any rate, and can proof the transaction).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

Pekka Savola wrote:
> On Wed, 18 Jul 2001, Jakob Schlyter wrote:
> > On Mon, 16 Jul 2001, jeff mcelroy wrote:
> >
> > > Is there any work going into placing keys in a central directory
such as
> > > LDAP ?
> >
> > I see a problem with finding out what ldap server that has the key for
> > host.example.com? and then communicate securly and fast enough with
that
> > server.
> >
> > I would rather consider the dnssec support to be the preferred key
> > distribution mechanism in the future.
>
> I think the original meant placing keys of all servers _within
> organization_ to a central _internal_ directory.
>
> This is what I though of it at any rate.
>
> For "global" secure key access, dnssec is the way to go (if you
want to
> put them in a database at any rate, and can proof the transaction).
>
> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
    We have openssh deployed accross our organization and have to add/remove
entries into the known_hosts / authorized_keys files often.  I am looking for a
way to centrally manage these keys.

Jeff McElroy
jmcelroy at dtgnet.com