[840] in Kerberos_V5_Development
get_in_tkt API changes...
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Jan 30 22:22:37 1995
Date: Mon, 30 Jan 1995 22:22:21 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: krbdev@MIT.EDU
More proposed API changes.
1) Remove the etype and keytype argument from all of the get_in_tkt
family. It's generally a bad idea to make the Application have to
hardcode the encryption and keytype in the argument. Also, this
functionality has been subsumed by the new API function
krb5_set_desired_etypes().
2) Note that the proposed new function krb5_set_desired_etypes() only
applies to the get_in_tkt family. It controls the ordered list of
encryption types which the get_in_tkt family of routines will send to
the KDC, whereupon the KDC will pick the the first encryption type which
both it and the target application server supports.
The name of this function is a bit misleading; hence, I propose that we
change it to be krb5_set_default_in_tkt_etypes().
There will also be a matching krb5_get_default_in_tkt_etypes() to obtain
the current default list of encryption types that the Kerberos library
will attempt to use when contacting the KDC.
3) There should be a new routine, get_in_tkt_with_keytab(), which has
the same signature as get_in_tkt_with_skey(), except tha tinstead of
passing in a krb5_keyblock *key, a krb5_keytab *keytab is passed in
instead. I actually expect that in most cases get_in_tkt_with_keytab
will be appropriate more often than get_in_tkt_with_skey().
- Ted
