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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
