Interop/Compat: 3DES used in AS-REP despite no client support

[Brian Davidson]

You generally want to support all key types on your KDC.  You can 
restrict the key type from within kadmin:

kadmin: cpw -e "rc4-hmac:normal" krbtgt/AD.EXAMPLE.COM

Service principals should contain ONLY the key types supported by that 
service (i.e. rc4-hmac, des-cbc-md5, des-cbc-crc in the case of 
Windows).  User principals generally should contain ALL supported key 
types.  The client will send a list of supported key types to the KDC 
when requesting a service ticket.  The KDC compares that list with the 
key types available for the service.  The "strongest" (as specified by 
the client) key type is used for the session key.

The important bit is that the service you're connecting to is never 
asked what keys it supports.  The KDC assumes that all keys present on 
the KDC for that service are usable by the service.

RC4-HMAC is usable on Windows 2003 SP1, but you'll need to run:

ktpass -MitRealmName AD.EXAMPLE.COM -TrustEncryp RC4

after you have set up the trust, to get it to work.  You can ONLY (I'm 
95% sure) have an rc4-hmac key for the krbtgt/AD.EXAMPLE.COM principal.

You have to be careful with what key types are used for all of your 
host/*, krbtgt/*, ldap/*, etc principals.  The user principals should 
contain all key types supported by the KDC, unless you have a 
compelling reason not to and know what you're doing.


A ticket ends up using 3 keys, which may all be different key types:

1. shared session key - this is randomly generated by the KDC.  It must 
be a key type supported by both the client and the service.

2. client's key - The client must support this key type, and the 
principal must have a key of this type in the KDC.  Your password gets 
converted to this key during kinit, for example.

3. service's key - known by the server you're connecting to, and the 
KDC.

There are 2 copies of the shared session key.  One gets encrypted with 
the client's key, the other gets encrypted with the service's key.  It 
is entirely possible for 3 different types of keys to be used.  If user 
principals have keys of all possible types, and service principals only 
have keys of supported key types, it all works.

Windows 2003 R2 is supposed to add support for aes-128 and aes-256.  I 
don't know if that will be usable for cross-realm trusts or not.  Until 
SP1, rc4-hmac couldn't be used, even though it was a supported enctype 
for user and host principals...

Windows 2003 SP1 breaks kerberos authentication with Terminal Services. 
  Microsoft has a patch, KB902336 for this problem.  That KB article 
isn't public, but they should be able to provide you with a patch if 
you call and ask for it.

Brian Davidson
George Mason University

On Dec 7, 2005, at 12:48 PM, Matt wrote:

> Thank you for that info.
>
> I was able to solve the immediate problem by adding permitted_enctypes
> = rc4-hmac des-cbc-md5 des-cbc-crc to the [libdefaults] section of
> kerb5.conf. This caused DES to be used for all enc-parts and did allow
> the Windows KDC to issue a service ticket. This causes another problem,
> though, which is that I am unable to restart kadmind with the error: No
> matching key in entry having a permitted enctype
>
> Based on your statements, it would seem that a superior solution would
> be to ensure that for all the principals I create (user principals and
> the cross realm krbtgt/A.A at X.X) only RC4 and DES keys should be created
> and stored.
>
> How can I accompish this? I would be happy to recreate the principals
> after changing a setting, but I can't seem to find this configuration.
>
> With no enctype restrictions set anywhere, I would think that every MIT
> supported key type would be created and stored upon principal creation
> (ank <principal> within kadmin). But at present it seems that on my
> system only 3DES and DES keys are created, never RC4. My indications
> that this is happening are 1) If I create a principal (while no enctype
> restrictions are in place), and then try to authenticate that principal
> on a clinet which requests DES and RC4, DES (and 3DES for the first enc
> part) is always used in the response, never RC4. Also, if I use ktadd
> to export a keytab for that principal, only 3DES and DES keys are
> exported, never RC4. This leads me to believe that RC4 keys are never
> generated.
>
> Given that this is a Windows interop scenario, I think that I would
> want the MIT KDC and/or kadmin to create and store RC4 and DES (and no
> other) keys for all principals that I create. So far in my fumbling
> inexperience I have not been able to accomplish this. I tried to
> accomplish this by setting the supported_enctypes for the realm in
> kdc.conf to rc4-hmac des-cbc-md5:normal des-cbc-crc:normal but after
> restarting and creating a new principal, it still appears to store only
> 3DES and DES keys.
>
> Help!
>
> Thanks
>
> -Matt
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>