GSS-krb5 and enctype lists, revisited

[Steven Michaud]

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.
>
> Cheers,
>
> Nico
> --
>
>