[krbdev.mit.edu #7432] krb5-1.10.3: Updating krbtgt with kvno 0
Richard Basch via RT
rt-comment at krbdev.mit.edu
Thu Oct 25 22:06:24 EDT 2012
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 at krbdev.mit.edu]
Sent: Thursday, October 25, 2012 7:35 PM
To: basch at 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.
More information about the krb5-bugs
mailing list