default_tkt_enctypes and default_tgs_enctypes linkage?
William.Fiveash at sun.com
Thu Sep 8 19:32:26 EDT 2005
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
TGS/KDC? If not, why would the default_tgs_enctypes be used to decide
which TGT to use if there is only one?
> fortunately none of us really understand that either; it seems kind of
> The options for fixing it include:
> * Introduce a third option
> * have permitted_enctypes influence client behavior
> * Combine default_tkt_enctypes and default_tgs_enctypes together
> somehow and retain only one option. Do something to support old
> config files.
> 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. Every time I do some permutation testing in regards
to enctypes I find something weird.
> Using permitted_enctypes seems wrong because that's designed to
> control server behavior.
> 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
side. 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.
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
More information about the krbdev