[20461] in Kerberos_V5_Development
Re: KDC TGT enctype selection question
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Dec 4 16:45:57 2023
Date: Mon, 4 Dec 2023 15:44:57 -0600
From: Nico Williams <nico@cryptonector.com>
To: Ken Hornstein <kenneth.hornstein.ctr@nrl.navy.mil>
Cc: krbdev@mit.edu
Message-ID: <ZW5IWVm0hPFj6gKV@ubby21>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <202312042123.3B4LN7SQ004821@hedwig.cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
