Use keytab to select etypes in krb5_get_init_creds_keytab()

[Nico Williams]

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
> unpredictable.

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.
See below.

> 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
default_tkt_enctypes".

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.

Nico
--