Understanding Session/Service Encryption Types

[John Harris]

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