Updating encryption types

Tom Yu tlyu at MIT.EDU
Wed Jul 6 19:35:02 EDT 2005


>>>>> "phil" == Phil Dibowitz <phil at usc.edu> writes:

phil> [phil at frantic unstale]$ klist -e
phil> Ticket cache: FILE:/tmp/krb5cc_36070
phil> Default principal: phil at ISD.USC.EDU

phil> Valid starting     Expires            Service principal
phil> 07/05/05 13:36:31  07/05/05 23:36:31  krbtgt/ISD.USC.EDU at ISD.USC.EDU
phil>         Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32 

This indicates that your KDC is issuing a TGT which has its
ticket-encrypting key of type des-cbc-crc, which implies that the TGT
principal has at best a single-DES enctype.

phil> and the logs show:

phil> Jul 05 13:36:31 frantic.usc.edu krb5kdc[26284](info): AS_REQ (3 etypes {23 16
phil> 1}) 128.125.10.120: ISSUE: authtime 1120595791, etypes {rep=23 tkt=1 ses=1},
phil> phil at ISD.USC.EDU for krbtgt/ISD.USC.EDU at ISD.USC.EDU

phil> Neither the session key, nor my principal key seem to have been using the new
phil> encryption... it's not clear to me why...

It does list "rep=23", which means that the *reply* is encrypted in
arcfour.  The client shouldn't care about what the ticket-encrypting
enctype is, though some really old implementations erroneously do
care.  The session key choice is limited by the capabilities of the
TGT principal.

---Tom


More information about the Kerberos mailing list