[OpenAFS-devel] verifykt

[Derrick J Brashear]

asetkey should get this functionality inboard. you want to do it or should 
i?

On Sat, 13 Jan 2007, Marcus Watts wrote:

> 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
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>