1.3 Overview

  • Article

The .NET NegotiateStream Protocol was introduced to address the need for a simple and lightweight authentication and security mechanism between a client and a server when the client or server needs direct access to the TCP stream. A key benefit is that authentication is accomplished without the use of digital certificates, as is required by the Transport Layer Security (TLS) protocol [RFC5246]. The .NET NegotiateStream Protocol provides a means for framing GSS-API Negotiation (as specified in [RFC4178]) over a TCP stream. This is used to negotiate the security context for communication between a client and a server. The client and server can then exchange data protected by the negotiated security context.

The .NET NegotiateStream Protocol uses the SPNEGO mechanism to determine which underlying security protocol to use. The .NET NegotiateStream Protocol can also forego negotiation with SPNEGO and use NTLM authentication directly.

This protocol enables:

  • Client and/or server authentication

  • Data confidentiality and integrity

The .NET NegotiateStream Protocol performs these functions in two phases: a security context negotiation phase and a data transfer phase.

The security context negotiation allows for the selection of mechanisms to protect the authenticity and confidentiality of data that will be subsequently exchanged. SPNEGO is used to select the underlying security protocol, and the security context is negotiated between the client and server in a set of opaque security tokens generated by the SPNEGO GSS-API mechanism, which are transferred between client and server over a TCP connection by use of a message framing protocol defined in this document. This context negotiation is initiated by the client, and several messages can be exchanged before the security context negotiation is complete. When the negotiation is completed, the client and server have agreed upon the necessary authentication, data integrity, and confidentiality mechanisms. These mechanisms will be used to secure subsequent data exchanges between the client and the server.

After the security context has been successfully negotiated, the client and server exchange data that is protected using the agreed-upon authentication, integrity, and confidentiality mechanisms. The server can initiate a data transfer to the client, or the client can initiate a data transfer to the server. A data transfer can happen at any time after the security context negotiation is complete.

An error in the negotiation process or the data transfer process invalidates the stream, and a new security context has to be renegotiated. The reason for the failure to negotiate a security context is communicated to the other application taking part in the negotiation. An error in the data transfer process can include transfer of data with an authentication, integrity, or confidentiality mechanism different from what was negotiated.