MS-RPCE along with PKT_PRIVACY returning SEC_E_MESSAGE_ALTERED

Question

I have an RPC question that deals with SSPI. I have written a RPC library for .Net in c#. Everything works pretty well except when the PDU is set with PKT_PRIVACY. This means the stub data is encrypted, and the auth_value is the sec token(I'm guessing) to pass into SSPI's DecryptMessage along with the encrypted stub data. But everytime I call DecryptMessage it returns back with the status SEC_E_MESSAGE_ALTERED. If I pass anything else as the sec token it returns SEC_E_INVALID_TOKEN, so I'm pretty positive I have the token correct. I'm guessing the stub data is incorrect or something.

Anyone think they could shed some light on what I am doing wrong? Or what part of the PDU I am supposed to pass into DecryptMessage.

Answer 1

Hello John W C,

  Thanks for your question.   We will look into this issue and one of our team member will get back to you.

Thanks
John Dunning
Senior Escalation Engineer Microsoft Corporation US-CSS DSC PROTOCOL TEAM

Answer 2

Thank you

Answer 3

Hi John,

 

This forum provides support for documentation and interoperability questions on open specifications.
The Open Protocol Specifications can be found at: http://msdn2.microsoft.com/en-us/library/cc203350.aspx.
Your post does not appear to be related to the Open Protocols Specifications documentation set but rather to the usage of the DecryptMessage API.

 

This is the SSPI information on MSDN: http://msdn.microsoft.com/en-us/library/aa380535(VS.85).aspx

This is the explanation regarding DecryptMessage(): http://msdn.microsoft.com/en-us/library/aa375211(VS.85).aspx

This are the forums where you can post questions regarding C# and Windows security development:

 

http://social.msdn.microsoft.com/Forums/en-US/category/windev

http://social.msdn.microsoft.com/Forums/en-US/category/visualcsharp

 

 

However, since you've mentioned that you were looking at [MS-RPCE], I must tell you that Netlogon remote calls are handled by [MS-NRPC].

 

This document explains the remote calls in detail and section 3.3.4.2.2 explains some possible reasons why the server might be responding with SEC_E_MESSAGE_ALTERED.

 

I'm pasting the section below, but for better understanding of the protocol, I suggest you read the full document that you can find here: http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-NRPC%5D.pdf

 

Please let me know if I can be of further asisstance.

 

Thanks!

 

 

3.3.4.2.2 Receiving an Initial Netlogon Signature Token

When a server receives encrypted data, it verifies the Netlogon Signature token. If AES is negotiated, a server receives an NL_AUTH_SHA2_SIGNATURE structure, otherwise it receives a NL_AUTH_SIGNATURE structure. The following steps are performed to verify the data and to decrypt with AES if negotiated, otherwise RC4 if required:

1. The SignatureAlgorithm bytes MUST be verified to ensure that, if AES is negotiated, the first byte is set to 0x13 otherwise the first byte is set to 0x77, and that the second byte is set to 0x00. If either of these two are incorrect, an SEC_E_MESSAGE_ALTERED (0x8009030F) MUST be returned.

2. If the Confidentiality option is requested from the application, then the SealAlgorithm MUST be verified to ensure that if AES is negotiated, the first byte is set to 0x1A otherwise the first byte is set to 0x7A, and the second byte set to 0x00.

If the Confidentiality option is not requested, then the SealAlgorithm MUST be verified to contain all 0xff bytes.

3. The Pad MUST be verified to contain all 0xff bytes.

4. The Flags data MAY be<91> disregarded.

5. The SequenceNumber MUST be decrypted using an initialization vector constructed by concatenating twice the sequence number (thus getting 16 bytes of data). The RC4 key MUST be derived as follows.

SET zeroes to 4 bytes of 0

CALL hmac_md5(zeroes, [4 bytes], SessionKey, size of SessionKey, TmpData)

CALL hmac_md5(Checksum, size of Checksum, TmpData, size of TmpData,

DecryptionKey)

6. A local copy of SequenceNumber MUST be computed using the following algorithm.

Assume byte(n, l) returns byte n of the 32-bit number l. The n

parameter is limited to 0..3. The least significant byte is 0,

the most significant byte is 3.

