[20468] in Kerberos_V5_Development
Re: KDC TGT enctype selection question
daemon@ATHENA.MIT.EDU (Ken Hornstein via krbdev)
Mon Dec 4 20:30:37 2023
Message-ID: <202312042123.3B4LN7SQ004821@hedwig.cmf.nrl.navy.mil>
To: Nico Williams <nico@cryptonector.com>
cc: krbdev@mit.edu
In-Reply-To: <ZW5AXkYqYlUPDX2e@ubby21>
MIME-Version: 1.0
Date: Mon, 04 Dec 2023 16:23:08 -0500
From: Ken Hornstein via krbdev <krbdev@mit.edu>
Reply-To: Ken Hornstein <kenneth.hornstein.ctr@nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>The general convention is that a principal's long term keys are ordered
>from strongest to weakest, thus picking the first key that is approved
>by local policy (permitted_enctypes) is generally what you want. This
>is just a convention.
>
>I suspect that for root TGS principals (krbtgt/REALM@REALM where the two
>REALMs are the same) the convention MIT wants is that the first key _is_
>the key to use always, and woe unto you then if that key's enctype is
>not in the permitted_enctypes.
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!
>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.
--Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
