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