On Friday, July 01, 2005 02:14:02 AM -0700 Phil Dibowitz <[EMAIL PROTECTED]>
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/[EMAIL PROTECTED]).
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) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
