[cifs-protocol] [REG:113102010876826] MS-NLMP and V1 Signatuers without Extended Session Security

[Edgar Olougouna]

[case number in subject]
[casemail to cc]
[dochelp to bcc]

Simo,
The case number 113102010876826 has been created for this inquiry. One of our team members will follow-up soon.

Regards,
Edgar

-----Original Message-----
From: simo [mailto:idra at samba.org] 
Sent: Saturday, October 19, 2013 5:06 PM
To: Interoperability Documentation Help
Cc: cifs-protocol
Subject: MS-NLMP and V1 Signatuers without Extended Session Security

Hello dochelp,
I'd like some clarifications about sections 3.4.4 and 4.2.2.4 of MS-NLMP.

Section 3.4.4 details how to create a signature in the absence of Extended Session Security Negotiation.
The description of the operation is confusing and it seem not in line with 3 different Open Source implementations I have inspected.

In particular the documentation seem to imply the signature is created by RC4 of the concatenation of (Random_Pad, CRC32(Message), 0x00000000) all 4 bytes values, then discarding the first 4 bytes of the resulting ciphertext and replacing them with a 0 (last operation) and discarding the last 4 bytes of the ciphertext and replacing them with the XOR of a Sequence Number, and keeping only the central 4 bytes of the Ciphertext as the Checksum.

The Open Source implementations I inspected instead create the signature by RC4 of the concatenation of (0x00000000, CRC32(Message), SeqNum), some of them replace the fist 4 bytes with a random value/random_pad or 0.
None of them XOR the Sequence Number.


It is unclear to me what implementation is right, and Section 4.2.2.4 where a protocol Example is provided lacks the necessary data for reproducing the test.
In particular the Section does not make clear what Key is used to initialize the RC4 cipher (Later sections 4.2.3.4 and 4.2.4.4 both do).
There is also perhaps a terminology problem. In the paragraph a NONCE (set to zero) is mentioned, I assume this is the RandomPad described in 3.4.3, if so using a consistent terminology would be useful.

Finally 4.2.2.4 does not show the full signature buffer sent back to the peer. Both sections 4.2.3.4 and 4.2.4.4 instead do. 


Could you please clarify the algorithm in 3.4.3, use consistent terminology between 3.4.3 and 4.2.2.4 and provide sufficient data to verify 4.2.2.4 ?

Thanks,
Simo.