KDC TGT enctype selection question

[Nico Williams]

On Mon, Dec 04, 2023 at 04:23:08PM -0500, Ken Hornstein wrote:
> I understand the convention, but it doesn't really answer my question:
> this is a very explicit coding choice and I can't really see WHY it
> exists.  For one it could make it difficult to upgrade enctypes when
> you had geographically-distributed KDCs that were managed by different
> organizations.  Also, it doesn't really match the expected behavior
> in terms of other Kerberos enctype negotations and I am trying to
> understand why.  I am perfectly willing to believe there is something
> I don't understand!

It's a very simple convention.  I would strongly advise running the same
configuration on all the KDCs of any given realm.

> >I'm not sure how B ends up accepting the TGTs that it vends though, in
> >this case, given that it shouldn't be accepting the second key to
> >decrypt the TGT's enc-part.
> 
> It ends it calling krb5_dbe_def_search_enctype() which has this
> code:
> 
>         /* Filter out non-permitted enctypes. */
>         if (!krb5_is_permitted_enctype(context, kd->key_data_type[0])) {
>             saw_non_permitted = TRUE;
>             continue;
>         }
> 
> So on KDC B the sha384 key is skipped and the sha1 key is returned.

That makes the code in `kdc_rd_ap_req()` that you quoted earlier a bit
silly.

Nico
--