GSS-krb5 and enctype lists, revisited
hartmans at MIT.EDU
Fri Apr 18 16:28:55 EDT 2003
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> On Fri, Apr 18, 2003 at 05:54:54AM -0400, Ken Raeburn
>> 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
5) We need to make sure we do not violate user expectations in
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
I do agree with Ken that a temporary API is probably the right
solution if we cannot convince ourselves of the long-term correctness
More information about the krbdev