kaduk at mit.edu
Sat Mar 30 04:53:25 EDT 2019
On Tue, Mar 26, 2019 at 07:41:20PM -0400, Greg Hudson wrote:
> On 3/26/19 6:19 PM, Isaac Boukris wrote:
> > I see the point in setting name attributes in gss_impersonate(), and
> > saving the application the need for an extra init/accept, but if we
> > relax forwardable requirements then I would prefer to defer this,
> > along with PAC decoding to later, as a separate task.
> Not a problem.
> > I thought that GSS_C_ACCEPT would be needed to access default keytab,
> > same as we require GSS_C_INITIATE in gss_accept() in order to access
> > the ccache when we need to create proxy credentials. But I'm not clear
> > on these concepts.
> In a technical sense, nothing stops us from calling krb5_kt_default() on
> our krb5_context and trying it.
> But the more I think about doing this the more I don't like it. If an
> application needs behavior which is dependent on decrypting the ticket,
> it should identify the keytab to the GSS layer or do its own init/accept.
I'm inclined to agree -- as you say in your other message, this rather
violates the principle of least surprise, too.
More information about the krbdev