Admittedly, all the calls where the KDC was searching for the latest kvno,
it was also passing -1 for the other two values.

But, by having the function treat 0 as a special case for retrieving the
latest kvno, it creates issues if you are trying to do a cpw on a key with
-keepold and it was previously kvno=0.  In my case, I had a database with
krbtgt where kvno=0 because it was created in the early 1990s (back when the
db_creation initialized with kvno=0 instead of kvno=1).  Trying to update
the key while maintaining compatibility with clients was proving
problematic.  Basically, in this case, all client caches would become
"invalid" instantly if I were to update krbtgt, whereas had kvno >= 1, there
would have been no issue.

Any ideas how we should fix this case?  (I hacked the files I stated so I
didn't impact all the clients.)

You can probably infer the exact situation I am facing, since I was planning
to randomize the krbtgt in the upcoming couple weeks for a large Kerberos
installation (with hundreds of millions of authentications daily and where I
cannot simply invalidate everyone's ticket caches, even during a low-usage
period).


-----Original Message-----
From: Greg Hudson via RT [mailto:rt-comment@krbdev.mit.edu] 
Sent: Thursday, October 25, 2012 7:35 PM
To: basch@alum.mit.edu
Subject: [krbdev.mit.edu #7432] krb5-1.10.3: Updating krbtgt with kvno 0 

krb5_dbe_def_search_enctype does not currently treat kvno 0 the same way 
as kvno -1.  kvno -1 means "ignore the kvno", while kvno 0 means "search 
only in the highest kvno".  (Confusingly, if you pass kvno, stype, and 
ktype all as -1, the code optimizes by setting kvno to 0 in order to look 
only at entries of highest kvno, without a comment explaining what it's 
doing.)

It may be that we don't need both modes of operation.  Offhand, I can't 
imagine a situation where you want to search for a particular enctype 
and/or salt type across all key versions.  But we'd need to analyze all 
of the call sites to make sure of that.