[OpenAFS-devel] verifykt

Marcus Watts mdw@umich.edu
Sat, 13 Jan 2007 03:17:06 -0500


After seeing the recent spate of people having trouble
with keytabs (I think mostly from AD) and openafs, I decided
to write a "verify keytab" utility.  My intent is to do "more or less"
what I had suggested doing by hand (kinit + kvno + perl hack) but
all in one C program that (eventually) we can just tell people to
go run.  So here's what I have (so far):

	adogslife$ ./verifykt -k /tmp/afs.kt 
	Success; princ=<afs@DOGS.UMICH.EDU> vno=3 req.etype=1 ans.etype=1 ticket.length = 160
	adogslife$ ./verifykt -k /tmp/bad.kt 
	Failed in krb5_get_init_creds_keytab - error -1765328353 (Decrypt integrity check failed)
	adogslife$  ./verifykt -k /tmp/ltl-3.keytab
	Success; princ=<afs-k5/cats.umich.edu@CATS.UMICH.EDU> vno=3 req.etype=18 ans.etype=18 ticket.length = 213
	Success; princ=<afs-k5/cats.umich.edu@CATS.UMICH.EDU> vno=3 req.etype=17 ans.etype=18 ticket.length = 197
	Success; princ=<afs-k5/cats.umich.edu@CATS.UMICH.EDU> vno=3 req.etype=16 ans.etype=18 ticket.length = 205
	Success; princ=<afs-k5/cats.umich.edu@CATS.UMICH.EDU> vno=3 req.etype=1 ans.etype=18 ticket.length = 189
	adogslife$ 

It's not obvious from this, but the above utility is going just
a bit farther than "kvno" - it's actually decoding/decrypting
the ticket.  Turns out the ticket is always encrypted under
the "strongest" (probably the first) key type found and there's
no way to make MIT (at least) do different.  Also, if there are
old kvno's in the keytab, there's no way to check those.
On the bright side, it would be silly to accept tickets that
aren't the strongest possible, if the kdc can't generate them.
That means changing rxk5 & verifykt a bit to enforce/check that.

I think the quality of what I can do here is going to depend
a bit on the kerberos library.  The MIT folks seem bound & determined
not to provide interfaces like the above uses that would allow
"non-standard" access to things.  The best thing I can do with MIT
is mk_req/rd_req, which seems a bit silly.  I really like the idea
of having the decrypted but not yet decoded ticket available in this
program.

Anyways, I'm certainly interested in what people think.

				-Marcus