Updating encryption types

[Jeffrey Hutzelman]

On Friday, July 01, 2005 02:14:02 AM -0700 Phil Dibowitz <phil at usc.edu> 
wrote:

> So reading through:
>
>
> http://web.mit.edu/kerberos/www/krb5-1.4/krb5-1.4.1/doc/krb5-install/Upgr
> ading-to-Triple-DES-and-RC4-Encryption-Keys.html#Upgrading%20to%20Triple-
> DES%20and%20RC4%20Encryption%20Keys
>
> (the upgrading encryption types page)... regarding this sentence "Because
> of the way the MIT Kerberos database is structured, the KDC will assume
> that a service supports only those encryption types for which keys are
> found in the database."
>
> That makes me think that even if kdc.conf has:
>
> 	default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
>
> and krb5.conf has:
>
> 	default_tkt_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
> 	default_tgs_enctypes = arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc
>
> Any principals created before the switchover will obviously be stored in
> the old encryption type - but during authentication, what encryption type
> will be used between the client and the KDC?
>
> I'm a bit confused as to what all will use the new encryption types and
> what will use the old encryption types.


When responding to an initial ticket request, the KDC chooses three keys:

(1) The key in which the KDC's reply to the client will be encrypted.
    This key will be of one of the enctypes the KDC supports.
    This key will be of one of the enctypes the client says it supports.
    And, this key will be one of the client's long-term keys from the
    KDB, which means it will naturally be of one of the enctypes for
    which the KDB contains a key for this client.

(2) The key in which the private parts of the new ticket will be encrypted.
    This key will be one of the enctypes the KDC supports.
    This key will be one of the service's long-term keys from the KDB,
    which means it will naturally be one of the enctypes for which the KDB
    contains a key for the requested service (usually krbtgt/REALM at REALM).
    The client has no ability to affect the enctype of this key (except
    that some versions of some KDC implementations contain a bug in which
    the KDC considers only keys supported by the client).

(3) The session key contained in the new ticket.
    This key will be one of the enctypes the KDC supports.
    This key will be one of the enctypes the client says it supports;
    however, it need not be one for which the client has a long-term key.
    This key will be one of the enctypes known by the KDC to be supported
    by the server.  There is nothing in the Kerberos protocol which
    requires that this be the enctype of one of the service's long-term
    keys; however, the MIT implementation uses that list to decide what
    enctypes it thinks the server supports.


When responding to an additional ticket request, the KDC chooses keys for 
the same three roles.  However, the key used in role (1) is normally the 
session key from the client's TGT, and thus its enctype was chosen at the 
time the TGT was issued (alternately, it may be a sub-session key chosen by 
the client, which may be any enctype supported by both the client and KDC. 
Of course, the only enctypes the client knows are supported by the KDC are 
those used in its TGT).  The keys used in roles (2) and (3) are chosen in 
the same way as for initial tickets.


So, communicaton during an initial ticket exchange can be protected only by 
one of the client's long-term keys in the KDB.  That means that no matter 
what enctype settings are used on either client or KDC, you can't get it to 
use an enctype for which the user doesn't have a key.  To do that, the user 
will have to change his password so the admin server can generate a key for 
him for the new enctype.


Note that there are very few good reasons to configure clients for a 
specific set of enctypes.  In fact, under normal circumstances the only 
place you should have to configure enctypes is on the admin server, which 
needs to know which enctypes to generate keys for in the KDB.  As long as 
the KDB entry for each _service_ contains only keys of enctypes actually 
supported by that service, everything should work fine.

The one major exception is if you have a client workstation on which a 
single credential cache will be shared by multiple Kerberos implementations 
which do not all support the same set of enctypes.  In that case, you may 
want or need to restrict the set of enctypes used on that client to those 
which are supported by all implementations.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA