[OpenAFS] asetkey, aklog and weird key/principal

Marcus Watts mdw@umich.edu
Tue, 09 Jan 2007 08:13:03 -0500


Turbo Fredriksson <turbo@bayour.com> had sent:

...
> Just if it matters, I compared the keyfiles as well.
> 
> ----- s n i p -----
> root@nnwux002:/usr/afs/etc# klist -k unixkeytab -t -K
> Keytab name: FILE:unixkeytab
> KVNO Timestamp         Principal
> ---- ----------------- --------------------------------------------------------
>    3 01/01/70 01:00:00 afs/<cell>@<REALM> (0xe9801968ba2aada4)
> root@nnwux002:/usr/afs/etc# klist -k keytab.file -t -K
> Keytab name: FILE:keytab.file
> KVNO Timestamp         Principal
> ---- ----------------- --------------------------------------------------------
>    3 01/09/07 11:14:13 afs/<cell>@<REALM> (0x83dab01c6bb03701)
> root@nnwux002:/usr/afs/etc# 
> ----- s n i p -----
> 
> They ARE different, but since neither work... ? Did I miss restarting
> something?  I'we been waiting for more than the 'AD sync time' so it
> can't be that...

So the situation is you have 2 keytabs, and you don't
know which one is good.  The timestamp is no good (it has no
functional significance to the software, and in this case
it isn't useful to you either.)  The vno is the same, so we
know at least one of these files is for sure bogus.

Fortunately, it's easy to validate which keytab is good.

For instance, taking an afs keytab I happen to have just lying around:
	spam% klist -kte /tmp/afs.kt 
	Keytab name: FILE:/tmp/afs.kt
	KVNO Timestamp         Principal
	---- ----------------- --------------------------------------------------------
	   3 05/12/04 17:56:28 afs@DOGS.UMICH.EDU (DES cbc mode with CRC-32) 
	spam% kinit -kt /tmp/afs.kt afs@DOGS.UMICH.EDU 
	spam% klist -5fea
	Ticket cache: FILE:/tmp/krb5cc_25131_a7CIlU
	Default principal: afs@DOGS.UMICH.EDU

	Valid starting     Expires            Service principal
	01/09/07 05:57:02  01/10/07 05:57:02  krbtgt/DOGS.UMICH.EDU@DOGS.UMICH.EDU
		Flags: FPI, Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1 
		Addresses: (none)
	spam% 

If I can authenticate with the keytab, I've got one that should
also be capable of decrypting service ticket.  So, let us first
get a service ticket.
	spam% kvno -e des-cbc-crc afs@DOGS.UMICH.EDU
	afs@DOGS.UMICH.EDU: kvno = 3
	spam% klist -5fea
	Ticket cache: FILE:/tmp/krb5cc_25131_a7CIlU
	Default principal: afs@DOGS.UMICH.EDU

	Valid starting     Expires            Service principal
	01/09/07 05:57:02  01/10/07 05:57:02  krbtgt/DOGS.UMICH.EDU@DOGS.UMICH.EDU
		Flags: FPI, Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1 
		Addresses: (none)
	01/09/07 06:03:11  01/10/07 05:57:02  afs@DOGS.UMICH.EDU
		Flags: FPT, Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32 
		Addresses: (none)
	spam% 

Now I have a service ticket.  I can see that the kdc gave me kvno 3,
which is good, that's what I expect to see.  I could just stop here.
But if I want to be really thorough and chase this to the end, I ought
to decrypt the ticket using the keytab.  Unfortunately, there's no
handy kerberos utility that will just do that.  Fortunately, there are
other ways.  If we don't care about bullet-proofness, parsing a keytab can be
real trivial: for this simple case (one des-cbc-crc32 key) the last 8 bytes are
always going to be the key.  The ticket file isn't so trivial, but stepping backwards
from the end looking for the length and appl[3] tag is likely to be effective.
So here's a perl script that makes a few silly assumptions like this
to decrypt the last ticket in the k5 credentials cache using the last key in
the keytab file:
	spam% perl /afs/umich.edu/user/m/d/mdw/bin/decst.pl /tmp/afs.kt /tmp/krb5cc_25131_a7CIlU
	Y4GLMIGIoAcDBQBQCAAAoRMwEaADAgEBoQoECB8CZyyD+BzvohAbDkRPR1MuVU1JQ0guRURVoxAw
	DqADAgEBoQcwBRsDYWZzpAswCaADAgEBoQIEAKURGA8yMDA3MDEwOTEwNTcwMlqmERgPMjAwNzAx
	MDkxMTAzMTFapxEYDzIwMDcwMTEwMTA1NzAyWg==
	spam% 

Did the decrypt work?  Is this really valid?  A real kerberos
server would know right here.  The perl script isn't that smart.
But, if all went well, that output is the pem-encoded version of the
decrypted ticket.  Conveniently, this is exactly what openssl likes to read:

	spam% /afs/umich.edu/user/m/d/mdw/bin/decst.pl /tmp/afs.kt /tmp/krb5cc_25131_a7CIlU | openssl asn1parse -dump -i
	    0:d=0  hl=3 l= 139 cons: appl [ 3 ]        
	    3:d=1  hl=3 l= 136 cons:  SEQUENCE          
	    6:d=2  hl=2 l=   7 cons:   cont [ 0 ]        
	    8:d=3  hl=2 l=   5 prim:    BIT STRING        
	      0000 - 00 50 08                                          .P.
	      0005 - <SPACES/NULS>
	   15:d=2  hl=2 l=  19 cons:   cont [ 1 ]        
	   17:d=3  hl=2 l=  17 cons:    SEQUENCE          
	   19:d=4  hl=2 l=   3 cons:     cont [ 0 ]        
	   21:d=5  hl=2 l=   1 prim:      INTEGER           :01
	   24:d=4  hl=2 l=  10 cons:     cont [ 1 ]        
	   26:d=5  hl=2 l=   8 prim:      OCTET STRING      
	      0000 - 1f 02 67 2c 83 f8 1c ef-                          ..g,....
	   36:d=2  hl=2 l=  16 cons:   cont [ 2 ]        
	   38:d=3  hl=2 l=  14 prim:    GENERALSTRING     
	      0000 - 44 4f 47 53 2e 55 4d 49-43 48 2e 45 44 55         DOGS.UMICH.EDU
	   54:d=2  hl=2 l=  16 cons:   cont [ 3 ]        
	   56:d=3  hl=2 l=  14 cons:    SEQUENCE          
	   58:d=4  hl=2 l=   3 cons:     cont [ 0 ]        
	   60:d=5  hl=2 l=   1 prim:      INTEGER           :01
	   63:d=4  hl=2 l=   7 cons:     cont [ 1 ]        
	   65:d=5  hl=2 l=   5 cons:      SEQUENCE          
	   67:d=6  hl=2 l=   3 prim:       GENERALSTRING     
	      0000 - 61 66 73                                          afs
	   72:d=2  hl=2 l=  11 cons:   cont [ 4 ]        
	   74:d=3  hl=2 l=   9 cons:    SEQUENCE          
	   76:d=4  hl=2 l=   3 cons:     cont [ 0 ]        
	   78:d=5  hl=2 l=   1 prim:      INTEGER           :01
	   81:d=4  hl=2 l=   2 cons:     cont [ 1 ]        
	   83:d=5  hl=2 l=   0 prim:      OCTET STRING      
	   85:d=2  hl=2 l=  17 cons:   cont [ 5 ]        
	   87:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20070109105702Z
	  104:d=2  hl=2 l=  17 cons:   cont [ 6 ]        
	  106:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20070109110311Z
	  123:d=2  hl=2 l=  17 cons:   cont [ 7 ]        
	  125:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20070110105702Z
	spam% 

That's a perfectly good ticket, therefore, unless basic crypto
in the kdc is broken (seems unlikely), we have success.

Note; if the ticket we get here is over about 1400 bytes, it won't
work with afs.  There's a trick for that, which other people here
can answer better than I.

...

				-Marcus Watts