GSS-krb5 and enctype lists, revisited

[Sam Hartman]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Fri, Apr 18, 2003 at 05:54:54AM -0400, Ken Raeburn
    Nicolas> wrote:
    >> (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.

    Nicolas> I like Sam's suggestion.  Basically, the application
    Nicolas> shouldn't care one iota about the enctypes of x-realm
    Nicolas> TGTs needed to get the actual, requested service ticket.
    Nicolas> So the application's requested enctypes should only apply
    Nicolas> to the final TGS exchange, and a configurable list of
    Nicolas> enctypes should apply to all intermediate TGS exchanges.

Thanks for explaining this.  I was having great difficulty last night
explaining why I thought this was the correct solution.

    Nicolas> This means no APIs need changing.  At most you introduce
    Nicolas> a new configuration parameter, but I don't think even
    Nicolas> that is necessary.

I think the configuration parameter you use in permitted_enctypes.

Here are the concerns I still have about this solution.  

1) I don't know how easy it is to implement in a non-hackish way.

2) We need to convince ourselves  that it works correctly for x-realm tgts

3) I need to convince myself that there is still a way to get an
   explicit enctype tgt for using old libraries etc.

4) We need to look at backward compatibility impacts and make sure
   this change does not create problems for ccaches used by old and
   new software and  does not create interoperability problems with
   other implementations.  Part of this is an extension of point 3
   above.


5)  We need to make sure we do not violate  user expectations in
    confusing ways.  

Feedback on point five would be greatly appreciated.  I think the
first four points are probably things that Tom, Ken and I will need to
convince ourselves of even if we get external feedback.  So problems
we should be aware of or reasons why it won't work are appreciated,
but explanations of why points 1-4 are OK are not that useful because
we'll just have to duplicate the work to become comfortable with the
proposal.

I do agree with Ken that a temporary API is probably the right
solution if we cannot convince ourselves of the long-term correctness
of something.

--Sam