[31489] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Zero-length entry in a keytab: why?!

daemon@ATHENA.MIT.EDU (Nathan Patwardhan)
Fri Sep 18 11:02:28 2009

X-Barracuda-Envelope-From: noopy.org@gmail.com
MIME-Version: 1.0
In-Reply-To: <4AB2D585.5050700@mit.edu>
Date: Fri, 18 Sep 2009 07:17:32 -0400
Message-ID: <cba4e37e0909180417t308ff22dkbca6fb14576a54b4@mail.gmail.com>
From: Nathan Patwardhan <noopy.org@gmail.com>
To: Ezra Peisach <epeisach@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

On Thu, Sep 17, 2009 at 8:34 PM, Ezra Peisach <epeisach@mit.edu> wrote:
> ---------- Forwarded message ----------
> From: Ezra Peisach <epeisach@mit.edu>
> To: kerberos@noopy.edu
> Date: Thu, 17 Sep 2009 20:34:13 -0400
> Subject: Re: Zero-length entry in a keytab: why?!
> Howdy,
>
> a) You describe a variable bytesRemain - neither MIT nor Heimdal use such a
> variable - so this might be your code.

Yes, these variables are in my code.  Thought I'd mentioned that.
Sorry if I wasn't clear.  :-(

>
> b) You mention a vendor app writing such a keytab with holes - care to
> mention who? I suspect they might have extended their definition of a keytab
> in a non-standard way... You can ask the vendor...

Centrify.

> d) Heimdal has another extension -after the version number, if there are 4
> bytes - a flag for the entry can be stored.... Not sure off hand what for...

Yeah, I think this describes what I'm seeing -- even if not specific to Heimdal.

http://www.gnu.org/software/shishi/manual/html_node/The-Keytab-Binary-File-Format.html
http://www.h5l.org/manual/heimdal-1-2-branch/krb5/page_fileformats.html

>
> e) You mention that klist and ktutil can read the keytab - which vendor
> program are you using? I suspect not MIT.

If I'm seeing things correctly, Centrify ships with its own version of
the MIT binaries (klist, kinit, etc).  But your assertion made me
think about Heimdal a lot.  I am going to read their keytab code and
see if I can understand where things might be amiss here.  Certainly
there are many, many cases in my existing keytab where there are *NO*
extra bytes after the keyblock, and even when i look at the bytes
after the keyblock I can't figure how these would represent a vno for
that matter.

Also, looking further at the keytab in a binary editor I see a ton of
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ffffff at the end of the file --
without any other keytab entries following that data.  This just
doesn't seem like the case in any other keytabs I've looked at.

--
K
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post