GSS-krb5 and enctype lists, revisited
smichaud at pobox.com
Fri Apr 18 13:16:32 EDT 2003
I agree :-)
I suppose I should have said that a temporary problem should require
_nothing more than_ a temporary solution.
The reason I brought the matter up in the first place is that I was
suprised (and a little shocked) to discover that adding AES to the GSS
krb5 mech requires a change in an RFC.
On Fri, 18 Apr 2003, Nicolas Williams wrote:
> On Fri, Apr 18, 2003 at 11:44:10AM -0500, Steven Michaud wrote:
> > So, before _too_ long, the problem that Ken Raeburn's talking about
> > should disappear. This seems to strengthen the argument for an
> > interim solution -- one that doesn't permanently (publicly) change the
> > MIT Kerberos API.
> Except that the application (libgssapi_krb5 in this case) still has no
> business knowing, specifying or caring what enctypes are used for
> whatever TGTs are needed in the process of getting the desired service
> ticket - the application should only be able to constrain the enctypes
> for the service ticket.
> This means a fix can be made which modifies no APIs and introduces no
> internal APIs.
> What's wrong with Sam's suggestion then? Nothing that I can see.
More information about the krbdev