1.6.1 breaks ability for applications to specify enctypes
raeburn at MIT.EDU
Sun Apr 29 16:39:22 EDT 2007
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
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
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
(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.
More information about the krbdev