GSS-krb5 and enctype lists, revisited
Nicolas.Williams at sun.com
Fri Apr 18 11:31:44 EDT 2003
On Fri, Apr 18, 2003 at 05:54:54AM -0400, Ken Raeburn wrote:
> 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.
I like Sam's suggestion. Basically, the application shouldn't care one
iota about the enctypes of x-realm TGTs needed to get the actual,
requested service ticket. So the application's requested enctypes
should only apply to the final TGS exchange, and a configurable list of
enctypes should apply to all intermediate TGS exchanges.
This means no APIs need changing. At most you introduce a new
configuration parameter, but I don't think even that is necessary.
> Whatever approach we use, it ought to cope with a lot of cases,
> - getting a cross-realm TGT, for which AES might be the only allowed
(3) does this.
> - not causing other cross-realm exchanges to be protected only by a
> DES TGT just because AES and DES were the only options for the TGT
> session key and the GSS application got used first to the remote
(3) seems does this too.
> - not using a locally stored ticket for the service that has a
> session key of an enctype not supported by GSS
(3) does this too.
> Any other suggestions?
I don't see a better way than (3).
> For the moment, I think I like (1a) best as a short-term solution.
> For the long term, I think the more general case of (1) should be
> handled; I'm just not sure how, right now.
Again, I don't think the application should care about intermediate TGS
exchanges and the enctypes of the corresponding x-realm TGTs.
Cross-realm traversal should be done entirely under the hood.
More information about the krbdev