[16379] in Kerberos-V5-bugs
[krbdev.mit.edu #8844] SPNEGO should filter mechs on acceptor with
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Tue Oct 29 14:42:03 2019
From: "Greg Hudson via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To:
Message-ID: <rt-4.4.4-18712-1572374476-580.8844-4-0@mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #8844":;
Date: Tue, 29 Oct 2019 14:41:16 -0400
MIME-Version: 1.0
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Tue Oct 29 14:41:16 2019: Request 8844 was acted upon.
Transaction: Ticket created by ghudson@mit.edu
Queue: krb5
Subject: SPNEGO should filter mechs on acceptor with gss_acquire_cred()
Owner: Nobody
Requestors: ghudson@mit.edu
Status: open
Ticket <URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8844 >
In SPNEGO, the initiator proposes a list of mechanisms and the acceptor picks
one. In the code, the list of negotiable mechanisms on each side is taken from
the credential if one is provided; otherwise gss_indicate_mechs() is used (with
SPNEGO removed, and after tickets 8021 and 8217 some mechs are filtered out by
attribute). In the latter case, the initiator but not the acceptor filters the
mechs using gss_acquire_cred(). This distinction in behavior dates back to the
original import of the Solaris SPNEGO code.
I believe the acceptor should also filter mechs using gss_acquire_cred(), to
reduce the likelihood that it will choose a mechanism it cannot accept. This
will also provide greater consistency between using the default
verifier_cred_handle and using an explicitly acquired verifier_cred_handle
obtained with the default name and mech list.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
