What are the security differences between "NegotiateStream" and "WebRequest" using SPNego/Kerberos?

Question

The following link describes a traditional intranet client-server socket communication using Kerberos

public class NegotiateStream : System.Net.Security.AuthenticatedStream
... 
// Request authentication.
NetworkStream clientStream = client.GetStream();
NegotiateStream authStream = new NegotiateStream(clientStream, false); 
...
// Pass the NegotiateStream as the AsyncState object 
// so that it is available to the callback delegate.
IAsyncResult ar = authStream.BeginAuthenticateAsClient(
                  new AsyncCallback(EndAuthenticateCallback), authStream);
... 

On the other hand, IIS has the ability to authenticate using what I understand to be "Kerberos with SPNego over SSL"... (please correct my terminology!).

When in this SPNego/SSL/Kerberos mode, I wasn't able to get NegotiateStream to work, however I was able to get the machineaccount$ to work correctly with WebRequest.AuthenticationLevel set to MutualAuthRequired

Question

• What is the security difference between using the NegotiateStream, versus WebRequest.AuthenticationLevel?

• What are the standards (such as MS-SPNG) being used in each solution?

• What are the Windows subsystems (SIP, GSS-API, etc) that are in use?

Any information that can help me integrate Linux agents into this Kerberos/SpNego solution would be ideal.

Answer 1

This is all about the differences in transport types. Here you have two different transports:

• Binary stream of arbitrary data
• HTTP stream of HTTP-encoded data

An HTTP request and response have very specific semantics about how you authenticate a request, and that is via the Authorization: [scheme] [token] header and initiated by a response header WWW-Authenticate: [Scheme], where [scheme] is often Negotiate.

A binary stream is arbitrary and left to the implementor to do whatever they want.

The Negotiate scheme is a GSS compatible package which is a simple protocol that lets the client and server negotiate an internal authentication protocol like Kerberos or NTLM. In Windows land this is called an SSPI package.

A package, either GSS or SSPI, is made up of a set of functions that start or accept handshakes between parties, and then potentially encrypt/decrypt data between the two parties (it's optionally supported). These functions generate messages that can go across any transport and any form of transport can call these functions.

In the WebRequest case the class is smart enough to detect the Negotiate header and calls into the Windows SSPI functions to get a ticket, passing the package name. This relies primarily on Kerberos for protection of the ticket itself, but it doesn't protect anything else in the HTTP request so SSL/TLS is used.

In the NegotiateStream case the wire format is somewhat arbitrary, but bounded by the Negotiate handshake. The client will send just the negotiate init message across the wire, the server will respond, and if they agree you can start sending encrypted messages to each other.