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

simo idra at samba.org
Tue Oct 22 09:46:35 MDT 2013


Thanks a lot Obaid,

comments inline.

On Tue, 2013-10-22 at 14:09 +0000, Obaid Farooqi wrote:
> 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.

Ah right, should have thought about that ...

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

Ok.

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

Uhm My unit test does not go through the whole negotiation so I was
looking for the actual key used, and I tried them all except the
'random' session key ... thanks for pointing it out.

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

Thank you, this will certainly help.

> 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

Thank you, this is what I needed.

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

Sure, I will simply set a 'fixed' random pad in my unit test.
I wonder what is the point of this random pad though :)

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

It is clear now, thanks.

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

It answered it fully,
by using 0x555555... all my unit tests now pass too.

Thank you.

Simo.

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





More information about the cifs-protocol mailing list