SET CopySeqNumber[0] to byte(3, ServerSequenceNumber.LowPart)

SET CopySeqNumber[1] to byte(2, ServerSequenceNumber.LowPart)

SET CopySeqNumber[2] to byte(1, ServerSequenceNumber.LowPart)

SET CopySeqNumber[3] to byte(0, ServerSequenceNumber.LowPart)

SET CopySeqNumber[4] to byte(3, ServerSequenceNumber.HighPart)

SET CopySeqNumber[5] to byte(2, ServerSequenceNumber.HighPart)

SET CopySeqNumber[6] to byte(1, ServerSequenceNumber.HighPart)

SET CopySeqNumber[7] to byte(0, ServerSequenceNumber.HighPart)

Set CopySeqNumber[4] to CopySeqNumber[4] OR 0x80

7. The SequenceNumber MUST be compared to CopySeqNumber. If these two do not match, an error is returned indicating that out-of-sequence data was received.

8. ServerSequenceNumber MUST be incremented.

9. If the Confidentiality option is requested, the Confounder and the data MUST be decrypted. 113 / 260 [MS-NRPC] — v20090924 Netlogon Remote Protocol Specification Copyright © 2009 Microsoft Corporation. Release: Thursday, September 24, 2009

The AES key used MUST be derived using the following algorithm:

FOR (I=0; I < Key Length; I++)

EncryptionKey [I] = SessionKey[I] XOR 0xf0

If AES is negotiated, decrypt using an initialization vector constructed by concatenating twice the sequence number (thus getting 16 bytes of data).

The RC4 key used MUST be derived using the following algorithm:

SET zeroes to 4 bytes of 0

FOR (I=0; I < Key Length; I++)

XorKey [I] = SessionKey[I] XOR 0xf0

CALL hmac_md5(zeroes, [4 bytes], XorKey, size of XorKey, TmpData)

CALL hmac_md5(CopySeqNumber, size of CopySeqNumber, TmpData,

size of TmpData, EncryptionKey)

The hmac_md5 function is specified in [RFC2104]

10.If AES is negotiated, then a signature MUST be computed using the following algorithm:

CALL SHA256Reset(&HashContext, Sk, sizeof(Sk));

CALL SHA256Input(HashContext, NL_AUTH_SHA2_SIGNATURE, [8 bytes]);

IF Confidentiality requested

CALL SHA256Input(HashContext, Confounder, [8 bytes]);

