[16542] in Kerberos_V5_Development
Re: Poor enctype used after rekeying TGT
daemon@ATHENA.MIT.EDU (Tom Yu)
Thu Dec 9 10:46:35 2010
To: Jonathan Reams <jr3074@columbia.edu>
From: Tom Yu <tlyu@mit.edu>
Date: Thu, 09 Dec 2010 10:46:31 -0500
In-Reply-To: <413A8D3B-1B09-4045-A402-ACB64444C2F0@columbia.edu> (Jonathan
Reams's message of "Thu, 9 Dec 2010 10:19:35 -0500")
Message-ID: <ldvbp4v6jag.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: Matt Selsky <selsky@columbia.edu>, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Jonathan Reams <jr3074@columbia.edu> writes:
> We recently rekeyed our krbtgt to take advantage of new and improved encryption types (and slaughter DES-CBC-CRC), and we ended up with 5 keys.
>
> Key: vno 3, DES cbc mode with CRC-32, no salt
> Key: vno 3, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
> Key: vno 3, AES-128 CTS mode with 96-bit SHA-1 HMAC, no salt
> Key: vno 3, ArcFour with HMAC/md5, no salt
> Key: vno 2, DES cbc mode with CRC-32, Version 4
The fifth key (vno 2) is probably because you used the "-keepold" flag
when changing keys. (Which you do probably want, in order to avoid
breaking existing tickets.)
> Everything seems okay there, but when I get a TGT, the skey using a high encryption type, but the tkt is a very weak encryption type.
>
> [minotaur:~]$ klist -e
> Ticket cache: FILE:/tmp/krb5cc_266357_kfGiUN1020
> Default principal: jr3074@CC.COLUMBIA.EDU
>
> Valid starting Expires Service principal
> 12/09/10 09:41:10 12/09/10 19:41:10 krbtgt/CC.COLUMBIA.EDU@CC.COLUMBIA.EDU
> renew until 12/10/10 09:41:10, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, DES cbc mode with CRC-32
>
> What do we need to do to eviscerate DES-CBC-CRC? Can't clients that understand the better types get them automatically?
You should probably change TGT keys again, after reordering your
supported_enctypes list (or use the "-e" option when changing the
key), putting the AES keys enctypes first. You could possibly omitt
single-DES completely, but that may break the issuing of single-DES
session keys for applications that need it.
[realms]
EXAMPLE.ORG = {
supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal arcfour-hmac-md5:normal
}
The KDC encrypts tickets using the first enctype in the key list of
the max kvno of that service. The "tkt" enctype is the enctype of the
service key that the service (in this case the TGS) will use to
decrypt the ticket, and the client has no need to know about that
enctype. (There was a very very old bug -- 1.0.x or even earlier --
where clients would reject tickets due to an unrecognized service key
enctype, even when the session key enctype was OK.)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
