default_tkt_enctypes and default_tgs_enctypes linkage?
jhutz at cmu.edu
Thu Sep 8 19:49:35 EDT 2005
On Thursday, September 08, 2005 06:32:26 PM -0500 Will Fiveash
<William.Fiveash at sun.com> wrote:
> On Thu, Sep 08, 2005 at 03:40:21PM -0400, Sam Hartman wrote:
>> >>>>> "Will" == Will Fiveash <William.Fiveash at sun.com> writes:
>> Will> What I'm trying to point out here in my long winded way is
>> Will> that I don't understand the linkage between
>> Will> default_tkt_enctypes and default_tgs_enctypes.
>> I think it's more like you don't understand the fact that
>> default_tgs_enctypes is used to decide what enctypes are valid tgts to
>> use for tgs requests *and* what enctypes to request from the TGS.
> Is there ever a case in which someone can have >1 TGT for a particular
Yes. For example, you might have two different client implementations such
that each shares an enctype with the KDC, but there is no enctype supported
by all three (yes, Kerberos has a required-to-implement enctype, but people
can choose which supported enctypes to turn on).
> If not, why would the default_tgs_enctypes be used to decide
> which TGT to use if there is only one?
It is used to decide whether a given TGT is suitable; this has the effect
of selecting between TGT's if there is more than one.
>> Adding a third option seems like the clear wrong direction. The
>> configuration is too complex; it does not need to get more complex.
> I agree completely.
I also agree.
>> I think we'd like to move to a single option controlling all client
>> enctypes including: AS requests, selection of usable credentials from
>> the cache, TGS requests.
> Something like the equivalent of permitted_enctypes but on the client
Yes, I think that is the best option. It should be clear from the name of
this option that it affects the behavior of clients, not servers, and that
its effect is that the library behaves as though it did not support any
enctype not in the list. To this end, I'd propose a name like
> What would be a good name for this is requested_skey_enctypes to
> make it clear that this controls the session key enctypes that the
> client desires and will allow.
No, because that's not the only thing it controls.
It affects what enctypes the client claims to support, which affects
session key selection. But this also affects which of the client's
long-term keys will be used to protect an AS-REP. And, it controls the
client's behavior with respect to searching the credential cache for usable
tickets (TGT or otherwise).
It may also affect behavior in other cases where selection of enctypes is
required. For example, it might affect what enctypes a client claims to
support when negotiating the enctype of a sub-session key as described in
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
More information about the krbdev