Automatically randomizing principal keys (in preauth plugin)

Yair Yarom irush at
Thu Mar 24 12:45:33 EDT 2011

Thanks for the detailed reply. 

Greg Hudson <ghudson at MIT.EDU> writes:

> On Wed, 2011-03-23 at 07:51 -0400, Yair Yarom wrote:
>> 1. Have the preauth plugin check if there's a key available, and if not
>>    create a random one and insert it into the database. Is this
>>    possible? If so how and where in the plugin should I do it?
> I think it's possible, just by making krb5_db_* calls in the verify_proc
> with the provided context.  It doesn't seem very clean, but I can't
> think of a reason why it wouldn't work.

I've tried this by using krb5_dbe_ark, which seems to work but with two

1. Is there a way to get the master key (and some salts) from the kdc?
   my current method (more or less copied from
   kdb5_util.c:add_random_key) is to call krb5_db_setup_mkey_name,
   krb5_read_realm_params and krb5_db_fetch_mkey. But if the kdc was
   started with special parameters, this might not work properly.

2. The database isn't updated. I actually prefer that the database won't
   be updated, but then I wonder how does it work? I.e. the kdc appears
   to find the client key, but just until the next 'kinit' where the
   plugin randomizes a new key (as it can't find one).

>> 2. Have all users have the same static (random) key. Here the question
>>    is how insecure is it? i.e. I force the use of my preauth plugin as
>>    it's the only one installed that provides HW authentication
>>    (allegedly). So is this key actually used anywhere?
> I think you'd want to set the KRB5_KDB_DISALLOW_SVR flag on the user
> principals so people couldn't print service tickets for them.  Beyond
> that, I can't think of a risk, although that doesn't mean there isn't a
> risk.
>> Any other suggestion would be appreciated.
> Depending on your deployment requirements, it might be possible to alter
> the KDC to allow principals with no keys.  I think we would need to
> create a new preauth plugin flag for "I don't need an input reply key"
> to avoid incompatibilities with existing plugins.

I've checked this, and the kdc checks in process_as_req for the client
key. By setting a random key if it doesn't exists, everything seems to
work. However, as I'm still not very familiar with the kdc code, I
prefer not to change it.


More information about the krbdev mailing list