Use keytab to select etypes in krb5_get_init_creds_keytab()
nico at cryptonector.com
Tue Apr 17 14:39:09 EDT 2012
On Sun, Apr 15, 2012 at 6:17 PM, Greg Hudson <ghudson at mit.edu> wrote:
> On 04/10/2012 03:51 PM, Stef Walter wrote:
>> The attached patch fixes the issue. If the
>> krb5_get_init_creds_opt_set_etype_list() has not been called on the
>> option context passed to krb5_get_init_creds_keytab() then the keytab is
>> enumerated for the enctypes that are available for the given principal.
>> The patch sorts the enctypes so 'weak' ones come last.
> I do want this feature, but I have a few concerns about the patch:
> 1. This doesn't work with krb5_init_creds_set_keytab().
> 2. qsort() isn't a stable sort, so the resulting order of enctypes is
Well, if you're only sorting an array of scalar values (here:
enctypes) instead of, say, tuples where not all elements form a key,
then the fact that qsort() is unstable is irrelevant. It's the fact
that Stef's compare_etypes() is aliases enctypes by weak/not-weak,
coupled with qsort() that will make the sort unstable.
But more importantly, I think I'd like request enctypes to be sorted
according to a configured preference, not some hardcoded preference.
> 3. This patch could introduce enctypes not present in default_tkt_enctypes.
Would that be a problem? I'm inclined to think that it would be. But
I'm not sure. After all, it's only a "default". Perhaps the right
answer is "that's OK, but don't allow any non-permitted_enctypes",
perhaps adding "and also take the request enctype order from
Is it time to have an enctype_preference parameter listing enctypes in
order of preference?
> 4. This patch could result in requesting weak enctypes when
> allow_weak_enctypes is false.
See previous comment regarding permitted_enctypes.
More information about the krbdev