1.6.1 breaks ability for applications to specify enctypes

[Ken Raeburn]

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.

should be examined further, even if it's not the root cause of this  
particular problem.

The etype list included in the TGS request indicates the types of  
session key that are desired, whether because of application protocol  
restrictions or configuration policies or some other reason.  In the  
referral case, we get back a TGT to be used to acquire the service  
ticket, and the application protocol restrictions don't apply, so we  
don't need or want to impose the same etype list limitation.  And, in  
fact, the cross-realm TGT principal may have a restricted set of key  
types that has an empty intersection with the application protocol  
etype list.

Is this a fair summary of the conflict as you see it?

A similar issue could come up with the AS exchange in certain  
configurations.  Consider a site where user accounts have AES keys  
only, you want to talk to a service that requires a DES session key,  
and you only want to talk to that one service so you don't need a  
TGT.  If you send an etype list that includes only DES key types,  
that list also gets applied to the selection of which key is used  
from the database entry for the user, which has only AES, so no  
matching key is found.  But in this situation, the exchange should be  
able to use the user's AES key and establish a DES session key.

One approach might be, when referrals are permitted, to build an  
etype list with the etypes acceptable under the application protocol  
restrictions at the front, and the other enctypes that we can accept  
in TGTs at the end.  That will allow a TGT to be returned with an  
etype not supported by the application protocol, if the KDC treats  
this as a prioritized list.  It has a couple of obvious drawbacks:

(1) If the cross-realm TGT keys support both some weaker etypes  
needed by the application protocol and some stronger etypes, the  
weaker type would be used.  If the TGT is only used to get the  
service ticket and then discarded, that would probably be acceptable;  
less desirable if we actually cache it and use it for getting other  
tickets (even for the same service principal under a different  
application protocol).

(2) We could get back a service ticket of a type not supported by the  
application protocol.  This should only happen if the service  
principal's entry in the database indicates that the desired etypes  
aren't actually supported by the service (which, given the  
application protocol restrictions, means that application protocol  
isn't supported, and the client is apparently trying to get tickets  
before figuring out if the server will support it).  So the library  
code should check the etype returned and generate the appropriate  
error if needed.

However, I should note that I don't think RFC 4120 explicitly says  
the TGS treats the etype list as a prioritized list.  It is explicit  
about the AS case.

So, if the above won't work in the TGS case, if we get an error back  
because the etype lists don't intersect, we could submit another  
request for the service ticket without the (more) restricted etype  
list, and use the final cross-realm TGT to re-request a service  
ticket with the restricted etype list.

Ken