Challenging clients, why another ping-pong?

[Greg Hudson]

On 02/06/2014 08:42 AM, Rick van Rein wrote:
> In my RFC 4599 it says "The initial WWW-Authenticate header will not carry any gssapi-data.” and I was wondering if I missed some cryptographic reason to delay the challenge until later.

Some terminology clarification is in order:

* SPNEGO (RFC 4178, previously RFC 2478) was created in the 1990s as a
GSSAPI meta-mechanism, with no specific considerations to HTTP.  It is
used with a variety of GSS-enabled network protocols, though not all of
them.

* HTTP negotiate auth (RFC 4559 and [MS-N2HT]) was created in the 2000s
to allow the use of NTLM and Kerberos (primarily) to authenticate HTTP
requests.  Most of the statements you have made about SPNEGO are
actually about HTTP negotiate auth, which uses SPNEGO but is not the
same thing as SPNEGO.

There is no challenge in the HTTP negotiate auth 401 error because (1)
SPNEGO does not contain any provision to convey a challenge to the
initiator side of the GSS mechanism, (2) web servers are supposed to be
mostly stateless, although of course that's not an absolute, and (3) the
client does not necessarily wait for the server's 401 error to
authenticate; it may have cached the need to authenticate to a
particular URL.

HTTP negotiate is generally considered to be on the weak end of
acceptable.  It provides no data stream protection at all, relying
completely on TLS to protect the channel.  An attacker who can break the
TLS channel can eavesdrop on or modify the HTTP headers and data, or can
replay an authenticator in another request of its own if the server does
not detect that (and most HTTP negotiate servers do not use a replay cache).

The simplest way to improve this situation is with channel bindings, but
even that is not simple for reasons Nico could elaborate on.