1.6.1 breaks ability for applications to specify enctypes
hartmans at MIT.EDU
Mon Apr 30 12:22:43 EDT 2007
>>>>> "Ken" == Ken Raeburn <raeburn at MIT.EDU> writes:
Ken> The conflict you described:
>> I suspect the referrals code interacts badly with
>> use_conf_ktypes or something like that.
>> I actually don't see how referrals could work well with
>> use_conf_ktypes because I think they have conflicting
Ken> should be examined further, even if it's not the root cause
Ken> of this particular problem.
Ken> The etype list included in the TGS request indicates the
Ken> types of session key that are desired, whether because of
Ken> application protocol restrictions or configuration policies
Ken> or some other reason. In the referral case, we get back a
Ken> TGT to be used to acquire the service ticket, and the
Ken> application protocol restrictions don't apply, so we don't
Ken> need or want to impose the same etype list limitation. And,
Ken> in fact, the cross-realm TGT principal may have a restricted
Ken> set of key types that has an empty intersection with the
Ken> application protocol etype list.
Ken> Is this a fair summary of the conflict as you see it?
I agree with your comments below.
I'll add the following observations.
I think there are KDCs (MS) which do not treat the etype list as
Today we're willing to cache any ticket from our home KDC.
We should be careful of doing that in restricted etype situations if it is not the final ticket.
I'm not sure we should not cache; I just want to think carefully about it.
More information about the krbdev