[PATCH] s3-krb5: Limit search for old kvno to 8bits

[Jeremy Allison]

On Wed, May 07, 2014 at 09:28:29AM -0700, Christof Schmitt wrote:
> On Wed, May 07, 2014 at 09:18:35AM +0200, Volker Lendecke wrote:
> > On Tue, May 06, 2014 at 08:57:52PM -0700, Christof Schmitt wrote:
> > > >From cb0e25d1eb52e15f9c771a5d99027ab4afed3168 Mon Sep 17 00:00:00 2001
> > > From: Christof Schmitt <cs at samba.org>
> > > Date: Tue, 6 May 2014 16:48:07 -0700
> > > Subject: [PATCH] s3-krb5: Limit search for old kvno to 8bits
> > > 
> > > Some keytab files store the kvno only in 8bits. Limit the compare to
> > > 8bits, so that we don't miss old keys and delete them. This fixes the
> > > problem that updates to the keytab file removed all previous keys.
> > 
> > What kerberos library does this? And -- does this make sure
> > we don't delete too much on libraries that have wider kvnos?
> > Is there a way to detect this? If I'm asking stupid
> > questions, please excuse my Kerberos illiteracy :-)
> 
> I have seen this while experimenting with 'kerberos method' set to
> 'secrets and keytab' on a RHEL6 system. 
> 
> Without this patch, running 'net ads keytab create -P' or 'net ads
> changetrustpw' only puts the newest keys in the keytab, but does not
> keep the previous ones.
> 
> In the debug output i see that 32bit values are passed to the krb lib,
> but only 8bit values are returned:
> 
> # net ads changetrustpw -d5
> ...
> libads/kerberos_keytab.c:136: Found old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71) - trying to remove it.
> libads/kerberos_keytab.c:153: removed old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71).
> libads/kerberos_keytab.c:136: Found old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71) - trying to remove it.
> libads/kerberos_keytab.c:153: removed old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71).
> libads/kerberos_keytab.c:136: Found old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71) - trying to remove it.
> libads/kerberos_keytab.c:153: removed old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71).
> libads/kerberos_keytab.c:136: Found old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71) - trying to remove it.
> libads/kerberos_keytab.c:153: removed old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71).
> libads/kerberos_keytab.c:136: Found old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71) - trying to remove it.
> libads/kerberos_keytab.c:153: removed old entry for principal: host/st001.virtual1.com at VIRTUAL1.COM (kvno 71).
> libads/kerberos_keytab.c:234: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (1) and version (3400)
> libads/kerberos_keytab.c:234: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (3) and version (3400)
> libads/kerberos_keytab.c:234: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (17) and version (3400)
> libads/kerberos_keytab.c:234: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (18) and version (3400)
> libads/kerberos_keytab.c:234: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (23) and version (3400)
> ...
> 
> klist -k also returns only the 8bit values. I don't know the internals
> of kerberos, but this file format document suggests that storing the
> 32bit field is optional: http://www.ioplex.com/utilities/keytab.txt
> 
> With the patch applied, the previous keys (kvno - 1) are kept and the
> debug output also shows that the comparison works as intended:
> 
> libads/kerberos_keytab.c:65: Will try to delete old keytab entries libads/kerberos_keytab.c:126: Saving previous (kvno 3400) entry for principal: host/st001.virtual1.com at VIRTUAL1.COM.
> libads/kerberos_keytab.c:126: Saving previous (kvno 3400) entry for principal: host/st001.virtual1.com at VIRTUAL1.COM.
> libads/kerberos_keytab.c:126: Saving previous (kvno 3400) entry for principal: host/st001.virtual1.com at VIRTUAL1.COM.
> libads/kerberos_keytab.c:126: Saving previous (kvno 3400) entry for principal: host/st001.virtual1.com at VIRTUAL1.COM.
> libads/kerberos_keytab.c:126: Saving previous (kvno 3400) entry for principal: host/st001.virtual1.com at VIRTUAL1.COM.
> libads/kerberos_keytab.c:237: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (1) and version (3401)
> libads/kerberos_keytab.c:237: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (3) and version (3401)
> libads/kerberos_keytab.c:237: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (17) and version (3401)
> libads/kerberos_keytab.c:237: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (18) and version (3401)
> libads/kerberos_keytab.c:237: adding keytab entry for (host/st001.virtual1.com at VIRTUAL1.COM) with encryption type (23) and version (3401)

Pretty compelling stuff :-). Wow, just looked
at that doc - what a *mess* :-).

"The 8 bit vno8 field is the version number of the key. This value is
overridden by the 32 bit vno field if it is present."

so the caller has no way of knowing, as far
as I can see, if the kvno field stored and
returned is 8 bit or 32 bit :-(.

Jeremy.