1.6.1 breaks ability for applications to specify enctypes

[Sam Hartman]

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

    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?

Yes.

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

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.

--Sam