GSS-krb5 and enctype lists, revisited

[Ken Raeburn]

The current plan for MIT's 1.3 release is to include AES support in
the krb5 library, and have it turned on by default, but no support in
the GSS Kerberos mechanism.  It's looking like this combination could
be a problem.

Sam and I discussed it a little tonight, without reaching any
conclusion.  Here's a recap:

Currently the GSS krb5 code sets the tgs_enctypes list to those
encryption types supported by the GSS krb5 mechanism specification,
with MIT and Microsoft enhancements for des3 and rc4 respectively.
(Actually, I think it's the intersection of that list and the
permitted enctypes or the existing tgs_enctypes, I forget the
details.)  It then acquires a ticket for the indicated service, and
restores the old tgs_enctypes list.

As with normal ticket acquisition, if a suitable ticket isn't already
in the credentials cache, we get a ticket-granting ticket and contact
the KDC.  The problem is, the modified tgs_enctypes list is used for
getting that TGT.  We should be using the normal tgs_enctypes list.

So, if you get a TGT with an AES session key, and then the GSS code
tries to get a DES3 or DES ticket, it won't work, because it can't
find a DES3 or DES TGT in your ccache.

There are some possible solutions to this, none without issues:


(1)

We could add yet another call for getting tickets with one more
argument, a list of enctypes to be used only for the requested ticket
and not for any intermediate TGTs.  But we're trying to stabilize the
API, not continue to randomly throw more stuff into it every time we
need one more little tweak.

My gut feeling is that this is a special case of needing to specify
attributes for the desired ticket in some form other than a single
value, and it may apply to other attributes.  So a hack to deal with
one attribute may be a step in the wrong direction.

(1a)

As a variant on this approach, we could create such a call, make it a
private krb5int_ function that we'll make available only for this
release, and rip it out as soon as we've got a better solution.  This
would mean the GSS mechanism could not be built cleanly on top of the
"official, supported" API for the library.


(2)

In the DES3 GSS work, I first tried an approach of trying to get a
DES3 ticket, and if it failed, trying to get a DES ticket.  The
tgs_enctypes list was left alone, so any TGT could be used.  This was
removed because it would contact the KDC to ask for a DES3 ticket even
if a DES ticket was already available and DES3 tickets would not be
issued for the service.  (There was no caching of the negative
indication.  With the current ccache file format, there is no place to
put such information.)  This was too large an increase in traffic.

It's still not the right approach for the service ticket, but perhaps
it would be good enough for the TGT used to get the service ticket?


(3)

Sam's suggestion, if I understand correctly, was to have the
tgs_enctypes list affect the request to the KDC, but not the
restrictions on enctypes in locally available TGTs used to contact the
KDC.  Or perhaps any acquisition of a TGT would ignore the
tgs_enctypes list, and just use permitted_enctypes.

I'm concerned this won't behave properly when cross-realm TGTs need to
be acquired.  Or that it would get the right result, but by making the
current enctype specification in the config file even more confusing.


Whatever approach we use, it ought to cope with a lot of cases,
including:
 - getting a cross-realm TGT, for which AES might be the only allowed
   enctype
 - not causing other cross-realm exchanges to be protected only by a
   DES TGT just because AES and DES were the only options for the TGT
   session key and the GSS application got used first to the remote
   realm
 - not using a locally stored ticket for the service that has a
   session key of an enctype not supported by GSS

Any other suggestions?

For the moment, I think I like (1a) best as a short-term solution.
For the long term, I think the more general case of (1) should be
handled; I'm just not sure how, right now.

Ken