[PATCH] add support to kadm5 for removing old kvnos

[Henry B. Hotz]

Yes!!!  Excellent!!!

On Apr 26, 2006, at 9:02 AM, krbdev-request at mit.edu wrote:

> Date: Tue, 25 Apr 2006 12:45:23 -0400 (EDT)
> From: Christopher Allen Wing <wingc at engin.umich.edu>
> Subject: [PATCH] add support to kadm5 for removing old kvnos
> To: krbdev at mit.edu
> Message-ID: <Pine.LNX.4.63.0604251224420.20580 at gx620.engin.umich.edu>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> In krb5-1.4.3, there is no way to remove old kvnos for a principal  
> whose
> password was changed using the -keepold option in kadmin.  This is of
> interest when rekeying the TGS key as per the kadmin man page:
>
>  	kadmin:  cpw -randkey -keepold krbtgt/REALM.NAME
>
>
> I made a patch against 1.4.3 which adds a new kadm5 RPC called  
> 'flushkeys'
> to remove old kvnos.  The patch does the following:
>
>  	1. define FLUSHKEYS_PRINCIPAL kadm5 RPC (#22)
>
>  	2. add kadm5_flushkeys_principal() API to libkadm5clnt and
>  	   libkadm5srv
>
>  	3. hook up support in kadmind, using the 'setkey' ACL permission
>  	   (seems reasonable)
>
>  	4. added 'flushkeys' command to kadmin client
>
>  	5. update man pages and documentation
>
>
> I'm unsure if the patch is too long for this mailing list (561  
> lines, 18K
> of text); you can get it from here:
>
>  	http://www-personal.engin.umich.edu/~wingc/mitk5/krb5-1.4.3- 
> flushkeys.patch
>
> I can send it to the list, or break it up into logical pieces and  
> send it
> if that would be better.
>
>
> Does the patch seem reasonable?  The FLUSHKEYS_PRINCIPAL RPC just  
> removes
> all keys for a principal which are older than the current max  
> kvno.  If
> all keys have the same kvno then it does nothing.
>
> As far as I can guess, this would only be needed for rekeying the  
> TGS key,
> which can be done (with the patch) as follows:
>
>
>  	kadmin:  cpw -randkey -keepold krbtgt/REALM
>
> (now wait until all previously issued TGTs have expired)
>
>  	kadmin:  flushkeys krbtgt/REALM
>
> (this removes the old kvnos for the TGS key)
>
>
>
> All other service principals should be able to be rekeyed by doing a
> regular 'ktadd' and storing the new keys into the application server's
> keytab along with the old kvnos.  The old kvnos shouldn't have to  
> stay in
> the KDC database for any reason, right?
>
>
> TGS rekeying isn't too common, but it is necessary e.g. when upgrading
> encryption types on an existing krb5 realm.  It would be nice to  
> handle
> this gracefully without hacks like manually editing the old kvnos  
> out of
> the database with a dump.
>
> I can re-do the patch against the latest CVS code if the patch is
> undesirable for 1.4 but would be considered for 1.5.
>
>
> Thanks,
>
> Chris Wing
> wingc at engin.umich.edu