Understanding Session/Service Encryption Types
John Harris
harris at ucdavis.edu
Tue Apr 1 16:11:14 EDT 2008
Greetings,
I'm trying to understand the interrelationship between the session key
encryption type and the service principal encryption type. My confusion
stems from our infrastructure always having had just one encryption type
available, and it being of a low-level, so both the session key and the
service encryption type were always valid and understood by all
clients. In those cases, klist -e always returned des-cbc-crc for both
and away we went.
Now that we're attemping to bump our encryption levels a bit, I run into
weird behavior that I don't expect. It appears that the session key is
encrypted at the level a client can understand (whatever the highest
level it can, like des for old Solaris, or aes-128 for Solaris 10, or
aes-256 for others, etc.), but the principal encryption type is always
reported as aes-256.
Does it not matter what the service principal is encrypted with as long
as the KDC can understand it with the session key? This example show
that the session key encryption type is lowering itself to the level the
client can understand, but using the highest level available for the
principal key:
a) a principal with only rc4 and des on it's KDC list (with the default
krbtgt having all encryption types) and being obtained from an old
Solaris box. I note the des-cbc-crc session key type is what Solaris
can handle, and it obtains the ticket, and uses the highest level the
krbtgt/MYREALM.EDU type available.
harris at tsurnami>klist -e
Ticket cache: /tmp/krb5cc_7304
Default principal: testuser at MYREALM.EDU
Valid starting
Expires Service principal
Tue 01 Apr 2008 12:04:52 PM PDT Wed 02 Apr 2008 12:04:52 PM PDT
krbtgt/MYREALM.EDU at MYREALM.EDU
renew until Tue 01 Apr 2008 12:04:52 PM PDT, Etype(skey, tkt):
DES-CBC-CRC, unsupported encryption type 18
I can then use this ticket to a get the service principal that just has
rc4 and des on it's list:
harris at tsurnami>klist -e
Ticket cache: /tmp/krb5cc_7304
Default principal: krbtgt/TESTCROSS.MYREALM.EDU at MYREALM.EDU
Valid starting
Expires Service principal
Tue 01 Apr 2008 01:04:49 PM PDT Wed 02 Apr 2008 01:04:49 PM PDT
krbtgt/TESTCROSS.MYREALM.EDU at MYREALM.EDU
renew until Tue 01 Apr 2008 01:04:49 PM PDT, Etype(skey, tkt):
DES-CBC-CRC, unsupported encryption type 23
So I'm hoping to be educated on why this actually works.
-----
Secondly, I thought that Windows XP did not support AES (at all), but
the Identity Network Manager in Kerberos for Windows is reporting both
the session key and the service as encrypted with AES-256 (the caveat
being that said principal is in the KDC with that type obviously). Does
the KfW add functionality that recognizes AES and so reports it (and
would be used to contact the KDC to get additional principals with types
the service could use), or is it misreporting it, or am I a dodo and am
unaware of XP being AES functional?
Sincerely,
J
More information about the Kerberos
mailing list