directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject [Kerberos] [core] Service principal keys
Date Sat, 17 Mar 2007 21:25:34 GMT
Hi, Directory developers,

So, we've been discussing deriving keys for user principals based on
passwords.  Similarly, we need to provision keys for service
principals.  Examples of service principals would be daemons for HTTPD
and SSHD that, much like users, would have a Kerberos principal name
and keys in the directory.

The big difference between users and services is that while a user
enters a password to derive a key, services have random keys generated
for them and those random keys must be exported from the DIT to a
file.  An admin backing SSHD with a KDC for authentication needs to:

1)  Create a service principal for SSHD in the DIT.
2)  Somehow flag that principal as requiring a random key (as opposed
to setting a password for the service principal).  This could be as
simple, to start, as using the special keyword "randkey" as the
userPassword and letting a trigger generate random keys.
3)  Now that key needs to be exported to a file.  IMO, looking at the
building blocks we have, a little CLI app that uses client-side JNDI
and LDAP\GSSAPI could use an admin user's Kerberos creds to connect to
the directory, read the key(s), and write them to a keytab file.
4)  An additional issue is that there is a best-practice that when a
key is exported, the key is re-randomized and a version number for the
key is incremented.  This prevents a compromised admin user from using
keys mass-read from the directory.  The compromised admin would have
some keys, but they are now out-of-synch with the keys provisioned to
any hosts/services.

Hopefully in reading the steps, above, you can see how some combo of
trigger/SPs, interceptors, or even extended ops can help (a) randomize
keys, (b) export keys, and (c) re-randomize keys and increment key
versions for keys on export, all using the LDAP protocol.

I wanted to make sure people were aware of the issues and what was
coming.  The above capabilities will let us "close the loop" on
symmetric key lifecycle and we will be much more generally usable as a


View raw message