[18930] in Kerberos_V5_Development
Re: [PATCH] Fix SPNEGO interoperability with servers implementing
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Aug 4 15:01:27 2014
Date: Mon, 4 Aug 2014 14:01:16 -0500
From: Nico Williams <nico@cryptonector.com>
To: David Woodhouse <dwmw2@infradead.org>
Message-ID: <20140804190115.GV3579@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1406284950.9484.9.camel@infradead.org>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Fri, Jul 25, 2014 at 11:42:30AM +0100, David Woodhouse wrote:
> So the vulnerability is that a hypothetical attacker can trick us into
> selecting a mechanism that both client and server were prepared to use
> anyway, and which the server *would* have accepted if we'd happened to
> try it first.
Yes.
> In practice, the viable fallback mechanism is almost always going to be
> NTLMSSP. And in the case of HTTP and many other protocols, our
> hypothetical attacker would have a much easier way of making the client
> use NTLM — just mangle the 'WWW-Authenticate: Negotiate' in the 401
> response so that my client only sees the 'WWW-Authenticate: NTLM', and
> no need to screw around with SPNEGO packets at all.
Today, yes. It's not clear that this will always be so.
> (Note: If I could just disable IAKERB, or install the GSS-NTLMSSP plugin
> with a sufficiently high priority that it's the first thing we offer to
> this server, that would also suffice for me to avoid this problem. As
> long as I offer GSS-NTLMSSP first and not IAKERB (which never works in
> my environment and only serves to exacerbate other issues such as this
> one), I'd be OK.)
You should be able to gss_set_neg_mechs() to disable offering mechanisms
you can't / don't want to use.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
