[835] in Kerberos_V5_Development
Planned changes for multiple encryption support....
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Wed Jan 25 00:24:13 1995
Date: Wed, 25 Jan 1995 00:24:06 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: krbdev@MIT.EDU
There have been some requests that I write up a list of the planned API
changes, so that people could comment. Well, here are at least some of
the changes that need to be made....
To better support multiple encryption algoriths,
krb5_kt_read_service_key currently these arguments:
krb5_kt_read_service_key(krb5_context context,
krb5_pointer keyprocarg,
krb5_principal principal,
krb5_vno vno,
krb5_keyblock **key)
it should be changed to be:
krb5_kt_read_service_key(krb5_context context,
krb5_pointer keyprocarg,
krb5_principal principal,
krb5_vno vno,
krb5_keytype keytype, <---- NEW
krb5_keyblock **key)
Similarily....
krb5_kt_get_entry(krb5_context context,
krb5_keytab id,
krb5_principal principal,
krb5_kvno vno,
krb5_keytab_entry)
needs to be changed to:
krb5_kt_get_entry(krb5_context context,
krb5_keytab id,
krb5_principal principal,
krb5_kvno vno,
krb5_keytype keytype, <----- NEW
krb5_keytab_entry)
-----------------------------------------------------------------
krb5_send_tgs only allows you to set a single desired encryption type,
instead of a list, which is what is allowed by the protocol (and which
is necessary to provide compatibility for the DES-CRC vs. DES-MD5
change).
Thus, we should change:
krb5_send_tgs(...
const krb5_enctype etype,
...)
to
krb5_send_tgs(...
const krb5_enctype *etypes,
...)
-----------------------------------------------------------------
There is also the problem that get_in_tkt, et. al, don't have a way to
pass a parameter indicating which types of encryption should be used.
However, instead of changing a *large* number of functions, I propose
that what we do instead is to save this information in the library state
(or rather, in the library session context), by introducing the
following API call:
krb5_set_desired_etypes(krb5_context context,
const krb5_enctype *etypes);
The default list of desired etypes will be compiled in, and consist of:
DES-MD5, DES-CRC (in that order).
Eventually, when we revamp the configuration files, the default
encryption list will be stored in the configuration file.
-----------------------------------------------------------------
Another problem: when you are doing both preauthentication and
non-standard salts, at the time when you need to encrypt the
preauthentication info (during get_in_tkt, for example) you don't know
what salt to use. You can guess, but if you guess wrong, there's no way
to guess again. The reason for this is because the callback to
get_in_tkt is:
krb5_error_code (*key_proc)(const krb5_keytype type,
krb5_keyblock **key,
krb5_const_pointer keyseed,
krb5_pa_data **padata)
The problem is that in some cases, key_proc actually prompts the user
for the password; so, if get_in_tkt calls key_proc more than once, the
user may be prompted for his/her password more than once. Not good.
The *clean* fix would be to redo the key_proc function signature as:
krb5_error_code (*key_proc)(/* IN */
const krb5_keytype type,
krb5_const_pointer keyseed,
krb5_data *salt,
/* OUT */
char **password,
krb5_keyblock **key)
Where the key_proc could *optionally* fill in password with the text
password, if the key procedure had the text password available. If it's
available, the get_in_tkt can try the default salt, and if the KDC
returns an KRB_ERR packet with the correct salt to use, then get_in_tkt
can use the new salt and try again to preauthenticate.
The not so clean fix requires no API changes, but defines a new keytype,
KEYTYPE_PASSWORD. The user-supplied key_proc would be allowed to
optionally fill in the password into the krb5_keyblock structure, with
the keytype set to KEYTYPE_PASSWORD. In that case, the get_in_tkt would
be responsible for calling string_to_key with the appropriate salt(s).
I'm currently leaning towards the not-so-clean fix simply because it's
less work. However, I could easily be pursuaded that we really should
do things right, and change the callback used by get_in_tkt. Comments?
- Ted
