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

[Obaid Farooqi]

Hi Simo:
Please find the answers to your questions in Q&A form as follows:

Q. 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 first 4 bytes with a random value/random_pad or 0.
None of them XOR the Sequence Number.

A. In the open source implementations, the XORing of SeqNum is implicit. In the document(MS-NLMP), we RC4 encrypt 0x00000000 and then XOR with SeqNum which has the same effect as RC4 encrypting SeqNum because you get RC4 cipher stream when you encrypt 0x00000000.

As for the RandomPad, for signing, it just doesn’t matter so you can put anything there. For verification, windows just copies the RandomPad from the input messages so it verifies correctly.

Q. 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).

A. The document in section 3.4.4.1 mentions that:
“Handle - The handle to a key state structure corresponding to the current state of the SealingKey”
Please note that even for signing, sealing key is used for encryption. 

In section 3.1.5.1, it is stated that:
“….The key for RC4 is established at the start of the session for an instance of RC4 dedicated to that session. RC4 then continues to generate key stream in order over all messages of the session, without rekeying.”

So, the RC4 is initialized with sealing key at the start of a session and is not rekeyed again. Keeping this is mind, please look at the example in section 4.2.2.4. Using the session key (0x55555555555555555555555555555555, provided in the document ) as sealkeay, I was able to get the results in example in section 4.2.2.4. Please let me know if you need a detailed step-by-step calculation of signature in section 4.2.2.4 and I’ll be happy to provide that.


Q. 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.
A. The nonce is actually SeqNum. I’ll file a suggestion against the document to fix this confusion.

Q. 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. 
A. I’ll file a suggestion to include that in the document. Using the result calculated in example in section 4.2.2.4, here is the signature that will result from section 4.2.2.4:
01 00 00 00  45 c8 44 e5  09 dc d1 df 2e 45 9d 36

As I mentioned, randomPad is not important and you can put anything there, so the signature above is same as

01 00 00 00  xx xx xx xx  09 dc d1 df 2e 45 9d 36 

where xx can be any byte value. 

Q. 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 ?
A. Based on the above answers, the algorithm in 3.4.3 should be clear but if not, please let me know any specific question you have about 3.4.3. One thing missing from 3.4.3 is the final step of concatenation of the sealed message and signature in one piece. After concatenation, the final output from section 4.2.2.4 example would be 


56 fe 04 d8 61 f9 31 9a f0 d7 23 8a 2e 3b 4d 45 7f b8 01 00 00 00  45 c8 44 e5  09 dc d1 df 2e 45 9d 36

I’ll file a document bug to add the concatenation in the algorithm in section 3.4.3.

Please let me know if it does not answer your question.

Regards,
Obaid Farooqi
Escalation Engineer | Microsoft

Exceeding your expectations is my highest priority.  If you would like to provide feedback on your case you may contact my manager at nkang at Microsoft dot com

-----Original Message-----
From: Edgar Olougouna 
Sent: Saturday, October 19, 2013 10:56 PM
To: idra at samba.org
Cc: cifs-protocol; MSSolve Case Email
Subject: [REG:113102010876826] MS-NLMP and V1 Signatuers without Extended Session Security

[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.