CALL SHA256FinalBits(HashContext, Message, size of Message;

CALL SHA256Result(HashContext, output);

SET Signature to output

Note: In the first call to SHA256Input only the first 8-bytes

of the NL_AUTH_SHA2_SIGNATURE structure are used.

Else a signature MUST be computed using the following algorithm:

SET zeroes to 4 bytes of 0

CALL MD5Init(md5context)

CALL MD5Update(md5context, zeroes, [4 bytes])

CALL MD5Update(md5context, NL_AUTH_SIGNATURE, [8 bytes])

IF Confidentiality requested

CALL MD5Update(md5context, Confounder, [8 bytes])

CALL MD5Update(md5context, Message, size of Message)

CALL MD5Final(md5context)

CALL HMAC_MD5(md5context.digest, md5context.digest length,

Session Key, size of Session Key, output)

SET Signature to output

Note: In the second call to MD5Update only the first 8-bytes

of the NL_AUTH_SIGNATURE structure are used. 114 / 260 [MS-NRPC] — v20090924 Netlogon Remote Protocol Specification Copyright © 2009 Microsoft Corporation. Release: Thursday, September 24, 2009

11.The first 8 bytes of the computed signature MUST be compared to the checksum. If these two do not match, the server MUST return an SEC_E_MESSAGE_ALTERED (0x8009030F) indicating that the message was altered.

---

SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team

Answer 4

Sebastian, this is not a question about NetLogon, this is a direct question pertaining to the MS-RPCE protocol that has NTLMSSP PKT_PRIVACY set.

The stub data is encrypted for the Request PDU, when I try to decrypt it with the SSPI function DecryptMessage I get the SEC_E_MESSAGE_ALTERED error. As I mentioned, I am the RPC server endpoint, not windows, not netlogon.

I can go from Bind to replying with Bind_Ack to successfully verifying the AUTH3 PDU. All of those PDUs have the NTLM request/challenge/response security tokens and get called with the AcceptSecurityContext SSPI function; it's the very first Request PDU that I get the SEC_E_MESSAGE_ALTERED error.

A scenario to help out:
Receive Bind PDU: Call SSPI's AcquireCredentialsHandle() for server handle, then call SSPI's AcceptSecurityContext() with auth_info.auth_value from the Bind PDU passed in as security token.
Send Bind_Ack PDU:  auth_info.auth_value returned = output from SSPI's AcceptSecurityContext().
Receive AUTH3 PDU: Call SSPI's AcceptSecurityContext() to verify challenge response, get SEC_E_OK (All is well)
Receive Request PDU: Call SSPI's DecryptMessage() passing in auth_info.auth_value as security token and all of stub data as encrypted data, returns SEC_E_MESSAGE_ALTERED.

I believe the sec token is correct, as if I set it to anything else than auth_value it returns SEC_E_INVALID_TOKEN. My only guess is that one of the other parameters is incorrect or something is up with the stub data, is it padded, etc...

This is the DecryptMessage call with the parameters I am using.
DecryptMessage(ref DecryptionContext, ref DescBuffer, 0, out EncryptionQuality)
DecryptionContext = servers context handle from AcquireCredentialsHandle()
DescBuffer = SecBufferDesc struct with sec token and encrypted data

Any clue as what I am doing wrong?

Answer 5

Anyone?

Answer 6

Hi John,

 

The SEC_E_MESSAGE_ALTERED means: “The message or signature supplied for verification has been altered”.

 

With that being said, either your signature calculation AND/OR your encryption and decryption functions could be experiencing the issue.

 

If this information does not help you resolving the issue, I will need an specific section and text on the MS-RPCE document where you believe the document may need corrections or clarifications.

 

Please note that these forums are intended to address questions regarding Microsoft Open specifications documentation and related inter-operability issues. 

Thanks and regards,

 

Sebastian

 

 

 

 

MS-RPCE section 3.3.1.5.2.2 provides the following info (the areas highlighted are the ones I believe you could be having issues with):

 

3.3.1.5.2.2   Using a Security Context

After a security context is built, the security context can be used by the RPC runtime and higher-level protocols to perform authorization decisions. Besides using the security context for authorization decisions, the RPC runtime can also use the security context to create a logical stream of data that is protected from tampering and information disclosure on the network.

The amount of protection applied depends on the authentication level for the security context requested by the client when the security context is created. The authentication level is applied in two dimensions:

§ In the first dimension, it controls what capabilities the RPC runtime MUST request from the security provider when the security context is being built, as detailed in the first table that follows. It is possible for a security provider to not be able to provide a certain capability. In this case, the lack of the capability MUST be considered by the RPC runtime as equivalent to the security provider returning an error and MUST be handled as specified in the previous section.

§ In the second dimension, the authentication level controls how the security provider runtime MUST perform PDU protection on the different PDU segments using the security context, as detailed in the second table that follows.

The following table specifies the abstract capability that the RPC runtime MUST request from the security provider when the security context is being created. The capabilities in the following table are further specified in [RFC2743] section 1.2.1.2. The capabilities requested at each level include the ones requested at the previous level.

Authentication level	Capability requested
RPC_C_AUTHN_LEVEL_CONNECT	None
RPC_C_AUTHN_LEVEL_PKT	Replay Detect
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY	Sequence Detect, integrity
RPC_C_AUTHN_LEVEL_PKT_PRIVACY	Confidentiality

As specified earlier, once the security context is built, the RPC runtime MUST also use the authentication level to control how the security context is used to protect request and response PDUs sent to the other side.

One of the first decisions that needs to be negotiated is whether the security provider on each side supports what this specification calls header signing. Header signing is an operation in which a security provider can provide integrity protection to a segment of the PDU such that the integrity protection does not modify the content of that segment. The segments of the PDU are specified in section 2.2.2.1. The RPC runtime on the client determines in an implementation-specific way if the security provider on the client supports header signing. If it does, the first bind or alter_context PDU that the client sends on a connection that carries authentication information and whose authentication level is integrity or higher MUST have its PFC_SUPPORT_HEADER_SIGN bit set. The RPC runtime on the server also determines in an implementation-specific way whether the security provider on the server supports header signing, and, if it does not, it MUST respond to the client with a PDU whose PFC_SUPPORT_HEADER_SIGN bit is cleared. If it does support header signing, it MUST respond to the client with a PDU whose PFC_SUPPORT_HEADER_SIGN bit is set.

Using this mechanism, the client and server agree if header signing should be done for this connection. Once agreed, the client and server apply protection to request and response PDUs in the same way.

If the client and server support header signing, the party that sends the PDU asks the security provider to apply the following protection to the different PDU segments.

Authentication level	PDU header	PDU body	sec_trailer
RPC_C_AUTHN_LEVEL_CONNECT	None	None	None
RPC_C_AUTHN_LEVEL_PKT	None	None	None
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY	Integrity	Integrity	Integrity
RPC_C_AUTHN_LEVEL_PKT_PRIVACY	Integrity	Confidentiality	Integrity

If either the client or server does not support header signing, the RPC runtime on the sending side asks the security provider to apply the following protection to the different PDU segments.

Authentication level	PDU header	PDU body	sec_trailer
RPC_C_AUTHN_LEVEL_CONNECT	None	None	None
RPC_C_AUTHN_LEVEL_CALL	None	None	None
RPC_C_AUTHN_LEVEL_PKT	None	None	None
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY	None	Integrity	None
RPC_C_AUTHN_LEVEL_PKT_PRIVACY	None	Confidentiality	None

In the preceding tables, "None" means no protection, "Integrity" means an integrity check per [RFC2743] section 2.3.1 MUST be applied, and "Confidentiality" means that the segment MUST be encrypted.

The PDU header, PDU body, and sec_trailer MUST be passed in the input message, in this order, to GSS_WrapEx, GSS_UnwrapEx, GSS_GetMICEx, and GSS_VerifyMICEx. For integrity protection the sign flag for that PDU segment MUST be set to TRUE, else it MUST be set to FALSE. For confidentiality protection, the conf_req_state flag for that PDU segment MUST be set to TRUE, else it MUST be set to FALSE.

The PDU header, PDU body, and sec_trailer from the output message of GSS_WrapEx and GSS_VerifyMICEx MUST be sent to the other side (client or server) as part of the request or response PDU, and the signature output MUST be sent to the other side (client or server) as the authentication token as specified in section 2.2.2.12.

If the authentication level is RPC_C_AUTHN_LEVEL_PKT_PRIVACY, the PDU body will be encrypted. The PDU body from the output message of GSS_UnwrapEx represents the plain text version of the PDU body. The PDU header and sec_trailer output from the output message SHOULD be ignored. Similarly the signature output SHOULD be ignored.

For further details on GSS_WrapEx, see [MS-NLMP] section 3.4.6 and [MS-KILE] section 3.4.5.4.

For details on GSS_UnwrapEx, see [MS-NLMP] section 3.4.7 and [MS-KILE] section 3.4.5.5.

For further details on GSS_GetMICEx, see [MS-NLMP] section 3.4.8 and [MS-KILE] section 3.4.5.6.

For further details on GSS_VerifyMICEx, see [MS-NLMP] section 3.4.9 and [MS-KILE] section 3.4.5.7.

If the authentication level is connect, the security provider MUST use for request and response PDUs an authentication token that is optional and that does not need to be transmitted to the other side.

This protocol does not specify whether the authentication token itself is protected from tampering by the security provider. It also does not specify how the security provider applies integrity or confidentiality protection to a PDU segment. The algorithms for doing so are specific to the security provider. For details about a security provider, see the documentation for that security provider

 

 

 

 

The above mentioned section of MS-NLMP reads as follows:

 

3.4.6.1   Signature Creation for GSS_WrapEx()

Section 3.4.3 describes the algorithm used by GSS_WrapEx() to create the signature. The signature contains the NTLMSSP_MESSAGE_SIGNATURE structure (section 2.2.2.9).

The checksum is computed over the concatenated input buffers using only the input data buffers where sign==TRUE for NTLMv1 and all of the input data buffers for NTLMv2, including the cleartext data buffers.

    3.4.3   Message Confidentiality

Message confidentiality, if it is negotiated, also implies message integrity. If message confidentiality is negotiated, a sealed (and implicitly signed) message is sent instead of a signed or unsigned message. The function that seals a message using the signing key, sealing key, and message sequence number is as follows:

-- Input:

--   SigningKey - The key used to sign the message.

--   Message - The message to be sealed, as provided to the application.

--   NegFlg, SeqNum - Defined in section 3.1.1.

--   Handle - The handle to a key state structure corresponding to the

--   current state of the SealingKey

--

-- Output:

--   Sealed message – The encrypted message

--   Signature – The checksum of the Sealed message

--

--   Functions used:

 

--   RC4() - Defined in Section 6 and 3.1.

--   MAC() - Defined in Section 3.4.4.1 and 3.4.4.2.

 

 

 

 

   Define SEAL(Handle, SigningKey, SeqNum, Message) as

     Set Sealed message to RC4(Handle, Message)

     Set Signature to MAC(Handle, SigningKey, SeqNum, Message)

     EndDefine

 

 

Message confidentiality is available in connectionless mode only if the client configures extended session security.

 

 

3.4.7   GSS_UnwrapEx() Call

This call is an extension to GSS_Unwrap [RFC2743] that passes multiple buffers. The Microsoft implementation of GSS_WrapEx() is called DecryptMessage(). For more information, see [MSDN-DecryptMsg].

Inputs:

§ context_handle CONTEXT HANDLE

§ input_message ORDERED LIST of:

§ conf_state BOOLEAN

§ signed BOOLEAN

§ data OCTET STRING

§ signature OCTET STRING

Outputs:

§ qop_req INTEGER, -- 0 specifies default QOP

§ major_status INTEGER

§ minor_status INTEGER

§ output_message ORDERED LIST (in same order as input_message) of:

§ conf_state BOOLEAN

§ data OCTET STRING

This call is identical to GSS_Unwrap, except that it supports multiple input buffers. Input data buffers having conf_state==TRUE are decrypted in the output_message. For NTLMv1, all input data buffers where signed==TRUE are concatenated together and the signature is verified against the resulting concatenated buffer. For NTLMv2, the signature is verified for all of the input data buffers.

 

---

SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team

Answer 7

 Ok, so from what I gather from all of that, is this.

I receive a Request PDU that has PKT_PRIVACY set, but no header signing enabled.
From the table above I should follow this, RPC_C_AUTHN_LEVEL_PKT_PRIVACY: Header=None, Body=Confidentiality, sec_trailer=None.

PDU Request packet layout:
 Header: 24 bytes (frag_len=176, auth_len=16, alloc_hint=120, etc...)
 Stub data: 128 bytes (120 bytes of data + 8 bytes of auth padding)
 sec_trailer: 8 bytes
 sec_trailer.auth_value: 16 bytes

So with that said, using GSS_UnWrapEx() I should create a ordered list in the exact order as follows for the input message.
[0] {conf_state=false, signed=false, data=header data (24 bytes) }
[1] {conf_state=true,  signed=true,  data=body data (128 bytes) }
[2] {conf_state=false, signed=false, data=sec_trailer data (8 bytes) }

With all that, plus the other required parameters, passed into GSS_UnWrapEx() I should get back a decrypted body and SEC_OK status, correct? Do I have it correct so far?

Now, if that is correct how do I do the same thing with DecryptMessage(), as the documents state that Microsoft's implementation for GSS_UnWrapEx() is DecryptMessage(). I can't understand or see how I am supposed to set the conf_state or signed settings per buffer item within the SecBuffer struct?

Question: If Microsoft's implementation to GSS_UnWrapEx() is DecryptMessage(), why does all the documentation always talk about GSS_UnWrapEx() or the other GSS_??? methods instead of the SSPI methods? Are there future plans to move to the GSS API over the current SSPI API?

Thanks for everything you are doing, I really appreciate it.
John

Answer 8

Any help Sebastian?

John

Answer 9

Hi John,

 

I am glad that you found the information that I have provided useful.

 

For what I understand from your message, you are having some implementation decisions to make and unfortunately I cannot help you directly with that.

 

As I have sated before, if you have any questions or concerns regarding a specific section or paragraph in any of our documents, we can and certainly will be working with you towards checking and validating the accuracy of the information. However based on my understanding, your question would have better fit in the developer’s forums.

 

I truly think that posting into one of the following forums, will give you a better result than our Protocol Documentation forums:

 

.NET Framework Networking and Communication

http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/threads

 

Windows Communication Foundation

http://social.msdn.microsoft.com/Forums/en-US/wcf/threads

 

Common Language Runtime

 http://social.msdn.microsoft.com/Forums/en-US/clr/threads

 

 

Please let me know if I can be of further assist or if I have misinterpreted you.

 

Thanks and regards,

---

SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team

Answer 10

Your protocol documentation does not make it very clear on how to Decrypt the RPC body. You don't give enough information about using what y'all designed, DecryptMessage(), y'all only give information about the GSS_UnWrapEx() method, which from what I can find I can't call. I can only call the SSPI's DecryptMessage().

PLEASE help me understand how the protocol specs are designed around calling DecryptMessage(). Nothing to do about my own implementation decision, I'm trying to follow your design specs implementation.

John

Answer 11

The bottom line question that I can't seem to get clearly answered is this. With a Request PDU packet, what bytes of the PDU am I supposed to use when forming the SecBuffer structures to form a SecBufferDesc to call DecryptMessage()? And in what format is each SecBuffer supposed to be? I have tried every way that I could possibly think, they all return SEC_E_MESSAGE_ALTERED.

I'm not sure if asking this question would get anywhere with those forums you posted, as the question relates more towards MS-RPCE protocol. Any one that I ask would have to understand the MS-RPCE protocol.

I will give a sample Request PDU that maybe someone can pin point what out of it is placed where in the SecBuffer structures to send to DecryptMessage() to return with SEC_E_OK. Or point me to someone that will know?

PDU Request packet layout:

Header (24 bytes)
	ver: 5
	ver_minor: 0
	type: 0
	flags: 0x03 (First, Last)
	drep: 0x10000000
	frag_len: 176
	auth_len: 16
	call_id: 1
	alloc_hint: 120
	context_id: 0
	opnum: 0
 Stub data: 128 bytes (120 bytes of data + 8 bytes of auth padding)
 sec_trailer (8 bytes)
	auth_type: 10 (NTLMSSP)
	auth_level: 6 (PKT_PRIVACY)
	auth_pad_len: 8
	auth_rsrvd: 0
	auth_context_id: 1492848
 sec_trailer.auth_value: 16 bytes

 

Answer 12

Hi John,

 

Please remember that MS-RPCE covers the differences between our implementation and the DCE C706 specification (http://www.opengroup.org/pubs/catalog/c706.htm)

The information on MS-RPCE seems to be complete since it clearly states (I have pasted most of this section on a previous response to this thread) that the PDU Body is the one encrypted (in your case, this is the body of your PDU -  Stub data: 128 bytes (120 bytes of data + 8 bytes of auth padding):

 

"If the authentication level is RPC_C_AUTHN_LEVEL_PKT_PRIVACY, the PDU body will be encrypted. The PDU body from the output message of GSS_UnwrapEx represents the plain text version of the PDU body. The PDU header and sec_trailer output from the output message SHOULD be ignored. Similarly the signature output SHOULD be ignored."

 

 Also, the graph onsection 2.2.2.1 shows how a PDU is comprised.

  

The DecryptMessage API is explained in detail here: http://msdn.microsoft.com/en-us/library/aa375211(VS.85).aspx

 

If you believe this information is not accurate, please indicate what sections present the inaccuracy and I will gladly revise that.

 

Please let me know if I can be of further assistance.

 

Thanks,

---

SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team

Answer 13

Any help Sebastian?

John

Answer 14

Ok, i'm following all the protocols specs to the T, I just don't understand why I am getting the error from DecryptMessage()

Answer 15

Sebastian, what other forums that are related to SSPI do you think I should submit my question too?

John

Answer 16

Hi John,

The following forum seems to me like the most accurate:

.NET Framework Networking and Communication http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/threads


However, I want you to know that we are absolutely committed to improve our documentation in an ongoing basis.

Should you find any inaccuracies, missing information or clarity issues, please let us know so we can work together in fixing the errors.

Thanks and regards,

---

SEBASTIAN CANEVARI - MSFT Senior SEE Protocol Documentation Team