[19911] in Kerberos_V5_Development
Re: Implementing RBCD
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Sat Mar 30 04:53:40 2019
Date: Sat, 30 Mar 2019 03:53:25 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20190330085324.GM35679@kduck.mit.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <506a45dc-7f9c-365e-f3c5-4e96568dd67d@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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.
-Ben
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
