[cifs-protocol] 118120419417044 [MS-NNS]: Active Directory Web Services violating documented payload size limit

Edgar Olougouna edgaro at microsoft.com
Fri Dec 7 20:53:44 UTC 2018


Garming,
Your observation is correct. I have filed a document bug and asked an update to the PayloadSize defined in [MS-NNS]. The definition should be clarified to reflect the size transmitted on the wire. 
For instance, when we call GSS_Wrap, the encrypted output will be prepended with the GSS token (e.g. see RFC4757 Section 7.3). 
The 0xFC00 is the size limit before calling GSS services. Before we come up with a proper document update, I suggest you can proceed in your implementation with the following:
*	Sender: Set the maximum write size of the buffer to send to 63KB before GSS protection (Sign/SignAndEncrypt). The PayloadSize transmitted on the wire will be longer due to GSS token. 
*	Receiver: Use a maximum read size of payload to be 64K. PayloadSize cannot be greater than 0x10000, even if in practice it would be slightly smaller. 

https://www.ietf.org/rfc/rfc4757.txt
7.2. GSS-API MIC Semantics
struct Token { struct Header { OCTET TOK_ID[2]; OCTET SGN_ALG[2]; OCTET Filler[4]; }; OCTET SND_SEQ[8]; OCTET SGN_CKSUM[8]; } Token;
7.3. GSS-API WRAP Semantics
struct Token { // 32 octets struct Header { OCTET TOK_ID[2]; OCTET SGN_ALG[2]; OCTET SEAL_ALG[2]; OCTET Filler[2]; }; OCTET SND_SEQ[8]; OCTET SGN_CKSUM[8]; OCTET Confounder[8]; } Token;
// Encrypted message = Token + Data

Thanks,
Edgar

-----Original Message-----
From: Edgar Olougouna 
Sent: Tuesday, December 4, 2018 11:04 PM
To: Garming Sam <garming at catalyst.net.nz>
Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
Subject: RE: 118120419417044 [MS-NNS]: Active Directory Web Services violating documented payload size limit

Garming,
I will look into this for you as well.

Thanks,
Edgar

-----Original Message-----
From: Sreekanth Nadendla <srenaden at microsoft.com> 
Sent: Tuesday, December 4, 2018 5:45 PM
To: Garming Sam <garming at catalyst.net.nz>
Cc: cifs-protocol at lists.samba.org
Subject: 118120419417044 [MS-NNS]: Active Directory Web Services violating documented payload size limit

Dochelp in Bcc

Hello Garming Sam,
Thank you for your inquiry about Microsoft Open Specifications. We have created an incident # 118120419417044 for investigating this issue. One of the Open specifications team member will contact you shortly.


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

-----Original Message-----
From: Garming Sam <garming at catalyst.net.nz>
Sent: Tuesday, December 4, 2018 5:28 PM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: [MS-NNS]: Active Directory Web Services violating documented payload size limit

Hi,

When observing traffic sent from the ADWS server, data messages returned via the NegotiateStream protocol has observable payload max sizes of
0x0000FC30 consistently (triggering this is possible by asking for a large search result which must be broken down into multiple data messages).

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fcc236740.aspx&data=02%7C01%7Cedgaro%40microsoft.com%7Cf7f368e61c9e42a24be208d65a4297e3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795639401061966&sdata=bgwrGMVgmninCedXEqQ9lnDeUElOHTxVgnsNvorKnK4%3D&reserved=0

'[MS-NNS]: 2.2.2 Data Message' indicates that the maximum value for this field is 0x0000FC00 (64,512). However, ADWS clearly returns answers which are greater. Noticeably, when this payload is decrypted via GSSAPI, the payload size nearly always goes from 0xFC30 to 0xFC00 (indicating a 0x30 length header). Sometimes the decrypted data is slightly less, but the total payload size always caps at 0xFC30.

>From what I understand, the documentation does not seem to be correct.
The documented payload size seems to be a reference to the unencrypted payload length.

Can this behaviour in regards to encrypted payload lengths be clarified (and documented)?

Cheers,

Garming




More information about the cifs-protocol mailing list