default_tkt_enctypes and default_tgs_enctypes linkage?

[Jeffrey Hutzelman]

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
> TGS/KDC?

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

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 
'enabled_client_enctypes'.

> 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 
draft-zhu-kerb-enctype-nego-03.txt.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA