GSS-krb5 and enctype lists, revisited
Nicolas.Williams at sun.com
Fri Apr 18 17:23:05 EDT 2003
On Fri, Apr 18, 2003 at 04:28:55PM -0400, Sam Hartman wrote:
> 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.
Oh, I see the hack. Yes, the krb5_gss_init_sec_context() overrides the
context-wide tgs enctypes and there's no way to pass the requested
enctypes to krb5_get_credentials().
Well, there's a not-too-hackish way 'round this: add a new config
parameter which defaults to the same value as permitted_enctypes and
which is meant to constrain the requested enctypes of non-TGT service
tickets, then make krb5_gss_init_sec_context() (get_credentials()) set
this new config parameter instead of default_tgs_enctypes.
The krb5_get_cred*() APIs need more arguments though to be really clean,
and I've long hated the notion of passing some options via a "template"
krb5_creds... (I don't mind passing arguments via a structure meant for
the task, I just mind overloading krb5_creds.)
> 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
Ah, well, there's a price to pay for mixing old and new versions of the
same library on the same host - so don't do it (yes, legacy, ...
> 5) We need to make sure we do not violate user expectations in
> confusing ways.
Er, the current code violates user expectations; this is the fix.
> 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
Sorry, I had to comment on (1) and (2).
More information about the krbdev