GSS-krb5 and enctype lists, revisited

[Nicolas Williams]

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.

Yes.

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

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, ...
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
> proposal.

Sorry, I had to comment on (1) and (2).

Cheers,

Nico
--