Introduction - Microsoft



[MS-NNS]: .NET NegotiateStream ProtocolIntellectual Property Rights Notice for Open Specifications DocumentationTechnical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions. Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting iplg@. License Programs. To see all of the protocols in scope under a specific license program and the associated patents, visit the Patent Map. Trademarks. The names of companies and products contained in this documentation might be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit trademarks. Fictitious Names. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events that are depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than as specifically described above, whether by implication, estoppel, or otherwise. Tools. The Open Specifications documentation does not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments, you are free to take advantage of them. Certain Open Specifications documents are intended for use in conjunction with publicly available standards specifications and network programming art and, as such, assume that the reader either is familiar with the aforementioned material or has immediate access to it.Support. For questions and support, please contact dochelp@. Revision SummaryDateRevision HistoryRevision ClassComments7/20/20070.1MajorMCPP Milestone 5 Initial Availability9/28/20070.1.1EditorialChanged language and formatting in the technical content.10/23/20070.1.2EditorialChanged language and formatting in the technical content.11/30/20070.1.3EditorialChanged language and formatting in the technical content.1/25/20081.0MajorUpdated and revised the technical content.3/14/20081.0.1EditorialChanged language and formatting in the technical content.6/20/20081.1MinorClarified the meaning of the technical content.7/25/20082.0MajorUpdated and revised the technical content.8/29/20082.0.1EditorialChanged language and formatting in the technical content.10/24/20083.0MajorUpdated and revised the technical content.12/5/20083.0.1EditorialChanged language and formatting in the technical content.1/16/20093.0.2EditorialChanged language and formatting in the technical content.2/27/20093.0.3EditorialChanged language and formatting in the technical content.4/10/20093.0.4EditorialChanged language and formatting in the technical content.5/22/20093.0.5EditorialChanged language and formatting in the technical content.7/2/20093.0.6EditorialChanged language and formatting in the technical content.8/14/20093.0.7EditorialChanged language and formatting in the technical content.9/25/20093.1MinorClarified the meaning of the technical content.11/6/20093.1.1EditorialChanged language and formatting in the technical content.12/18/20093.1.2EditorialChanged language and formatting in the technical content.1/29/20103.1.3EditorialChanged language and formatting in the technical content.3/12/20103.1.4EditorialChanged language and formatting in the technical content.4/23/20103.1.5EditorialChanged language and formatting in the technical content.6/4/20103.1.6EditorialChanged language and formatting in the technical content.7/16/20104.0MajorUpdated and revised the technical content.8/27/20104.0NoneNo changes to the meaning, language, or formatting of the technical content.10/8/20104.0NoneNo changes to the meaning, language, or formatting of the technical content.11/19/20104.0NoneNo changes to the meaning, language, or formatting of the technical content.1/7/20114.0NoneNo changes to the meaning, language, or formatting of the technical content.2/11/20114.0NoneNo changes to the meaning, language, or formatting of the technical content.3/25/20114.0NoneNo changes to the meaning, language, or formatting of the technical content.5/6/20114.0NoneNo changes to the meaning, language, or formatting of the technical content.6/17/20114.1MinorClarified the meaning of the technical content.9/23/20114.1NoneNo changes to the meaning, language, or formatting of the technical content.12/16/20115.0MajorUpdated and revised the technical content.3/30/20125.0NoneNo changes to the meaning, language, or formatting of the technical content.7/12/20125.1MinorClarified the meaning of the technical content.10/25/20125.1NoneNo changes to the meaning, language, or formatting of the technical content.1/31/20135.1NoneNo changes to the meaning, language, or formatting of the technical content.8/8/20135.1NoneNo changes to the meaning, language, or formatting of the technical content.11/14/20135.1NoneNo changes to the meaning, language, or formatting of the technical content.2/13/20145.1NoneNo changes to the meaning, language, or formatting of the technical content.5/15/20145.1NoneNo changes to the meaning, language, or formatting of the technical content.6/30/20156.0MajorSignificantly changed the technical content.10/16/20156.0NoneNo changes to the meaning, language, or formatting of the technical content.7/14/20166.0NoneNo changes to the meaning, language, or formatting of the technical content.3/16/20177.0MajorSignificantly changed the technical content.6/1/20177.0NoneNo changes to the meaning, language, or formatting of the technical content.12/1/20177.0NoneNo changes to the meaning, language, or formatting of the technical content.3/13/20198.0MajorSignificantly changed the technical content.Table of ContentsTOC \o "1-9" \h \z1Introduction PAGEREF _Toc2249289 \h 61.1Glossary PAGEREF _Toc2249290 \h 61.2References PAGEREF _Toc2249291 \h 61.2.1Normative References PAGEREF _Toc2249292 \h 61.2.2Informative References PAGEREF _Toc2249293 \h 71.3Overview PAGEREF _Toc2249294 \h 71.4Relationship to Other Protocols PAGEREF _Toc2249295 \h 81.5Prerequisites/Preconditions PAGEREF _Toc2249296 \h 81.6Applicability Statement PAGEREF _Toc2249297 \h 81.7Versioning and Capability Negotiation PAGEREF _Toc2249298 \h 81.8Vendor-Extensible Fields PAGEREF _Toc2249299 \h 91.9Standards Assignments PAGEREF _Toc2249300 \h 92Messages PAGEREF _Toc2249301 \h 102.1Transport PAGEREF _Toc2249302 \h 102.2Message Syntax PAGEREF _Toc2249303 \h 102.2.1Handshake Message PAGEREF _Toc2249304 \h 102.2.2Data Message PAGEREF _Toc2249305 \h 113Protocol Details PAGEREF _Toc2249306 \h 133.1Client Details PAGEREF _Toc2249307 \h 133.1.1Abstract Data Model PAGEREF _Toc2249308 \h 133.1.1.1Underlying TCP Connection PAGEREF _Toc2249309 \h 143.1.1.2Stream State PAGEREF _Toc2249310 \h 143.1.1.3Required Protection Level PAGEREF _Toc2249311 \h 143.1.1.4Negotiated Protection Level PAGEREF _Toc2249312 \h 143.1.1.5Allowed Impersonation Level PAGEREF _Toc2249313 \h 143.1.1.6Negotiated Impersonation Level PAGEREF _Toc2249314 \h 153.1.1.7Client Credentials PAGEREF _Toc2249315 \h 153.1.1.8Security Provider Context PAGEREF _Toc2249316 \h 153.1.1.9Framing Buffer PAGEREF _Toc2249317 \h 153.1.1.10Channel Binding Token PAGEREF _Toc2249318 \h 153.1.1.11Target Name PAGEREF _Toc2249319 \h 153.1.2Timers PAGEREF _Toc2249320 \h 153.1.3Initialization PAGEREF _Toc2249321 \h 153.1.4Higher-Layer Triggered Events PAGEREF _Toc2249322 \h 153.1.4.1Application Invocation of the .NET NegotiateStream Protocol PAGEREF _Toc2249323 \h 153.1.4.2Application Request to Send Data PAGEREF _Toc2249324 \h 163.1.4.3Application Request to Close Stream PAGEREF _Toc2249325 \h 163.1.5Message Processing Events and Sequencing Rules PAGEREF _Toc2249326 \h 163.1.5.1GSS_Init_sec_context Returns While in the CreatingSecurityToken State PAGEREF _Toc2249327 \h 163.1.5.2Receiving Data in the WaitingForHandshakeMessage State PAGEREF _Toc2249328 \h 173.1.5.3GSS_Init_sec_context Returns While in the ProcessingFinalToken State PAGEREF _Toc2249329 \h 173.1.5.4Receiving Data in the WaitingForHandshakeDone State PAGEREF _Toc2249330 \h 183.1.5.5Receiving Data in the Authenticated State PAGEREF _Toc2249331 \h 183.1.6Timer Events PAGEREF _Toc2249332 \h 183.1.7Other Local Events PAGEREF _Toc2249333 \h 183.2Server Details PAGEREF _Toc2249334 \h 193.2.1Abstract Data Model PAGEREF _Toc2249335 \h 193.2.1.1Underlying TCP Connection PAGEREF _Toc2249336 \h 193.2.1.2Stream State PAGEREF _Toc2249337 \h 203.2.1.3Required Protection Level PAGEREF _Toc2249338 \h 203.2.1.4Negotiated Protection Level PAGEREF _Toc2249339 \h 203.2.1.5Required Impersonation Level PAGEREF _Toc2249340 \h 203.2.1.6Negotiated Impersonation Level PAGEREF _Toc2249341 \h 203.2.1.7Server Credentials PAGEREF _Toc2249342 \h 203.2.1.8Security Provider Context PAGEREF _Toc2249343 \h 213.2.1.9Framing Buffer PAGEREF _Toc2249344 \h 213.2.1.10Expected Channel Binding PAGEREF _Toc2249345 \h 213.2.2Timers PAGEREF _Toc2249346 \h 213.2.3Initialization PAGEREF _Toc2249347 \h 213.2.4Higher-Layer Triggered Events PAGEREF _Toc2249348 \h 213.2.4.1Application Invocation of the .NET NegotiateStream Protocol PAGEREF _Toc2249349 \h 213.2.4.2Application Request to Send Data PAGEREF _Toc2249350 \h 213.2.4.3Application Request to Close Stream PAGEREF _Toc2249351 \h 223.2.5Message Processing Events and Sequencing Rules PAGEREF _Toc2249352 \h 223.2.5.1Receiving Data in the WaitingForHandshakeMessage State PAGEREF _Toc2249353 \h 223.2.5.2GSS_Accept_sec_context Returns While in the CreatingSecurityToken State PAGEREF _Toc2249354 \h 223.2.5.3GSS_Accept_sec_context Returns While in the ProcessingFinalToken State PAGEREF _Toc2249355 \h 233.2.5.4Receiving Data in the Authenticated State PAGEREF _Toc2249356 \h 233.2.6Timer Events PAGEREF _Toc2249357 \h 243.2.7Other Local Events PAGEREF _Toc2249358 \h 244Protocol Examples PAGEREF _Toc2249359 \h 255Security PAGEREF _Toc2249360 \h 305.1Security Considerations for Implementers PAGEREF _Toc2249361 \h 305.2Index of Security Parameters PAGEREF _Toc2249362 \h 306Appendix A: Product Behavior PAGEREF _Toc2249363 \h 317Change Tracking PAGEREF _Toc2249364 \h 328Index PAGEREF _Toc2249365 \h 33Introduction XE "Introduction" XE "Introduction"The .NET NegotiateStream Protocol provides mutually authenticated and confidential communication over a TCP connection. It defines a framing mechanism used to transfer Generic Security Service Application Program Interface (GSS-API) security tokens between a client and server. It also defines a framing mechanism used to transfer signed and/or encrypted application data once the GSS-API security context initialization has completed. It uses the Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation (SPNEGO) mechanism for security services (authentication, key derivation, and data encryption and decryption).Sections 1.5, 1.8, 1.9, 2, and 3 of this specification are normative. All other sections and examples in this specification are informative.Glossary XE "Glossary" This document uses the following terms:Kerberos: An authentication system that enables two parties to exchange private information across an otherwise open network by assigning a unique key (called a ticket) to each user that logs on to the network and then embedding these tickets into messages sent by the users. For more information, see [MS-KILE].little-endian: Multiple-byte values that are byte-ordered with the least significant byte stored in the memory location with the lowest address.Security Support Provider Interface (SSPI): An API that allows connected applications to call one of several security providers to establish authenticated connections and to exchange data securely over those connections. It is equivalent to Generic Security Services (GSS)-API, and the two are on-the-wire compatible.security token: An opaque message or data packet produced by a Generic Security Services (GSS)-style authentication package and carried by the application protocol. The application has no visibility into the contents of the token.MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.References XE "References" Links to a document in the Microsoft Open Specifications library point to the correct section in the most recently published version of the referenced document. However, because individual documents in the library are not updated at the same time, the section numbers in the documents may not match. You can confirm the correct section numbering by checking the Errata. Normative References XE "References:normative" XE "Normative references" We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact dochelp@. We will assist you in finding the relevant information. [MS-ERREF] Microsoft Corporation, "Windows Error Codes".[MS-NLMP] Microsoft Corporation, "NT LAN Manager (NTLM) Authentication Protocol".[MS-SPNG] Microsoft Corporation, "Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Extension".[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000, [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and Ingersoll, W., "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005, References XE "References:informative" XE "Informative references" [MS-KILE] Microsoft Corporation, "Kerberos Protocol Extensions".[MS-NETOD] Microsoft Corporation, "Microsoft .NET Framework Protocols Overview".[RFC4120] Neuman, C., Yu, T., Hartman, S., and Raeburn, K., "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005, [RFC5246] Dierks, T., and Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, XE "Overview (synopsis)" XE "Overview (synopsis)"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 authenticationData confidentiality and integrityThe .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.Relationship to Other Protocols XE "Relationship to other protocols" XE "Relationship to other protocols"The .NET NegotiateStream Protocol relies on TCP for transport, and it relies on the SPNEGO security protocol and the NTLM security protocol for authentication and message security. If the client application requests data integrity protection or confidentiality, the .NET NegotiateStream Protocol performs authentication and negotiates a security protocol to be used to provide these features through the exchange of opaque security tokens generated by the SPNEGO GSS-API mechanism. If the client application protocol does not request either of these features, the .NET NegotiateStream Protocol performs authentication through the exchange of opaque security tokens generated by the NTLM GSS-API mechanism.The .NET NegotiateStream Protocol provides an alternative to other security protocols, such as TLS [RFC5246], which provide for authentication, integrity protection, and encryption of data exchanged by a higher-level protocol. Whereas TLS requires the client and server to maintain valid digital certificates with private keys to authenticate each other and establish key material for signing and encrypting application data, the .NET NegotiateStream Protocol allows authentication and key exchange to be performed securely without the need for digital certificates through the use of SPNEGO and NTLM.Prerequisites/Preconditions XE "Prerequisites" XE "Preconditions" XE "Preconditions" XE "Prerequisites"This protocol assumes that a TCP connection has been established between client and server.Applicability Statement XE "Applicability" XE "Applicability"The .NET NegotiateStream Protocol is designed to secure information transmitted between a client and a server. The protocol provides security services without using digital certificates, and is thus useful to secure network traffic when the use of certificates is not an option. The .NET NegotiateStream Protocol uses SPNEGO (which selects between Kerberos and NTLM) to determine the underlying security protocol to use. Therefore, this protocol is best suited for environments in which a Kerberos infrastructure is deployed (see [MS-KILE] and [RFC4120]). Using SPNEGO, the .NET NegotiateStream Protocol enables: Client and/or server authenticationData integrity and confidentialityVersioning and Capability Negotiation XE "Versioning" XE "Capability negotiation" XE "Capability negotiation" XE "Versioning"This document covers versioning issues in the following areas:Protocol Versions: The .NET NegotiateStream Protocol supports versioning and is currently at version 1.0. The versioning capability is outlined in section 2.2.1. Version 1.0 is the only defined version of the .NET NegotiateStream Protocol. Therefore, no version negotiation semantics are described in this specification.Security and Authentication Methods: The .NET NegotiateStream Protocol supports the use of the SPNEGO and NTLM security protocols. The use of these security protocols is discussed in sections 2.2, 3.1.4, and 3.2.5.Capability Negotiation: This protocol performs explicit negotiation of a security method for providing authentication, data integrity, and data confidentiality as specified in sections 2.2, 3.1.4, and 3.2.5.Vendor-Extensible Fields XE "Vendor-extensible fields" XE "Fields - vendor-extensible" XE "Fields - vendor-extensible" XE "Vendor-extensible fields"This protocol uses HRESULT values as defined in [MS-ERREF] section 2.1. Vendors can define their own HRESULT values, provided they set the C bit (0x20000000) for each vendor-defined value, indicating the value is a customer code.Standards Assignments XE "Standards assignments" XE "Standards assignments"None.MessagesTransport XE "Messages:transport" XE "Transport" XE "Transport" XE "Messages:transport"The .NET NegotiateStream Protocol transports messages using a TCP stream. This protocol specifies a framing for messages over a TCP stream (see section 2.2 for message syntax). The protocol does not define a mechanism to establish the TCP connection; rather, an established TCP connection is a precondition for this protocol.Message Syntax XE "Syntax" XE "Messages:syntax"There are two types of messages defined by the .NET NegotiateStream Protocol: Handshake messages and Data messages. Handshake messages are used to carry GSS-API security tokens used to establish a security context. Once the security context has been established, Data messages are used to carry application data that has been signed and/or encrypted by the negotiated security mechanism.All multi-byte integer fields are transmitted using little-endian representation.Handshake Message XE "Messages:Handshake Message" XE "Handshake Message message" XE "handshake packet"The Handshake message structure is defined as follows.01234567891012345678920123456789301MessageIdMajorVersionMinorVersionHighByteOfPayloadSizeLowByteOfPayloadSizeAuthPayload (variable)...MessageId (1 byte): The type of Handshake message. The value of this field MUST be a value from the following table. ValueMeaningHandshakeDone0x14The handshake has completed successfully.HandshakeError0x15An error occurred during the handshake. The AuthPayload field contains an HRESULT. See the description of the AuthPayload field for further information.HandshakeInProgress0x16The message is part of the handshake phase and is not the final message from the host. The final Handshake message from a host is always transferred in a HandshakeDone message.MajorVersion (1 byte): An unsigned integer that, along with the MinorVersion field, specifies the version of the .NET NegotiateStream Protocol being used. This field MUST be set to 0x01.MinorVersion (1 byte): An unsigned integer that, along with the MajorVersion field, defines the version of the .NET NegotiateStream Protocol being used. This field MUST be set to 0x00.HighByteOfPayloadSize (1 byte): An unsigned integer that, along with the LowByteOfPayloadSize field, defines the size, in bytes, of the AuthPayload field. This field represents the high-order byte of the payload size.LowByteOfPayloadSize (1 byte): An unsigned integer that, along with the HighByteOfPayloadSize field, defines the size, in bytes, of the AuthPayload field. This field represents the low-order byte of the payload size.AuthPayload (variable): When the Handshake message has a MessageId of HandshakeDone or HandshakeInProgress, this field contains the authentication tokens generated by the Security Support Provider Interface (SSPI) security packages (SPNEGO and NTLM) used by the .NET NegotiateStream Protocol. The formats for these tokens are defined in [MS-SPNG] section 2.2 and [MS-NLMP] section 2.2 respectively. When the Handshake message has a MessageId of HandshakeInProgress, this field MUST have a non-zero length. When the Handshake message has a MessageId of HandshakeDone, this field MUST be of zero length if the remote side's security package did not return a security token when indicating successful initialization of the security context. When the Handshake message has a MessageId of HandshakeError, the AuthPayload field MUST have a length of 8 bytes, and contain either an HRESULT error code describing an error encountered by the security package or the Win32 error code ERROR_TRUST_FAILURE (0x000006FE) indicating that the security package was able to successfully authenticate, but the negotiated security parameters were unacceptable to the remote side.The following structure MUST be used to format this error code within the AuthPayload field:01234567891012345678920123456789301ReservedErrorCodeReserved (4 bytes): This field is reserved and MUST be set to zero. The recipient MUST ignore the value.ErrorCode (4 bytes): An HRESULT describing an error encountered by the remote side's security package, or the value 0x000006FE. Data Message XE "Messages:Data Message" XE "Data Message message" XE "dataMessage packet"This section defines the structure of the data exchange messages. These messages are used to transfer application-specific data after the handshake phase is complete. The .NET NegotiateStream Protocol only frames application data using the format noted in the following table if the negotiation of security services during the handshake phase resulted in both the client and server agreeing to sign or encrypt and sign the data to be transferred. Thus, if the negotiated security context in the handshake phase results in a context that supports neither message confidentiality nor integrity, then the data transferred is not framed, and does not follow the format specified in this section (that is, application-supplied data is written directly to the underlying TCP stream).01234567891012345678920123456789301PayloadSizePayload (variable)...PayloadSize (4 bytes): The unsigned size, in bytes, of the Payload field. The maximum value for this field is 0x0000FC30 (64,560).Payload (variable): The application-specific data to transfer between the client and server that has been secured by the selected security mechanism.Protocol DetailsClient Details XE "Client:overview" XE "Client:overview"The following figure represents the client state machine for the .NET NegotiateStream Protocol. The remainder of this section will discuss the state machine in depth.Figure SEQ Figure \* ARABIC 1: Client detailsAbstract Data Model XE "Client:abstract data model" XE "Abstract data model:client" XE "Data model - abstract:client" XE "Data model - abstract:client:overview" XE "Abstract data model:client:overview" XE "Client:abstract data model:overview"This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. This specification does not mandate that implementations adhere to this model, as long as their external behavior is consistent with that specified in this specification.Underlying TCP Connection XE "Data model - abstract:client:TCP connection - underlying" XE "Abstract data model:client:TCP connection - underlying" XE "Client:abstract data model:TCP connection - underlying"The .NET NegotiateStream Protocol uses the Underlying TCP Connection to exchange data with the server.Stream State XE "Data model - abstract:client:Stream state" XE "Abstract data model:client:Stream state" XE "Client:abstract data model:Stream state"The .NET NegotiateStream Protocol uses the Stream State to keep track of the state of the stream. The possible values for the state of the stream are:UninitializedCreatingSecurityTokenWaitingForHandshakeMessageProcessingFinalTokenWaitingForHandshakeDoneAuthenticatedClosedRequired Protection Level XE "Data model - abstract:client:protection level:required" XE "Abstract data model:client:protection level:required" XE "Client:abstract data model:protection level:required"The .NET NegotiateStream Protocol uses the Required Protection Level to keep track of the protection level required by the client application. The possible values for the Required Protection Level and Negotiated Protection Level are: NoneSignEncryptAndSignNegotiated Protection Level XE "Data model - abstract:client:protection level:negotiated" XE "Abstract data model:client:protection level:negotiated" XE "Client:abstract data model:protection level:negotiated"The .NET NegotiateStream Protocol uses the Negotiated Protection Level to keep track of the protection level agreed upon during the security context negotiation with the server. The possible values are the same as those for the Required Protection Level.Allowed Impersonation Level XE "Data model - abstract:client:impersonation level:allowed" XE "Abstract data model:client:impersonation level:allowed" XE "Client:abstract data model:impersonation level:allowed"The .NET NegotiateStream Protocol uses the Allowed Impersonation Level to keep track of the way in which the client application has specified that its credentials can be used by the server application. The possible values for the Allowed Impersonation Level and Negotiated Impersonation Level are:IdentificationImpersonationDelegationNegotiated Impersonation Level XE "Data model - abstract:client:impersonation level:negotiated" XE "Abstract data model:client:impersonation level:negotiated" XE "Client:abstract data model:impersonation level:negotiated"The .NET NegotiateStream Protocol uses the Negotiated Impersonation Level to keep track of the impersonation level agreed upon during the security context negotiation with the server. The possible values are the same as those for the Allowed Impersonation Level.Client Credentials XE "Data model - abstract:client:client credentials" XE "Abstract data model:client:client credentials" XE "Client:abstract data model:client credentials"The .NET NegotiateStream Protocol uses the Client Credentials to store a GSS-API handle to the credentials specified by the client application for authenticating to the server.Security Provider Context XE "Data model - abstract:client:security provider context" XE "Abstract data model:client:security provider context" XE "Client:abstract data model:security provider context"The .NET NegotiateStream Protocol tracks the context of the current security provider chosen during the handshake phase.Framing Buffer XE "Data model - abstract:client:framing buffer" XE "Abstract data model:client:framing buffer" XE "Client:abstract data model:framing buffer"The .NET NegotiateStream Protocol employs a buffer mechanism to handle the receiving and processing of full frames while in the handshake phase, and when the data payloads are signed, and/or encrypted.Channel Binding Token XE "Data model - abstract:client:channel binding token" XE "Abstract data model:client:channel binding token" XE "Client:abstract data model:channel binding token"The .NET NegotiateStream Protocol uses the Channel Binding Token to store the channel binding token provided by the application.Target Name XE "Data model - abstract:client:target name" XE "Abstract data model:client:target name" XE "Client:abstract data model:target name"The .NET NegotiateStream Protocol uses the Target Name to store the target name of the server provided by the application.Timers XE "Client:timers" XE "Timers:client" XE "Timers:client" XE "Client:timers"The .NET NegotiateStream Protocol does not use timers. Protocols above and below this protocol layer are responsible for implementing any timers for time-out events.Initialization XE "Client:initialization" XE "Initialization:client" XE "Initialization:client" XE "Client:initialization"The .NET NegotiateStream Protocol initialization for the client role is triggered by an application event. See section 3.1.4.1 for more details.Higher-Layer Triggered EventsApplication Invocation of the .NET NegotiateStream Protocol XE "Triggered events - higher-layer:client:application:invocation of the .NET NegotiateStream Protocol" XE "Higher-layer triggered events:client:application:invocation of the .NET NegotiateStream Protocol" XE "Client:higher-layer triggered events:application:invocation of the .NET NegotiateStream Protocol"The .NET NegotiateStream Protocol is triggered by an invocation from the application while in the Uninitialized state. If an application invocation is received when the Stream State is not equal to Uninitialized, an error MUST be returned to the application. The application specifies an underlying TCP connection to the server, the desired name to be used for client authentication, a channel binding token, the target name of the server, a required protection level, and an allowed impersonation level. The Underlying TCP Connection, Required Protection Level, Allowed Impersonation Level, Channel Binding Token, and Target Name MUST be set based on these inputs. The application-specified desired_name MUST be passed to the GSS_Acquire_cred function ([RFC2743] section 2.1.1). If the Required Protection Level is None, the implementation MUST pass a desired_mechs parameter indicating the NTLM mechanism. Otherwise, the implementation MUST pass a desired_mechs parameter indicating the SPNEGO mechanism. The cred_usage parameter MUST be set to INITIATE-ONLY and the lifetime_req parameter MUST be set to 0.If the function returns any major_status other than GSS_S_COMPLETE, the implementation MUST notify the application of the failure without sending anything over the Underlying TCP Connection. Otherwise, the implementation MUST store the returned credential handle as the Client Credentials, and MUST set the Stream State to CreatingSecurityToken. The implementation MUST pass the Client Credentials to the GSS_Init_sec_context function ([RFC2743] section 2.2.1). The input_context_handle parameter MUST be GSS_C_NO_CONTEXT. The targ_name parameter MUST be the Target Name. The mech_type parameter MUST be the same as that passed to GSS_Acquire_cred. The deleg_req_flag MUST be true if and only if Allowed Impersonation Level is Delegation. The conf_req_flag MUST be true if and only if the Required Protection Level is EncryptAndSign. The integ_req_flag MUST be true if and only if the Required Protection Level is Sign or EncryptAndSign. The mutual_req_flag, replay_det_req_flag, and sequence_req_flag MUST be true. The anon_req_flag MUST be false. The chan_bindings parameter MUST be the Channel Binding Token. The input_token MUST be NULL, and the lifetime_req MUST be 0.If the conf_avail return value is true, the integ_avail return value will also be true, and the Negotiated Protection Level is EncryptAndSign. If the conf_avail return value is false and the integ_avail return value is true, the Negotiated Protection Level is Sign. Otherwise, the Negotiated Protection Level is None.Application Request to Send Data XE "Triggered events - higher-layer:client:application:request:send data" XE "Higher-layer triggered events:client:application:request:send data" XE "Client:higher-layer triggered events:application:request:send data"When the Stream State is set to Authenticated, the application can at any time request that the protocol transfer an application-specific data message to the server. If the application requests that data be transferred while not in the Authenticated state, an error MUST be returned. If the Negotiated Protection Level is None, the application data MUST be transferred directly over the Underlying TCP Connection. Otherwise, the application data MUST be passed as the input_message parameter to the GSS_Wrap function ([RFC2743] section 2.3.3), along with the Securty Provider Context in the context_handle parameter. The conf_req_flag MUST be set if and only if the Negotiated Protection Level is EncryptAndSign, and the qop_req parameter MUST be set to 0. If the function returns a major_status of GSS_COMPLETE, the output_message MUST be wrapped in a Data Message (as specified in section 2.2.2) and transmitted to the server via the Underlying TCP Connection. If any other major_status is returned, the client application MUST be notified of the failure without writing anything to the Underlying TCP Connection.Application Request to Close Stream XE "Triggered events - higher-layer:client:application:request:close stream" XE "Higher-layer triggered events:client:application:request:close stream" XE "Client:higher-layer triggered events:application:request:close stream"The application can at any time request that the stream be closed. When this trigger is received, the Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed.Message Processing Events and Sequencing RulesGSS_Init_sec_context Returns While in the CreatingSecurityToken State XE "Sequencing rules:client:GSS_Init_sec_context returns:CreatingSecurityToken state" XE "Message processing:client:GSS_Init_sec_context returns:CreatingSecurityToken state" XE "Client:sequencing rules:GSS_Init_sec_context returns:CreatingSecurityToken state" XE "Client:message processing:GSS_Init_sec_context returns:CreatingSecurityToken state"If GSS_Init_sec_context returns a major_status of GSS_S_COMPLETE, the Negotiated Protection Level and Negotiated Impersonation Level MUST be set based on the returned state flags. The Security Provider Context MUST be set to the output_context_handle. If the Negotiated Impersonation Level is not equal to the Allowed Impersonation Level or the Negotiated Protection Level is lower than the Required Protection Level, the value 0x000006FE MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeError (as specified in section 2.2) and transmitted to the server. The Security Provider Context MUST be deleted and the Stream State MUST be set to Uninitialized. Otherwise, the output_token MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeDone (as specified in section 2.2) and transmitted to the server. In this case, the Stream State MUST be set to WaitingForHandshakeDone.If GSS_Init_sec_context returns a major status of GSS_S_CONTINUE_NEEDED, the Security Provider Context MUST be set to the output_context_handle and the output_token MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeInProgress (as specified in section 2.2) and sent to the server. The Stream State MUST be set to WaitingForHandshakeMessage.If any other major_status is returned, an HRESULT error code describing the error MUST be wrapped in the AuthPayload of a Handshake message with the HandshakeId set to HandshakeError (as specified in section 2.2) and sent to the server. The Stream State MUST be set to Uninitialized.Receiving Data in the WaitingForHandshakeMessage State XE "Sequencing rules:client:receiving data:WaitingForHandshakeMessage state" XE "Message processing:client:receiving data:WaitingForHandshakeMessage state" XE "Client:sequencing rules:receiving data:WaitingForHandshakeMessage state" XE "Client:message processing:receiving data:WaitingForHandshakeMessage state"The first five bytes received MUST be interpreted as the header of a Handshake message (as specified in section 2.2). The payload size MUST be reassembled from the HighByteOfPayloadSize and LowByteOfPayloadSize fields. The MajorVersion and MinorVersion MUST be ignored. The implementation MUST continue to receive data from the Underlying TCP Connection (storing it in the Framing Buffer) until the entire payload has been received. When a full frame has been received, the client MUST check the HandshakeId field of the message to see if it matches one of the three known message IDs for .NET NegotiateStream Handshake messages. If the message ID received matches the message ID for:A HandshakeInProgress message: Upon receipt of a message of this type, the Stream State MUST be set to CreatingSecurityToken. The client MUST take the token from the AuthPayload field of the message and pass it to the GSS_Init_sec_context function ([RFC2743] section 2.2.1), along with the Security Provider Context, Client Credentials, Target Name, Channel Binding Token, and the same other parameters as the first call to GSS_Init_sec_context (see section 3.1.4.1).A HandshakeDone message:Upon receipt of a message of this type, the Stream State MUST be set to ProcessingFinalToken. The client MUST take the token from the AuthPayload field of the message and pass it to the GSS_Init_sec_context function ([RFC2743] section 2.2.1) along with the Security Provider Context, Client Credentials, Target Name, Channel Binding Token, and the same other parameters as the first call to GSS_Init_sec_context (see section 3.1.4.1).A HandshakeError message: Upon receipt of a message of this type, the Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed. The application MUST be notified of the HRESULT contained in the AuthPayload field. (If the application wishes to retry the authentication, it can do so by invoking a new instance of the protocol with a new Underlying TCP Connection.)None of the preceding handshake message types: The message type is invalid. The Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed. The application MUST be notified of the failure. (If the application wishes to retry the authentication, it can do so by invoking a new instance of the protocol with a new Underlying TCP Connection.)GSS_Init_sec_context Returns While in the ProcessingFinalToken State XE "Sequencing rules:client:GSS_Init_sec_context returns:ProcessingFinalToken state" XE "Message processing:client:GSS_Init_sec_context returns:ProcessingFinalToken state" XE "Client:sequencing rules:GSS_Init_sec_context returns:ProcessingFinalToken state" XE "Client:message processing:GSS_Init_sec_context returns:ProcessingFinalToken state"If GSS_Init_sec_context returns a major_status of GSS_S_COMPLETE, the Negotiated Protection Level and Negotiated Impersonation Level MUST be set based on the returned state flags. If the Negotiated Impersonation Level is not equal to the Allowed Impersonation Level or the Negotiated Protection Level is less than the Required Protection Level, the value 0x000006FE MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeError (as specified in section 2.2) and transmitted to the server. The Security Provider Context MUST be deleted, and the Stream State MUST be set to Uninitialized. Otherwise, the Stream State MUST be set to Authenticated and the client application MUST be notified of the successful authentication.If the function returns any other major_status, an HRESULT describing the error MUST be wrapped in a Handshake message with the HandshakeId set to HandshakeError (as specified in section 2.2) and transmitted to the server. The Security Provider Context MUST be deleted and the Stream State MUST be set to Uninitialized. The application MUST be notified of the authentication failure.Receiving Data in the WaitingForHandshakeDone State XE "Sequencing rules:client:receiving data:WaitingForHandshakeDone state" XE "Message processing:client:receiving data:WaitingForHandshakeDone state" XE "Client:sequencing rules:receiving data:WaitingForHandshakeDone state" XE "Client:message processing:receiving data:WaitingForHandshakeDone state"The first five bytes received MUST be interpreted as the header of a Handshake message (as specified in section 2.2). The payload size MUST be reassembled from the HighByteOfPayloadSize and LowByteOfPayloadSize fields. The MajorVersion and MinorVersion MUST be ignored. The implementation MUST continue to receive data from the Underlying TCP Connection (storing it in the Framing Buffer) until the entire payload has been received. If the message has a HandshakeId of HandshakeDone, the AuthPayload field MUST be ignored. The Stream State MUST be set to Authenticated, and the client application MUST be notified of a successful authentication.If the message has a HandshakeId of HandshakeError, the Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed. The application MUST be notified of the HRESULT contained in the AuthPayload field. (If the application wishes to retry the authentication, it can do so by invoking a new instance of the protocol with a new Underlying TCP Connection.)If the message has any other HandshakeId (including HandshakeInProgress) the message type is invalid. The Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed. The application MUST be notified of the failure. (If the application wishes to retry the authentication, it can do so by invoking a new instance of the protocol with a new Underlying TCP Connection.)Receiving Data in the Authenticated State XE "Sequencing rules:client:receiving data:Authenticated state" XE "Message processing:client:receiving data:Authenticated state" XE "Client:sequencing rules:receiving data:Authenticated state" XE "Client:message processing:receiving data:Authenticated state"When data arrives on the Underlying TCP Connection, the following actions MUST be taken:If the Negotiated Protection Level is None, any bytes received MUST be delivered unmodified to the application.Otherwise, the first four bytes received MUST be interpreted as the PayloadSize field of a Data message (as specified in section 2.2). The implementation MUST then continue to receive data from the Underlying TCP Connection (storing it in the Framing Buffer) until PayloadSize bytes have been received. When a full frame has been received, it MUST be passed to the GSS_Unwrap function ([RFC2743] section 2.3.4) along with the Security Provider Context. If the function returns a major_status of GSS_S_COMPLETE, the output_message MUST be delivered to the application. If the function returns any other major_status, the application MUST be notified of the failure and the buffered message MUST be discarded.Timer Events XE "Client:timer events" XE "Timer events:client" XE "Timer events:client" XE "Client:timer events"None.Other Local Events XE "Client:other local events" XE "Other local events:client" XE "Local events:client" XE "Client:local events"If the server closes the Underlying TCP Connection, the Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed. The application MUST be notified that the server has closed the connection.Server Details XE "Server:overview" XE "Server:overview"The following figure represents the server state machine for the .NET NegotiateStream Protocol. The remainder of this section will discuss the state machine in depth.Figure SEQ Figure \* ARABIC 2: Server detailsAbstract Data Model XE "Server:abstract data model" XE "Abstract data model:server" XE "Data model - abstract:server" XE "Data model - abstract:server:overview" XE "Abstract data model:server:overview" XE "Server:abstract data model:overview"This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. This specification does not mandate that implementations adhere to this model as long as their external behavior is consistent with that specified in this specification.Underlying TCP Connection XE "Data model - abstract:server:TCP connection - underlying" XE "Abstract data model:server:TCP connection - underlying" XE "Server:abstract data model:TCP connection - underlying"The .NET NegotiateStream Protocol uses the Underlying TCP Connection to exchange data with the client.Stream State XE "Data model - abstract:server:Stream state" XE "Abstract data model:server:Stream state" XE "Server:abstract data model:Stream state"The .NET NegotiateStream Protocol uses the Stream State to keep track of the state of the stream. The possible values for the state of the stream are:UninitializedCreatingSecurityTokenWaitingForHandshakeMessageProcessingFinalTokenAuthenticatedClosedRequired Protection Level XE "Data model - abstract:server:protection level:required" XE "Abstract data model:server:protection level:required" XE "Server:abstract data model:protection level:required"The .NET NegotiateStream Protocol uses the Required Protection Level to keep track of the protection level required by the server application. The possible values for Required Protection Level and Negotiated Protection Level are:NoneSignEncryptAndSignNegotiated Protection Level XE "Data model - abstract:server:protection level:negotiated" XE "Abstract data model:server:protection level:negotiated" XE "Server:abstract data model:protection level:negotiated"The .NET NegotiateStream Protocol uses the Negotiated Protection Level to keep track of the protection level agreed upon during the security context negotiation with the client. The possible values are the same as those for the Required Protection Level.Required Impersonation Level XE "Data model - abstract:server:impersonation level:required" XE "Abstract data model:server:impersonation level:required" XE "Server:abstract data model:impersonation level:required"The .NET NegotiateStream Protocol uses the Required Impersonation Level to keep track of the way in which the server application intends to use the credentials specified by the client. The possible values for the Required Impersonation Level and Negotiated Impersonation Level are:IdentificationImpersonationDelegationNegotiated Impersonation Level XE "Data model - abstract:server:impersonation level:negotiated" XE "Abstract data model:server:impersonation level:negotiated" XE "Server:abstract data model:impersonation level:negotiated"The .NET NegotiateStream Protocol uses the Negotiated Impersonation Level to keep track of the impersonation level agreed upon during the security context negotiation with the client. The possible values are the same as those for the Required Impersonation Level.Server Credentials XE "Data model - abstract:server:server credentials" XE "Abstract data model:server:server credentials" XE "Server:abstract data model:server credentials"The .NET NegotiateStream Protocol uses the Server Credentials to store a GSS-API handle to the credentials specified by the server application for authenticating itself to the client.Security Provider Context XE "Data model - abstract:server:security provider context" XE "Abstract data model:server:security provider context" XE "Server:abstract data model:security provider context"The .NET NegotiateStream Protocol tracks the context of the current security provider chosen during the handshake phase.Framing Buffer XE "Data model - abstract:server:framing buffer" XE "Abstract data model:server:framing buffer" XE "Server:abstract data model:framing buffer"The .NET NegotiateStream Protocol employs a buffer mechanism to handle the receiving and processing of full frames while in the handshake phase, and when the data payloads are signed, and/or encrypted.Expected Channel Binding XE "Data model - abstract:server:channel binding - expected" XE "Abstract data model:server:channel binding - expected" XE "Server:abstract data model:channel binding - expected"The .NET NegotiateStream Protocol uses the Expected Channel Binding to store the channel binding token, which the client is expected to provide along with its credentials.Timers XE "Server:timers" XE "Timers:server" XE "Timers:server" XE "Server:timers"The .NET NegotiateStream Protocol does not use timers. Protocols above and below this protocol layer are responsible for implementing any timers for time-out events.Initialization XE "Server:initialization" XE "Initialization:server" XE "Initialization:server" XE "Server:initialization"The .NET NegotiateStream Protocol initialization for the server role is triggered by an application event. See section 3.2.4.1 for more details.Higher-Layer Triggered EventsApplication Invocation of the .NET NegotiateStream Protocol XE "Triggered events - higher-layer:server:application:invocation of the .NET NegotiateStream protocol" XE "Higher-layer triggered events:server:application:invocation of the .NET NegotiateStream protocol" XE "Server:higher-layer triggered events:application:invocation of the .NET NegotiateStream protocol"The .NET NegotiateStream Protocol is triggered by an invocation from the application while the Stream State is set to Uninitialized. If an application invocation is received when the Stream State is not equal to Uninitialized, an error MUST be returned to the application. The application specifies an underlying TCP connection to the client, the desired name to be used for server authentication, an expected channel binding, a required protection level, and a required impersonation level. The Underlying TCP Connection, Expected Channel Binding, Required Protection Level, and Required Impersonation Level MUST be set based on these inputs. The application-specified desired_name MUST be passed to the GSS_Acquire_cred function ([RFC2743] section 2.1.1). The implementation MUST pass a desired_mechs parameter indicating the SPNEGO mechanism. The cred_usage parameter MUST be set to ACCEPT-ONLY, and the lifetime_req parameter MUST be set to 0.If the function returns a major_status other than GSS_S_COMPLETE, the implementation MUST notify the application of the failure without writing anything to the Underlying TCP Connection. Otherwise, the implementation MUST store the returned credential handle as the Server Credentials and set the Stream State to WaitingForHandshakeMessage.Application Request to Send Data XE "Triggered events - higher-layer:server:application:request:send data" XE "Higher-layer triggered events:server:application:request:send data" XE "Server:higher-layer triggered events:application:request:send data"When the Stream State is set to Authenticated, the application can at any time request that the protocol transfer an application-specific data message to the client. If the application requests that data be transferred while not in the Authenticated state, an error MUST be returned. If the Negotiated Protection Level is None, the application data MUST be transferred directly over the Underlying TCP Connection. Otherwise, the application data MUST be passed as the input_message parameter to the GSS_Wrap function ([RFC2743] section 2.3.3) along with the Security Provider Context as the context_handle parameter. The conf_req_flag MUST be set if and only if the Negotiated Protection Level is EncryptAndSign, and the qop_req parameter MUST be set to 0. If the function returns a major_status of GSS_S_COMPLETE, the output_message MUST be wrapped in a Data message (as specified in section 2.2) and transmitted to the client via the Underlying TCP Connection. If any other major_status is returned, the server application MUST be notified of the failure without writing anything to the Underlying TCP Connection.Application Request to Close Stream XE "Triggered events - higher-layer:server:application:request:close stream" XE "Higher-layer triggered events:server:application:request:close stream" XE "Server:higher-layer triggered events:application:request:close stream"The application can at any time request that the stream be closed. When this trigger is received, the Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed.Message Processing Events and Sequencing RulesReceiving Data in the WaitingForHandshakeMessage State XE "Sequencing rules:server:receiving data:WaitingForHandshakeMessage state" XE "Message processing:server:receiving data:WaitingForHandshakeMessage state" XE "Server:sequencing rules:receiving data:WaitingForHandshakeMessage state" XE "Server:message processing:receiving data:WaitingForHandshakeMessage state"The first five bytes received MUST be interpreted as the header of a Handshake message (as specified in section 2.2). The payload size MUST be reassembled from the HighByteOfPayloadSize and LowByteOfPayloadSize fields. The MajorVersion and MinorVersion MUST be ignored. The implementation MUST continue to receive data from the Underlying TCP Connection (storing it in the Framing Buffer) until the entire payload has been received. When a full frame has been received, the server MUST check the HandshakeId field of the message to see whether it matches one of the three known message IDs for .NET NegotiateStream Handshake messages. If the message ID received matches the message ID for:A HandshakeInProgress message: Upon receipt of a message of this type, the Stream State MUST be set to CreatingSecurityToken. The server MUST take the token from the AuthPayload field of the message and pass it to the GSS_Accept_sec_context function ([RFC2743] section 2.2.2) along with the Server Credentials and Expected Channel Binding. If no Security Provider Context has been saved from a previous call to GSS_Accept_sec_context, the input_context_handle MUST be set to GSS_C_NO_CONTEXT. Otherwise, the saved Security Provider Context MUST be passed.A HandshakeDone message: Upon receipt of a message of this type, the Stream State MUST be set to ProcessingLastToken. The server MUST take the token from the AuthPayload field of the message and pass it to the GSS_Accept_sec_context function ([RFC2743] section 2.2.2) along with the Security Provider Context, Server Credentials, and Expected Channel Binding.A HandshakeError message: Upon receipt of a message of this type, the Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed. The application MUST be notified of the HRESULT contained in the AuthPayload field. (If the application wishes to retry the authentication, it can do so by invoking a new instance of the protocol with a new Underlying TCP Connection.)None of the preceding handshake message types: The message type is invalid. The Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed. The application MUST be notified of the failure. (If the application wishes to retry the authentication, it can do so by invoking a new instance of the protocol with a new Underlying TCP Connection.)GSS_Accept_sec_context Returns While in the CreatingSecurityToken State XE "Sequencing rules:server:GSS_Accept_sec_context returns:CreatingSecurityToken state" XE "Message processing:server:GSS_Accept_sec_context returns:CreatingSecurityToken state" XE "Server:sequencing rules:GSS_Accept_sec_context returns:CreatingSecurityToken state" XE "Server:message processing:GSS_Accept_sec_context returns:CreatingSecurityToken state"If GSS_Accept_sec_context returns a major_status of GSS_S_COMPLETE, the Negotiated Protection Level and Negotiated Impersonation Level MUST be set based on the returned state flags. The Security Provider Context MUST be set to the output_context_handle. If the Negotiated Impersonation Level is less than the Required Impersonation Level or the Negotiated Protection Level is less than the Required Protection Level, the value 0x000006FE MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeError (as specified in section 2.2) and transmitted to the client. The Security Provider Context MUST be deleted, and the Stream State MUST be set to Uninitialized. Otherwise, the output_token MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeDone (as specified in section 2.2) and transmitted to the client. The Stream State MUST be set to Authenticated, and the server application MUST be notified of a successful authentication.If the function returns a major_status of GSS_S_CONTINUE_NEEDED, the output_token MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeInProgress (as specified in section 2.2) and transmitted to the client. If the Security Provider Context has not yet been set, it MUST be set to the output_context_handle. The Stream State MUST be set to WaitingForHandshakeMessage.If the function returns any other major_status, an HRESULT describing the error MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeError (as specified in section 2.2) and transmitted to the client. The Security Provider Context MUST be deleted, and the Stream State MUST be set to Uninitialized.GSS_Accept_sec_context Returns While in the ProcessingFinalToken State XE "Sequencing rules:server:GSS_Accept_sec_context returns:ProcessingFinalToken state" XE "Message processing:server:GSS_Accept_sec_context returns:ProcessingFinalToken state" XE "Server:sequencing rules:GSS_Accept_sec_context returns:ProcessingFinalToken state" XE "Server:message processing:GSS_Accept_sec_context returns:ProcessingFinalToken state"If GSS_Accept_sec_context returns a major_status of GSS_S_COMPLETE, the Negotiated Protection Level and Negotiated Impersonation Level MUST be set based on the returned state flags. The Security Provider Context MUST be set to the output_context_handle. If the Negotiated Impersonation Level is less than the Required Impersonation Level, or the Negotiated Protection Level is less than the Required Protection Level, the value 0x000006FE MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeError (as specified in section 2.2) and transmitted to the client. The Security Provider Context MUST be deleted, and the Stream State MUST be set to Uninitialized. Otherwise, a Handshake message with the HandshakeId set to HandshakeDone MUST be constructed with a zero-length AuthPayload and transmitted to the client. The Stream State MUST be set to Authenticated and the server application MUST be notified of the successful authentication.If the function returns any other major_status, an HRESULT describing the error MUST be wrapped in the AuthPayload field of a Handshake message with the HandshakeId set to HandshakeError (as specified in section 2.2) and transmitted to the client. The Security Provider Context MUST be deleted and the Stream State MUST be set to Uninitialized. The application MUST be notified of the authentication failure.Receiving Data in the Authenticated State XE "Sequencing rules:server:receiving data:Authenticated state" XE "Message processing:server:receiving data:Authenticated state" XE "Server:sequencing rules:receiving data:Authenticated state" XE "Server:message processing:receiving data:Authenticated state"After sending a HandshakeDone message to the client, the server can receive Data messages from the client at any time. When data arrives on the Underlying TCP Connection, the following actions MUST be taken:If the Negotiated Protection Level is None, any bytes received MUST be delivered unmodified to the application.Otherwise, the first four bytes received MUST be interpreted as the PayloadSize field of a Data message (as defined in section 2.2). The implementation MUST then continue to receive data from the Underlying TCP Connection (storing it in the Framing Buffer) until PayloadSize bytes have been received. When a full frame has been received, it MUST be passed to the GSS_Unwrap function ([RFC2743] section 2.3.4) along with the Security Provider Context. If the function returns a major_status of GSS_S_COMPLETE, the output_message MUST be delivered to the application. If the function returns any other major_status, the application MUST be notified of the failure and the buffered message MUST be discarded.Timer Events XE "Server:timer events" XE "Timer events:server" XE "Timer events:server" XE "Server:timer events"None.Other Local Events XE "Server:other local events" XE "Other local events:server" XE "Local events:server" XE "Server:local events"If the client closes the Underlying TCP Connection, the Security Provider Context MUST be deleted, the Underlying TCP Connection MUST be closed, and the Stream State MUST be set to Closed. The application MUST be notified that the client has closed the connection.Protocol Examples XE "Examples - overview"Figure SEQ Figure \* ARABIC 3: Protocol sequence exampleThe previous figure gives a simple example of handshake, data transfer, and closing of the connection when the client and server negotiate a security mechanism that authenticates both the client and server and provides data integrity and confidentiality protections.To initiate the connection, the client first calls the GSS_Init_sec_context function to obtain a security token. This security token is placed in the AuthPayload field of a HandshakeInProgress message and sent to the server.Upon receipt of this HandshakeInProgress message, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function returns an output token and indicates that the security context negotiation is not yet complete. The server takes the token returned from GSS_Accept_sec_context, places this in the AuthPayload field of a HandShakeInProgress message, and sends this message to the client.The client receives the HandshakeInProgress message, and passes the token in the AuthPayload to GSS_Init_sec_context. The number of HandshakeInProgress messages exchanged between the client and server is dependent on the authentication level selected by the client and the authentication protocol that was negotiated between the client and server. In this example, the return code of GSS_Init_sec_context indicates that the handshake is not complete. The client takes the token returned from GSS_Init_sec_context, and places it in the AuthPayload field of a HandshakeInProgress message. The client sends the HandshakeInProgress message to the server.After the server receives the HandshakeInProgress message from the client, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function returns an output token and indicates that the security context negotiation is complete. The server takes the token returned from GSS_Accept_sec_context, places this in the AuthPayload field of a HandShakeDone message, and sends this message to the client. The server now enters the data transfer phase. When the client receives the HandshakeDone message from the server, it also transitions to the data transfer phase. In this example, the client chooses to send a single message to the server. The client creates this message as specified in section 2.2.2, using the negotiated security context from the handshake phase. The client then sends this message to the server. The server receives the message, and in this example chooses to end the connection at this time. The server closes the underlying TCP connection to the client. The client application is notified that the server has closed the connection.Figure SEQ Figure \* ARABIC 4: Protocol sequence exampleThe previous figure gives another simple example of handshake, data transfer, and closing of the connection when the client and server negotiate a security mechanism that authenticates only the client and does not provide data integrity or confidentiality protections.To initiate the connection, the client first calls the GSS_Init_sec_context function to obtain a security token. This security token is placed in the AuthPayload field of a HandshakeInProgress message, which is sent to the server.Upon receipt of this HandshakeInProgress message, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function returns an output token and indicates that the security context negotiation is not yet complete.The server takes the token returned from GSS_Accept_sec_context, places this in the AuthPayload field of a HandShakeInProgress message, and sends this message to the client.The client receives the HandshakeInProgress message, and passes the token in the AuthPayload to GSS_Init_sec_context. In this example, the return code of GSS_Init_sec_context indicates that the handshake is complete. The client takes the token returned from GSS_Init_sec_context, and places it in the AuthPayload field of a HandshakeDone message. The client sends the HandshakeDone message to the server.After the server receives the HandshakeDone message from the client, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function indicates that the security context negotiation is complete as well. No token is returned, so the server sends a HandshakeDone message with no AuthPayload to the client. The server now enters the data transfer phase. In this example, the server chooses to send a single message to the client. No data integrity or confidentiality protections have been negotiated, so the data is sent directly over the underlying TCP connection.The client receives the message and in this example chooses to end the connection at this time. The client closes the underlying TCP connection to the server.The server application is notified that the client has closed the connection.Figure SEQ Figure \* ARABIC 5: Protocol sequence exampleThe previous figure gives a final simple example of handshake in which the server rejects the client's credentials.To initiate the connection, the client first calls the GSS_Init_sec_context function to obtain a security token. This security token is placed in the AuthPayload field of a HandshakeInProgress message, which is sent to the server.Upon receipt of this HandshakeInProgress message, the server passes the AuthPayload to the GSS_Accept_sec_context function. In this example, this function returns an error indicating that the client's credentials have been rejected.The server constructs a HandshakeError message containing the HRESULT SEC_E_LOGON_DENIED (0x8009030C) and sends it to the client to indicate the failure.The client receives the HandshakeError message, notifies the application that the provided credentials have been rejected, and closes the underlying TCP connection.The server application is notified that the client has closed the connection.SecuritySecurity Considerations for Implementers XE "Security:implementer considerations" XE "Implementer - security considerations" XE "Implementer - security considerations" XE "Security:implementer considerations"The .NET NegotiateStream Protocol is dependent on the security services of the SPNEGO and NTLM security packages. Before using the .NET NegotiateStream Protocol, implementers will want to carefully review the characteristics of the NTLM security package and all security providers used by SPNEGO on the platforms where the implementation will be used.Index of Security Parameters XE "Security:parameter index" XE "Index of security parameters" XE "Parameters - security index" XE "Parameters - security index" XE "Index of security parameters" XE "Security:parameter index" Security Parameter Section Client Role: Credentials, Required Protection Level, Allowed Impersonation Level, Channel Binding Token, Target Name3.1.4.1Server Role: Credentials, Required Protection Level, Required Impersonation Level, Expected Channel Binding3.2.4.1Appendix A: Product Behavior XE "Product behavior" The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.This document specifies version-specific details in the Microsoft .NET Framework. For information about which versions of .NET Framework are available in each released Windows product or as supplemental software, see [MS-NETOD] section 4.Microsoft .NET Framework 2.0Microsoft .NET Framework 3.0Microsoft .NET Framework 3.5Microsoft .NET Framework 3.5 Service Pack 1 (SP1)Microsoft .NET Framework 4.0Microsoft .NET Framework 4.5Microsoft .NET Framework 4.6Microsoft .NET Framework 4.7Microsoft .NET Framework 4.8Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.Change Tracking XE "Change tracking" XE "Tracking changes" This section identifies changes that were made to this document since the last release. Changes are classified as Major, Minor, or None. The revision class Major means that the technical content in the document was significantly revised. Major changes affect protocol interoperability or implementation. Examples of major changes are:A document revision that incorporates changes to interoperability requirements.A document revision that captures changes to protocol functionality.The revision class Minor means that the meaning of the technical content was clarified. Minor changes do not affect protocol interoperability or implementation. Examples of minor changes are updates to clarify ambiguity at the sentence, paragraph, or table level.The revision class None means that no new technical changes were introduced. Minor editorial and formatting changes may have been made, but the relevant technical content is identical to the last released version.The changes made to this document are listed in the following table. For more information, please contact dochelp@.SectionDescriptionRevision class2.2.2 Data Message9333 : Corrected the maximum size of the PayloadSize field by changing it from '0x0000FC00' to '0x0000FC30', to accommodate for both the application data size and the size increase that occurs when this protocol signs or encrypts the data to be transferred.Major6 Appendix A: Product BehaviorAdded .NET Framework v4.8 to the applicability list.MajorIndexAAbstract data model client PAGEREF section_d7b98310e71b4ad6a9c972409f9a177c13 channel binding token PAGEREF section_9ba6cfb4483148c2bf9d00b5ad21f0fb15 client credentials PAGEREF section_a9952b5467b74f3f93720f9bb9da0b5715 framing buffer PAGEREF section_67448cdf906541f8a3b57b9feb21c88e15 impersonation level allowed PAGEREF section_f97afabcbd524ad0ba8b196929707af414 negotiated PAGEREF section_ed7928e6874b43d2944ae0f8a13f391a15 overview PAGEREF section_d7b98310e71b4ad6a9c972409f9a177c13 protection level negotiated PAGEREF section_2bf2f31fb8f347f4a6f9d0e5445a82df14 required PAGEREF section_1bc0a3230304427ea54f0f9e916e61c114 security provider context PAGEREF section_3b6abe2f3d4e47259520d1984d97311815 Stream state PAGEREF section_4fc6064027f640dd8b8a8aef2d86373114 target name PAGEREF section_7471e31681f046a8b34b2a060b34ee4f15 TCP connection - underlying PAGEREF section_f840b5fe95904c688b994351e9ff6b5a14 server PAGEREF section_7b54d193e09841589332d646461f42da19 channel binding - expected PAGEREF section_543dce59ee844f898bbd837c26225d7a21 framing buffer PAGEREF section_788a92296b4e4455bcd088afeccaae2221 impersonation level negotiated PAGEREF section_88fc665394fc49c5bf57aba05eb87d5320 required PAGEREF section_74129f04c7934b449fad927437d1685220 overview PAGEREF section_7b54d193e09841589332d646461f42da19 protection level negotiated PAGEREF section_3aa83827ca144e778b9c0354f15c9ea620 required PAGEREF section_dd9f9e34b5304ad5a7f6bad235ba1e5420 security provider context PAGEREF section_435a976887e14acaa396457babd99e8421 server credentials PAGEREF section_9c1ebe98ac284d15a395f2eb295a495220 Stream state PAGEREF section_f924797155bd415e817d606eb640f64d20 TCP connection - underlying PAGEREF section_e4c6c88dfa0c4fe4b7f06ba07c05089419Applicability PAGEREF section_0287a7019f1646cd94e3f8fee2db4db68CCapability negotiation PAGEREF section_61a57bfa5d8a4a89b7a4412ac74b82928Change tracking PAGEREF section_a84afeb9f5a341459c344d4c5d6b532032Client abstract data model PAGEREF section_d7b98310e71b4ad6a9c972409f9a177c13 channel binding token PAGEREF section_9ba6cfb4483148c2bf9d00b5ad21f0fb15 client credentials PAGEREF section_a9952b5467b74f3f93720f9bb9da0b5715 framing buffer PAGEREF section_67448cdf906541f8a3b57b9feb21c88e15 impersonation level allowed PAGEREF section_f97afabcbd524ad0ba8b196929707af414 negotiated PAGEREF section_ed7928e6874b43d2944ae0f8a13f391a15 overview PAGEREF section_d7b98310e71b4ad6a9c972409f9a177c13 protection level negotiated PAGEREF section_2bf2f31fb8f347f4a6f9d0e5445a82df14 required PAGEREF section_1bc0a3230304427ea54f0f9e916e61c114 security provider context PAGEREF section_3b6abe2f3d4e47259520d1984d97311815 Stream state PAGEREF section_4fc6064027f640dd8b8a8aef2d86373114 target name PAGEREF section_7471e31681f046a8b34b2a060b34ee4f15 TCP connection - underlying PAGEREF section_f840b5fe95904c688b994351e9ff6b5a14 higher-layer triggered events application invocation of the .NET NegotiateStream Protocol PAGEREF section_878a827b0d3a4d7a9c6fedf9c2239fb815 request close stream PAGEREF section_e2db728d5dc944c8b50a7c7fdcbab89816 send data PAGEREF section_1d58818e2b774b009ecb9e10882cf36716 initialization PAGEREF section_80354ec9098d429fae9006c47bab22da15 local events PAGEREF section_8b55a18369dc4b5989cd76048d1b67d618 message processing GSS_Init_sec_context returns CreatingSecurityToken state PAGEREF section_8da4cc5b790f4af38ab13a26ccc01ea216 ProcessingFinalToken state PAGEREF section_cc2263e63ab74d2693fa07f469f5869717 receiving data Authenticated state PAGEREF section_1d53294af31a4773ad9df44fa5cd42ac18 WaitingForHandshakeDone state PAGEREF section_dce7597ad3864645aa15f0c774b5216518 WaitingForHandshakeMessage state PAGEREF section_fed5e9722dcf409dbfe96b939c83bc2017 other local events PAGEREF section_8b55a18369dc4b5989cd76048d1b67d618 overview PAGEREF section_902195137b8149399dc10f21ddc4964a13 sequencing rules GSS_Init_sec_context returns CreatingSecurityToken state PAGEREF section_8da4cc5b790f4af38ab13a26ccc01ea216 ProcessingFinalToken state PAGEREF section_cc2263e63ab74d2693fa07f469f5869717 receiving data Authenticated state PAGEREF section_1d53294af31a4773ad9df44fa5cd42ac18 WaitingForHandshakeDone state PAGEREF section_dce7597ad3864645aa15f0c774b5216518 WaitingForHandshakeMessage state PAGEREF section_fed5e9722dcf409dbfe96b939c83bc2017 timer events PAGEREF section_52c5bdd589e64b5493f3b0c19f6948a618 timers PAGEREF section_a6e20a4e87e747eab2fd0c6706b7f0ee15DData Message message PAGEREF section_decab65113304ce9bac596d19310cb4011Data model - abstract client PAGEREF section_d7b98310e71b4ad6a9c972409f9a177c13 channel binding token PAGEREF section_9ba6cfb4483148c2bf9d00b5ad21f0fb15 client credentials PAGEREF section_a9952b5467b74f3f93720f9bb9da0b5715 framing buffer PAGEREF section_67448cdf906541f8a3b57b9feb21c88e15 impersonation level allowed PAGEREF section_f97afabcbd524ad0ba8b196929707af414 negotiated PAGEREF section_ed7928e6874b43d2944ae0f8a13f391a15 overview PAGEREF section_d7b98310e71b4ad6a9c972409f9a177c13 protection level negotiated PAGEREF section_2bf2f31fb8f347f4a6f9d0e5445a82df14 required PAGEREF section_1bc0a3230304427ea54f0f9e916e61c114 security provider context PAGEREF section_3b6abe2f3d4e47259520d1984d97311815 Stream state PAGEREF section_4fc6064027f640dd8b8a8aef2d86373114 target name PAGEREF section_7471e31681f046a8b34b2a060b34ee4f15 TCP connection - underlying PAGEREF section_f840b5fe95904c688b994351e9ff6b5a14 server PAGEREF section_7b54d193e09841589332d646461f42da19 channel binding - expected PAGEREF section_543dce59ee844f898bbd837c26225d7a21 framing buffer PAGEREF section_788a92296b4e4455bcd088afeccaae2221 impersonation level negotiated PAGEREF section_88fc665394fc49c5bf57aba05eb87d5320 required PAGEREF section_74129f04c7934b449fad927437d1685220 overview PAGEREF section_7b54d193e09841589332d646461f42da19 protection level negotiated PAGEREF section_3aa83827ca144e778b9c0354f15c9ea620 required PAGEREF section_dd9f9e34b5304ad5a7f6bad235ba1e5420 security provider context PAGEREF section_435a976887e14acaa396457babd99e8421 server credentials PAGEREF section_9c1ebe98ac284d15a395f2eb295a495220 Stream state PAGEREF section_f924797155bd415e817d606eb640f64d20 TCP connection - underlying PAGEREF section_e4c6c88dfa0c4fe4b7f06ba07c05089419dataMessage packet PAGEREF section_decab65113304ce9bac596d19310cb4011EExamples - overview PAGEREF section_7183553c9554415f8a61d39d4f21e2b125FFields - vendor-extensible PAGEREF section_a4786eef822b4d22ac70af5d12bd36019GGlossary PAGEREF section_da36c55efe404ed7b3b057eb0fd03a296HHandshake Message message PAGEREF section_3e77f3acdb7e4c7695de911dd280947b10handshake packet PAGEREF section_3e77f3acdb7e4c7695de911dd280947b10Higher-layer triggered events client application invocation of the .NET NegotiateStream Protocol PAGEREF section_878a827b0d3a4d7a9c6fedf9c2239fb815 request close stream PAGEREF section_e2db728d5dc944c8b50a7c7fdcbab89816 send data PAGEREF section_1d58818e2b774b009ecb9e10882cf36716 server application invocation of the .NET NegotiateStream protocol PAGEREF section_bef3d7be90764b01a114eae52dead96d21 request close stream PAGEREF section_04772a61761a4df5a8f973c8d5faa20622 send data PAGEREF section_5ddc35a432b242de949db0724a194c1521IImplementer - security considerations PAGEREF section_91cad1c560624eb68b3594a1c993e0a730Index of security parameters PAGEREF section_6e31ffcc1547444aac698ca9b199385930Informative references PAGEREF section_d631da667aa14ccaab6911e317f14e477Initialization client PAGEREF section_80354ec9098d429fae9006c47bab22da15 server PAGEREF section_4736c4c617a642b7b0f05f694d0455a121Introduction PAGEREF section_2947689629db4f218311d7f1e492aac16LLocal events client PAGEREF section_8b55a18369dc4b5989cd76048d1b67d618 server PAGEREF section_31ddfae286b24fdcbeee38f80b95546124MMessage processing client GSS_Init_sec_context returns CreatingSecurityToken state PAGEREF section_8da4cc5b790f4af38ab13a26ccc01ea216 ProcessingFinalToken state PAGEREF section_cc2263e63ab74d2693fa07f469f5869717 receiving data Authenticated state PAGEREF section_1d53294af31a4773ad9df44fa5cd42ac18 WaitingForHandshakeDone state PAGEREF section_dce7597ad3864645aa15f0c774b5216518 WaitingForHandshakeMessage state PAGEREF section_fed5e9722dcf409dbfe96b939c83bc2017 server GSS_Accept_sec_context returns CreatingSecurityToken state PAGEREF section_aee004b96be54c938cee38389d6f38d522 ProcessingFinalToken state PAGEREF section_9a31b357d66249b0967d3f9372b52b8623 receiving data Authenticated state PAGEREF section_9f62f20e38fd45c3930d90a6fd71628023 WaitingForHandshakeMessage state PAGEREF section_4cfbae1dda66420e9943d20762d7616122Messages Data Message PAGEREF section_decab65113304ce9bac596d19310cb4011 Handshake Message PAGEREF section_3e77f3acdb7e4c7695de911dd280947b10 syntax PAGEREF section_d58a9c680bb94b29968622d2ca455a8a10 transport PAGEREF section_4be2e0d0401d41aa90385e13a4f82bf710NNormative references PAGEREF section_ba79a6345e904868814bc25ba46f6f016OOther local events client PAGEREF section_8b55a18369dc4b5989cd76048d1b67d618 server PAGEREF section_31ddfae286b24fdcbeee38f80b95546124Overview (synopsis) PAGEREF section_aaa2adb834a0461c941efca1319c5a507PParameters - security index PAGEREF section_6e31ffcc1547444aac698ca9b199385930Preconditions PAGEREF section_d2ab8403f905469390b6ced94b3b88a58Prerequisites PAGEREF section_d2ab8403f905469390b6ced94b3b88a58Product behavior PAGEREF section_84968810bf274caa9c8233f28e5d15b131RReferences PAGEREF section_e6b24db050f146f48ec14ecbc3ef7e956 informative PAGEREF section_d631da667aa14ccaab6911e317f14e477 normative PAGEREF section_ba79a6345e904868814bc25ba46f6f016Relationship to other protocols PAGEREF section_67609b418d5a4c9392e5f62054b0c4b78SSecurity implementer considerations PAGEREF section_91cad1c560624eb68b3594a1c993e0a730 parameter index PAGEREF section_6e31ffcc1547444aac698ca9b199385930Sequencing rules client GSS_Init_sec_context returns CreatingSecurityToken state PAGEREF section_8da4cc5b790f4af38ab13a26ccc01ea216 ProcessingFinalToken state PAGEREF section_cc2263e63ab74d2693fa07f469f5869717 receiving data Authenticated state PAGEREF section_1d53294af31a4773ad9df44fa5cd42ac18 WaitingForHandshakeDone state PAGEREF section_dce7597ad3864645aa15f0c774b5216518 WaitingForHandshakeMessage state PAGEREF section_fed5e9722dcf409dbfe96b939c83bc2017 server GSS_Accept_sec_context returns CreatingSecurityToken state PAGEREF section_aee004b96be54c938cee38389d6f38d522 ProcessingFinalToken state PAGEREF section_9a31b357d66249b0967d3f9372b52b8623 receiving data Authenticated state PAGEREF section_9f62f20e38fd45c3930d90a6fd71628023 WaitingForHandshakeMessage state PAGEREF section_4cfbae1dda66420e9943d20762d7616122Server abstract data model PAGEREF section_7b54d193e09841589332d646461f42da19 channel binding - expected PAGEREF section_543dce59ee844f898bbd837c26225d7a21 framing buffer PAGEREF section_788a92296b4e4455bcd088afeccaae2221 impersonation level negotiated PAGEREF section_88fc665394fc49c5bf57aba05eb87d5320 required PAGEREF section_74129f04c7934b449fad927437d1685220 overview PAGEREF section_7b54d193e09841589332d646461f42da19 protection level negotiated PAGEREF section_3aa83827ca144e778b9c0354f15c9ea620 required PAGEREF section_dd9f9e34b5304ad5a7f6bad235ba1e5420 security provider context PAGEREF section_435a976887e14acaa396457babd99e8421 server credentials PAGEREF section_9c1ebe98ac284d15a395f2eb295a495220 Stream state PAGEREF section_f924797155bd415e817d606eb640f64d20 TCP connection - underlying PAGEREF section_e4c6c88dfa0c4fe4b7f06ba07c05089419 higher-layer triggered events application invocation of the .NET NegotiateStream protocol PAGEREF section_bef3d7be90764b01a114eae52dead96d21 request close stream PAGEREF section_04772a61761a4df5a8f973c8d5faa20622 send data PAGEREF section_5ddc35a432b242de949db0724a194c1521 initialization PAGEREF section_4736c4c617a642b7b0f05f694d0455a121 local events PAGEREF section_31ddfae286b24fdcbeee38f80b95546124 message processing GSS_Accept_sec_context returns CreatingSecurityToken state PAGEREF section_aee004b96be54c938cee38389d6f38d522 ProcessingFinalToken state PAGEREF section_9a31b357d66249b0967d3f9372b52b8623 receiving data Authenticated state PAGEREF section_9f62f20e38fd45c3930d90a6fd71628023 WaitingForHandshakeMessage state PAGEREF section_4cfbae1dda66420e9943d20762d7616122 other local events PAGEREF section_31ddfae286b24fdcbeee38f80b95546124 overview PAGEREF section_ec57b187d10d4387a07bdc03a7bffd9e19 sequencing rules GSS_Accept_sec_context returns CreatingSecurityToken state PAGEREF section_aee004b96be54c938cee38389d6f38d522 ProcessingFinalToken state PAGEREF section_9a31b357d66249b0967d3f9372b52b8623 receiving data Authenticated state PAGEREF section_9f62f20e38fd45c3930d90a6fd71628023 WaitingForHandshakeMessage state PAGEREF section_4cfbae1dda66420e9943d20762d7616122 timer events PAGEREF section_6f4ae3dfd7454414b180fd2f66f0df0e24 timers PAGEREF section_ae538351bef94c4e807283ee3fda6ce421Standards assignments PAGEREF section_d63b6f0d2e3043828983321cacf8b3b09Syntax PAGEREF section_d58a9c680bb94b29968622d2ca455a8a10TTimer events client PAGEREF section_52c5bdd589e64b5493f3b0c19f6948a618 server PAGEREF section_6f4ae3dfd7454414b180fd2f66f0df0e24Timers client PAGEREF section_a6e20a4e87e747eab2fd0c6706b7f0ee15 server PAGEREF section_ae538351bef94c4e807283ee3fda6ce421Tracking changes PAGEREF section_a84afeb9f5a341459c344d4c5d6b532032Transport PAGEREF section_4be2e0d0401d41aa90385e13a4f82bf710Triggered events - higher-layer client application invocation of the .NET NegotiateStream Protocol PAGEREF section_878a827b0d3a4d7a9c6fedf9c2239fb815 request close stream PAGEREF section_e2db728d5dc944c8b50a7c7fdcbab89816 send data PAGEREF section_1d58818e2b774b009ecb9e10882cf36716 server application invocation of the .NET NegotiateStream protocol PAGEREF section_bef3d7be90764b01a114eae52dead96d21 request close stream PAGEREF section_04772a61761a4df5a8f973c8d5faa20622 send data PAGEREF section_5ddc35a432b242de949db0724a194c1521VVendor-extensible fields PAGEREF section_a4786eef822b4d22ac70af5d12bd36019Versioning PAGEREF section_61a57bfa5d8a4a89b7a4412ac74b82928 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download