[19910] in Kerberos_V5_Development
Re: Implementing RBCD
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Mar 26 19:41:42 2019
To: Isaac Boukris <iboukris@gmail.com>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <506a45dc-7f9c-365e-f3c5-4e96568dd67d@mit.edu>
Date: Tue, 26 Mar 2019 19:41:20 -0400
MIME-Version: 1.0
In-Reply-To: <CAC-fF8RVOpfMpBPQoo3P41jqFSYsRoj19A-zmhokdsOh6StevA@mail.gmail.com>
Content-Language: en-US
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
