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: [email protected] > 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:[email protected]] > 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. > > _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
