[cifs-protocol] [REG:113102010876826] MS-NLMP and V1 Signatuers without Extended Session Security
edgaro at microsoft.com
Sat Oct 19 21:56:07 MDT 2013
[case number in subject]
[casemail to cc]
[dochelp to bcc]
The case number 113102010876826 has been created for this inquiry. One of our team members will follow-up soon.
From: simo [mailto:idra at samba.org]
Sent: Saturday, October 19, 2013 5:06 PM
To: Interoperability Documentation Help
Subject: MS-NLMP and V1 Signatuers without Extended Session Security
I'd like some clarifications about sections 3.4.4 and 220.127.116.11 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 18.104.22.168 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 22.214.171.124 and 126.96.36.199 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 188.8.131.52 does not show the full signature buffer sent back to the peer. Both sections 184.108.40.206 and 220.127.116.11 instead do.
Could you please clarify the algorithm in 3.4.3, use consistent terminology between 3.4.3 and 18.104.22.168 and provide sufficient data to verify 22.214.171.124 ?
More information about the cifs-protocol