default_tkt_enctypes and default_tgs_enctypes linkage?

[Will Fiveash]

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
> broken.
> 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.

-- 
Will Fiveash
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)