[20337] in Kerberos_V5_Development
Re: Use gss_krb5_import_cred() for initiator spnego creds
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun Dec 12 21:01:38 2021
To: Isaac Boukris <iboukris@gmail.com>,
"krbdev@mit.edu Dev List"
<krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <68c2348d-d588-d649-f6c3-9e786359058a@mit.edu>
Date: Sun, 12 Dec 2021 21:00:43 -0500
MIME-Version: 1.0
In-Reply-To: <CAC-fF8SA+tpNnh=nDcP=Og3AQRhJnY3nOwpXkPaB=9QxHgLaLw@mail.gmail.com>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 12/12/21 7:44 PM, Isaac Boukris wrote:
> When passing a unique memory cache to gss_krb5_import_cred() (aka not
> default), I fail to use these creds in gss_init_sec_context() with
> spnego mech but succeed with krb5. I wonder if that's a bug or if
> there is a way around it.
>
> I managed to reproduce in the test-suite, with this diff:
gss_krb5_import_cred() creates a krb5 cred. You can't use that with
SPNEGO per the standard API, nor is there a way to turn an existing cred
handle into a SPNEGO cred. Recent Heimdal does allow this as an
implicit extension (SPNEGO is flagged as a meta-mechanism which directly
uses union creds), but MIT krb5 does not.
A confounding factor is that the mechglue gss_init_sec_context() does
not error out on mismatched credentials. It just calls
gssint_get_mechanism_cred() on the union cred, and if that returns NULL
(it has no other way of failing) the mechglue just passes the default
cred handle to the mech. gss_accept_sec_context() used to behave the
same way, but I changed that in 2011 to make it fail out instead.
The current best way around this is to use gss_acquire_cred_from().
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
