none
Inconsistent key exchange key in [MS-NLMP] RRS feed

  • Question

  •  
    [MS-NLMP] section 4.2.3 uses NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY, and lists session base key in 4.2.3.1.2 as

    0000000: d8 72 62 b0 cd e4 b1 cb 74 99 be cc cd f1 07 84   .rb.═...t.......
     
    and lists the key exchange key in section 4.2.3.1.3 as

    0000000: eb 93 42 9a 8b d9 52 f8 b8 9c 55 b8 7f 47 5e dc   ..B...R...U..G..

    Section 3.4.5.1 says that “If NTLM v2 session security is negotiated, the key exchange key MUST be the 128-bit session base key.”

    If 3.4.5.1 is correct, should the key exchange key and session base key above be the same?

    Thanks,

    HW

    • Edited by hwang2007 Thursday, October 23, 2008 10:34 PM
    Thursday, October 23, 2008 10:34 PM

Answers

  •  

    Hi,

    We have completed investigation of your questions regarding the use of NTLM extended security flag. As a result, there will be a number of updates to the [MS-NLMP] specification. The changes will be included in a later release of the document.

     

    Request:

    I will highly appreciate if you could provide the signing key, the sealing key and a piece of message in plain text and cipher text in the examples in section 4.2.2 and 4.2.3.

     

    Answer:

    The product group has thoroughly reviewed your request. They will be working on adding sanitized crypto examples in Section 4.2. This will appear in a future release of the document.

     

    Question 1:

    Section 3.4.4.1 has the following pseudo code,

    Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to CRC32(SigningKey, ConcatenationOf(SeqNum, RandomPad, Message))[0..7]

    In this code, CRC32 takes two input arguments. However, section 6 defines CRC32(M), which only takes one input argument.

     

    Answer:

    CRC32() takes only one argument as defined in Section 6.

    The pseudo-code in Section 3.4.4.1 will be updated as follows:

           Define MAC(Handle, SigningKey, SeqNum, Message) as

                Set NTLMSSP_MESSAGE_SIGNATURE.Version to 0x00000001

                Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to CRC32(Message)

                Set NTLMSSP_MESSAGE_SIGNATURE.RandomPad RC4(Handle, RandomPad)

                Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to RC4(Handle,

                    NTLMSSP_MESSAGE_SIGNATURE.Checksum)

                Set NTLMSSP_MESSAGE_SIGNATURE.SeqNum to RC4(Handle, 0x00000000)

                If (connection oriented)

                     Set NTLMSSP_MESSAGE_SIGNATURE.SeqNum to

                         NTLMSSP_MESSAGE_SIGNATURE.SeqNum XOR SeqNum

                     Set SeqNum to SeqNum + 1

                Else

                     Set NTLMSSP_MESSAGE_SIGNATURE.SeqNum to

                         NTLMSSP_MESSAGE_SIGNATURE.SeqNum XOR

                         (application supplied SeqNum)

                Endif

                Set NTLMSSP_MESSAGE_SIGNATURE.RandomPad to 0

           EndDefine

     

    Question 2:

     Section 3.4.3 seals the message in the format of

    ConcatenationOf(RC4(handle, Message), …)

    Based on the network trace, the message seems in the format of ConcatenationOf(…, RC4(handle, Message)).

     

    Answer:

    The pseudo code will be updated as follows:

           -- Input:

           --   SigningKey - The key used to sign the message.

           --   Message - The message provided by the application to be sealed.

           --   NegFlg, SeqNum - Defined in section 3.1.1.

           --   Handle - The handle to a key state structure corresponding to the

           --   current state of the SealingKey

           --

           -- Output:     

           --   Sealed message – encrypted message

           --   Signature – checksum of sealed message

           --

           --   Functions used:

           --   ConcatenationOf() - Defined in Section 6.

           --   RC4() - Defined in Section 6 and 3.1.

           --   MAC() - Defined in Section 3.4.4.1 and 3.4.4.2.

           --   CRC32() - Defined in Section 6.

            

           If (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set in NegFlg)

            

              Define SEAL(Handle, SigningKey, SeqNum, Message) as

                Set Sealed message to RC4(Handle, Message)

                Set Signature to MAC(Handle, SigningKey,SeqNum, Message)

              EndDefine

            

           Else

                

              Define SEAL(Handle, SigningKey, SeqNum, Message) as

                Set Sealed message to RC4(Handle, Message)

                Set Signature to ConcatenationOf(0x00000001,

                RC4(Handle, ConcatenationOf(NONCE(4),

                CRC32(ConcatenationOf(SeqNum, Message)), SeqNum)))

              EndDefine

     

    Question 3:

    Section 3.4.4.1 refers to NTLMv1. Does it actually mean that NTLM v2 session security is not negotiated? The NTLM v1 network trace does not match the pseudo code in this section when NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY is defined. In addition, the NTLMSSP_MESSGE_SIGNATURE used in this section is defined in section 2.2.2.9.1, which is defined as NTLM v2 session security is not negotiated.

     

    Answer:

    a.       NTLM version and NTLMv2 session security

    According to [MS-NLMP] Sections 3.3.1 and 3.3.2, the NTLM authentication version (NTLMv1 or NTLMv2) is not negotiated by the protocol. It MUST be configured on both the client and the server prior to authentication.

    In the Negotiate Flags, NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag specifies the use of NTLM v2 session security (See [MS-NLMP] 2.2.2.5 NEGOTIATE). The NTLMv2 session security flag is often referred to as extended session security.  

    The NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY is set in the NEGOTIATE_MESSAGE to the server and the CHALLENGE_MESSAGE to the client in Windows NT 4.0 SP4 and onward (See Appendix 7 Windows Behavior).

    NTLMv1 authentication can use NTLM v2 session security. Depending on your registry configuration, NTLMv1 is used when the NtChallengeResponse from the client does not exceed 24 bytes.

    b.      NTLMv1 message signature when session security is negotiated

    When enhanced session security is negotiated, NTLMv2 signature functions are used (See 3.4.4.2 instead of the referenced 3.4.4.1).  The NTLMSSP_MESSGE_SIGNATURE would be the one defined in section 2.2.2.9.2.

    The document will be updated to reflect that enhanced session security uses the NTLMv2 signature functions. 

    In addition, there will be a correction to the key exchange key calculation logic (Section 3.4.5.1 KXKEY). Although the following update on NTLMv1 with session security does not currently extend to encryption, it correctly shows that the KeyExchangeKey is different from the SessionBaseKey.

    When NTLMv1 with enhanced session security and key exchange key is negotiated (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY and NTLMSSP_NEGOTIATE_KEY_EXCH):

    KeyExchangeKey =  HMAC_MD5(SessionBaseKey, ConcatenationOf( ServerChallenge, ClientChallenge))

    Where:    

    SessionBaseKey is calculated from the user’s password

    ServerChallenge is in sent in CHALLENGE_MESSAGE from server to client (see Section 2.2.1.2 ).           

    ClientChallenge is put in the first 8 bytes of the LM challenge response field sent by the client.  The other 16 bytes of the LM response will be zero (see Section 3.3.1).   

     

    Question 4:

    Section 3.4.4.2 refers to NTLMv2. Does it actually mean NTLM v2 session security? The NTLM v1 network trace seems to match this NTLM v2 pseudo code when NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY is defined. In addition, the NTLMSSP_MESSGE_SIGNATURE used in this section is defined in section 2.2.2.9.2, which refers to NTLM v2 session security.

     

    Answer:

    For the clarification on NTLM version and NTLMv2 session security, please refer to the answer for Question 3.

    There is a typo in this section; the reference 2.2.1.4 for the NTLMSSP_MESSAGE_SIGNATURE should be 2.2.2.9, i.e.:

           -- Output:

           --   An NTLMSSP_MESSAGE_SIGNATURE structure whose fields are defined

                in section 2.2.1.4.

    will be updated to:

           -- Output:

           --   An NTLMSSP_MESSAGE_SIGNATURE structure whose fields are defined

                in section 2.2.2.9.

    When NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is negotiated, the NTLMSSP_MESSAGE_SIGNATURE for Extended Session Security is used (see 2.2.2.9.2).

     

    Question 5:

    Section 3.4.4.2 lists two pseudo code sections, and the second one is used when “a key exchange key is negotiated … except the 8 bytes of the HMAC_MD5 are encrypted with RC4”. Indeed, the two sections are the same, and one of them is wrong.

     

    Answer:

    In Section 3.4.4.2 NTLMv2, we will have the following update:

    If message integrity is negotiated, the message signature is calculated as follows:

           Define MAC(Handle, SigningKey, SeqNum, Message) as

                Set NTLMSSP_MESSAGE_SIGNATURE.Version to 0x00000001

                Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to

                    HMAC_MD5(SigningKey,

                    ConcatenationOf(SeqNum, Message))[0..7]

                Set NTLMSSP_MESSAGE_SIGNATURE.SeqNum to SeqNum

                Set SeqNum to SeqNum + 1

           EndDefine

     

     

    Question 6:

    Section 6 definition of ConcatenationOf(…) does not match the usages in pseudo codes.

     

    Answer:

    As shown in the updated pseudo-code below, the API returns multiple blobs, however the application can send them in any order. In fact, the API returns the signature and message, but the application can send them on the wire in the order of its preference.

    The version number in the message signature is sent in little-endian. As stated in Section 2.2 (Message syntax), the protocol uses little-endian order unless otherwise specified.

    3.4.3   Message Confidentiality

           -- Input:

           --   SigningKey - The key used to sign the message.

           --   Message - The message provided by the application to be sealed.

           --   NegFlg, SeqNum - Defined in section 3.1.1.

           --   Handle - The handle to a key state structure corresponding to the

           --   current state of the SealingKey

           --

           -- Output:     

           --   Sealed message – encrypted message

           --   Signature – checksum of sealed message

           --

           --   Functions used:

           --   ConcatenationOf() - Defined in Section 6.

           --   RC4() - Defined in Section 6 and 3.1.

           --   MAC() - Defined in Section 3.4.4.1 and 3.4.4.2.

           --   CRC32() - Defined in Section 6.

            

           If (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set in NegFlg)

            

              Define SEAL(Handle, SigningKey, SeqNum, Message) as

                Set Sealed message to RC4(Handle, Message)

                Set Signature to MAC(Handle, SigningKey,SeqNum, Message)

              EndDefine

            

           Else

                

              Define SEAL(Handle, SigningKey, SeqNum, Message) as

                Set Sealed message to RC4(Handle, Message)

                Set Signature to ConcatenationOf(0x00000001,

                RC4(Handle, ConcatenationOf(NONCE(4),

                CRC32(ConcatenationOf(SeqNum, Message)), SeqNum)))

              EndDefine

     

    Thanks for helping us to improve the MS-NLMP specification.

     

    Regards,

    Edgar

    Friday, December 5, 2008 10:44 PM
    Moderator
  • Rahul,

    I noticed that you also posted your question here. I will follow-up with you regarding your question on that forum thread.

    Dominic Salemno
    Escalation Engineer
    US-CSS DSC Protocols Team

    Tuesday, August 10, 2010 3:40 PM

All replies

  • Anyone still interests in NTLM?

    Monday, October 27, 2008 1:30 PM
  •  

    I have alerted our Protocols Support team concerning your questions. One of our team members will contact you soon.
    Thanks!

    Edgar

    Monday, October 27, 2008 2:22 PM
    Moderator
  • Hi,

    With regards to NTLMv1 and NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY, we have revised the NTLMv1 authentication algorithm in Section 3.3.1.

    SessionBaseKey is an interim value that is used to compute the key exchange key. The pseudo-code in Section “3.3.1 NTLMv1 authentication” will be updated as follows.

    3.3.1   NTLM v1 Authentication

    the last line:

           Set SessionBaseKey to MD4(NTOWF)

    will be changed to:

           If (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set in NegFlg)

               Set SessionBaseKey to HMAC_MD5(MD4(NTOWF),ConcatenationOf{CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge})

           Else

               Set SessionBaseKey to MD4(NTOWF)

    Endif

    When NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set, this results in identical values for both session base key and key exchange key as stated in Section 3.4.5.1 KXKEY.

    The value of the session base key will be updated in Section 4.2.3.1.2.

    4.2.3.1.2   Session Base Key

    The SessionBaseKey is specified in section 3.3.1:

           0000000: eb 93 42 9a 8b d9 52 f8 b8 9c 55 b8 7f 47 5e dc   ..B...R...U..G..


    The changes will be available in a future release of the document. Thanks for helping us to improve the [MS-NLMP] specification.

    Regards,

    Edgar
    • Marked as answer by hwang2007 Tuesday, November 11, 2008 7:25 PM
    • Unmarked as answer by hwang2007 Tuesday, November 11, 2008 7:25 PM
    • Unmarked as answer by hwang2007 Tuesday, November 11, 2008 7:25 PM
    • Unmarked as answer by hwang2007 Tuesday, November 11, 2008 7:25 PM
    Monday, November 10, 2008 11:16 PM
    Moderator
  • Hi Edgar,

    Thanks for the response. Your update aligns the pseudo code in section 3.3.1 with the values in 4.2.3.1.2. Unfortunately, even with this update, I still have troubles to use NTLM extended session security. I will highly appreciate if you could provide the signing key, the sealing key and a piece of message in plain text and cipher text in the examples in section 4.2.2 and 4.2.3.

    This specification has a few other things that confuse me.

    1. Section 3.4.4.1 has the following pseudo code,

    Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to CRC32(SigningKey, ConcatenationOf(SeqNum, RandomPad, Message))[0..7]

    In this code, CRC32 takes two input arguments. However, section 6 defines CRC32(M), which only take one input argument.

    2. Section 3.4.3 seals the message in the format of
    ConcatenationOf(RC4(handle, Message), …)

    Based on the network trace, the message seems in the format of ConcatenationOf(…, RC4(handle, Message)).

    3. Section 3.4.4.1 refers to NTLMv1. Does it actually mean that NTLM v2 session security is not negotiated? The NTLM v1 network trace does not match the pseudo code in this section when NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY is defined. In addition, the NTLMSSP_MESSGE_SIGNATURE used in this section is defined in section 2.2.2.9.1, which is defined as NTLM v2 session security is not negotiated.

    4. Section 3.4.4.2 refers to NTLMv2. Does it actually mean NTLM v2 session security? The NTLM v1 network trace seems to match this NTLM v2 pseudo code when NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY is defined. In addition, the NTLMSSP_MESSGE_SIGNATURE used in this section is defined in section 2.2.2.9.2, which refers to NTLM v2 session security.

    5. Section 3.4.4.2 lists two pseudo code sections, and the second one is used when “a key exchange key is negotiated … except the 8 bytes of the HMAC_MD5 are encrypted with RC4”. Indeed, the two sections are the same, and one of them is wrong.

    6. Section 6 definition of ConcatenationOf(…) does not match the usages in pseudo codes.


    Thanks again for your helps. I am looking forward to hearing from you,

    Regards,

    HW

    • Edited by hwang2007 Wednesday, November 12, 2008 7:59 PM
    Wednesday, November 12, 2008 7:57 PM
  • Hi,

    Thanks for the new questions. We will post the answer once we complete our investigation.

    Regards,
    Edgar
    Wednesday, November 12, 2008 10:51 PM
    Moderator
  •  

    Hi,


    In order to correctly investigate Questions 2, and 4, I am requesting you provide the trace of the issue you are experiencing.

      

    Please upload the network trace at the following location, and provide all the relevant details (e.g. scenario, data) that would enable to analyze the trace and assist you with this inquiry.

    URL: https://sftus.one.microsoft.com/choosetransfer.aspx?key=4a03c681-002a-4dc8-bd83-c2753e4b5c6c

    Password: hA*80%JU-^7


    Regards,

    Edgar

    Friday, November 14, 2008 9:52 PM
    Moderator
  • Hi Edgar,

    Thanks for the expedia response. I have sent a request to my company to get permission to upload the network trace. At the mean, here is a piece of data from the network trace.

    NTLM Version: v1
    NTLM Flags:
            NTLMSSP_NEGOTIATE_UNICODE
            NTLMSSP_REQUEST_TARGET
            NTLMSSP_NEGOTIATE_SIGN
            NTLMSSP_NEGOTIATE_SEAL
            NTLMSSP_NEGOTIATE_NTLM
            NTLMSSP_NEGOTIATE_ALWAYS_SIGN
            NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
            NTLMSSP_NEGOTIATE_TARGET_INFO
            NTLMSSP_NEGOTIATE_VERSION
            NTLMSSP_NEGOTIATE_128
            NTLMSSP_NEGOTIATE_KEY_EXH
            NTLMSSP_NEGOTIATE_56

    The text at the end shows the encrypted message.

    The first 16 bytes, 
               01 00 00 00 86 d7 c7 cc cb bb 3c 92 00 00 00 00
    indicates that it is the NTLMSSP_MESSAGE_SIGNATURE, and the message is in the format of
    ConcatenationOf(NTLMSSP_MESSAGE_SIGNATURE, RC4(...)).

    In addition, the last 4 bytes in the above text is 00 00 00 00, which should be the sequence number, and this number increases sequentially in the trace, which indicates the NTLMSSP_MESSAGE_SIGNATURE is calculated through 3.4.4.2 NTLMv2. However, the authenticated user is NTLM v1.

    I will upload the network trace as soon as I get permission.

    Regards,

    HW

    --------------------

                                                           01 00 00 00 86        ...........
    0320   d7 c7 cc cb bb 3c 92 00 00 00 00 df 7e 1d fa e1  .....<......~...
    0330   63 23 e4 92 dc f2 b4 bb a9 3c 87 12 7c 2e 69 9e  c#.......<..|.i.
    0340   d7 7e dc d4 19 b5 f3 2b d2 90 84 8e 20 a1 1d e4  .~.....+.... ...
    0350   33 68 95 d1 de 8b 97 a7 f8 8c c9 b5 72 b6 80 89  3h..........r...
    0360   df 25 0f 4c 3c 51 d4 06 d2 8c 93 80 da 5c 74 ac  .%.L<Q.......\t.
    0370   db 43 c3 a6 3f 08 4f fa 79 4a 54 59 2a f0 6c 35  .C..?.O.yJTY*.l5
    0380   3a 8f 6f 4a 05 6a ff 8f 9c 3d 77 03 de 40 7f 17  :.oJ.j...=w..@..
    0390   62 1f a1 fd 8b 53 8d 3d a0 3d 16 98 4a f8 08 22  b....S.=.=..J.."
    03a0   45 27 21 fe aa ab 8e a3 36 a4 2b a2 f1 11 6e df  E'!.....6.+...n.
    03b0   15 a5 62 71 5e fd f9 ce 4a d8 21 7b 64 31 a1 87  ..bq^...J.!{d1..
    03c0   5a a7 77 3b 48 23 5e 28 93 1c 12 8d 34 00 db 1a  Z.w;H#^(....4...
    03d0   d8 2e 1b 2c 8d 56 ea f0 6f 44 50 40 e3 23 48 e2  ...,.V..oDP@.#H.
    03e0   55 69 de 80 d3 1e 14 b5 22 7f 42 00 d5 98 45 19  Ui......".B...E.
    03f0   ae

    • Edited by hwang2007 Friday, November 14, 2008 10:43 PM
    Friday, November 14, 2008 10:37 PM
  • Hi Edgar,

    I have uploaded the trace file (wireshark) and a readme file. This trace is generated through Microsoft WinRM command line client (winrm) on Windows XP and WinRM service on Windows Server 2008, and collected through wireshark. It reviews that the NTLMSSP_MESSGE_SIGNATURE is in front of RC4(Handle, Message) (Question 2). The sequentially increased sequence number shows that it uses NTLM v2 signature algorithm although it uses NTLM v1 user (Question 3 and 4). In the signature, the version number is 01 00 00 00 instead of 00 00 00 01 (Question 6).

    I highly appreciate your time and efforts to investigate into these questions. And it would also be extreme helpful if you can provide the following information so that I can verify a few more sections in the specification and continue my project. The best help would be the signing key, the sealing key and a sample message in plain text and cipher text in the examples described in the specification.


    Thanks again for your help, and I am looking forward to hearing from you,

    HW

     

    Monday, November 17, 2008 3:03 PM
  • Hi,

    Thanks for the trace. We are investigating your issues and will update you once we have news.

    Regards,
    Edgar
    Monday, November 17, 2008 11:25 PM
    Moderator
  •  

    Hi,

    We have completed investigation of your questions regarding the use of NTLM extended security flag. As a result, there will be a number of updates to the [MS-NLMP] specification. The changes will be included in a later release of the document.

     

    Request:

    I will highly appreciate if you could provide the signing key, the sealing key and a piece of message in plain text and cipher text in the examples in section 4.2.2 and 4.2.3.

     

    Answer:

    The product group has thoroughly reviewed your request. They will be working on adding sanitized crypto examples in Section 4.2. This will appear in a future release of the document.

     

    Question 1:

    Section 3.4.4.1 has the following pseudo code,

    Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to CRC32(SigningKey, ConcatenationOf(SeqNum, RandomPad, Message))[0..7]

    In this code, CRC32 takes two input arguments. However, section 6 defines CRC32(M), which only takes one input argument.

     

    Answer:

    CRC32() takes only one argument as defined in Section 6.

    The pseudo-code in Section 3.4.4.1 will be updated as follows:

           Define MAC(Handle, SigningKey, SeqNum, Message) as

                Set NTLMSSP_MESSAGE_SIGNATURE.Version to 0x00000001

                Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to CRC32(Message)

                Set NTLMSSP_MESSAGE_SIGNATURE.RandomPad RC4(Handle, RandomPad)

                Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to RC4(Handle,

                    NTLMSSP_MESSAGE_SIGNATURE.Checksum)

                Set NTLMSSP_MESSAGE_SIGNATURE.SeqNum to RC4(Handle, 0x00000000)

                If (connection oriented)

                     Set NTLMSSP_MESSAGE_SIGNATURE.SeqNum to

                         NTLMSSP_MESSAGE_SIGNATURE.SeqNum XOR SeqNum

                     Set SeqNum to SeqNum + 1

                Else

                     Set NTLMSSP_MESSAGE_SIGNATURE.SeqNum to

                         NTLMSSP_MESSAGE_SIGNATURE.SeqNum XOR

                         (application supplied SeqNum)

                Endif

                Set NTLMSSP_MESSAGE_SIGNATURE.RandomPad to 0

           EndDefine

     

    Question 2:

     Section 3.4.3 seals the message in the format of

    ConcatenationOf(RC4(handle, Message), …)

    Based on the network trace, the message seems in the format of ConcatenationOf(…, RC4(handle, Message)).

     

    Answer:

    The pseudo code will be updated as follows:

           -- Input:

           --   SigningKey - The key used to sign the message.

           --   Message - The message provided by the application to be sealed.

           --   NegFlg, SeqNum - Defined in section 3.1.1.

           --   Handle - The handle to a key state structure corresponding to the

           --   current state of the SealingKey

           --

           -- Output:     

           --   Sealed message – encrypted message

           --   Signature – checksum of sealed message

           --

           --   Functions used:

           --   ConcatenationOf() - Defined in Section 6.

           --   RC4() - Defined in Section 6 and 3.1.

           --   MAC() - Defined in Section 3.4.4.1 and 3.4.4.2.

           --   CRC32() - Defined in Section 6.

            

           If (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set in NegFlg)

            

              Define SEAL(Handle, SigningKey, SeqNum, Message) as

                Set Sealed message to RC4(Handle, Message)

                Set Signature to MAC(Handle, SigningKey,SeqNum, Message)

              EndDefine

            

           Else

                

              Define SEAL(Handle, SigningKey, SeqNum, Message) as

                Set Sealed message to RC4(Handle, Message)

                Set Signature to ConcatenationOf(0x00000001,

                RC4(Handle, ConcatenationOf(NONCE(4),

                CRC32(ConcatenationOf(SeqNum, Message)), SeqNum)))

              EndDefine

     

    Question 3:

    Section 3.4.4.1 refers to NTLMv1. Does it actually mean that NTLM v2 session security is not negotiated? The NTLM v1 network trace does not match the pseudo code in this section when NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY is defined. In addition, the NTLMSSP_MESSGE_SIGNATURE used in this section is defined in section 2.2.2.9.1, which is defined as NTLM v2 session security is not negotiated.

     

    Answer:

    a.       NTLM version and NTLMv2 session security

    According to [MS-NLMP] Sections 3.3.1 and 3.3.2, the NTLM authentication version (NTLMv1 or NTLMv2) is not negotiated by the protocol. It MUST be configured on both the client and the server prior to authentication.

    In the Negotiate Flags, NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag specifies the use of NTLM v2 session security (See [MS-NLMP] 2.2.2.5 NEGOTIATE). The NTLMv2 session security flag is often referred to as extended session security.  

    The NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY is set in the NEGOTIATE_MESSAGE to the server and the CHALLENGE_MESSAGE to the client in Windows NT 4.0 SP4 and onward (See Appendix 7 Windows Behavior).

    NTLMv1 authentication can use NTLM v2 session security. Depending on your registry configuration, NTLMv1 is used when the NtChallengeResponse from the client does not exceed 24 bytes.

    b.      NTLMv1 message signature when session security is negotiated

    When enhanced session security is negotiated, NTLMv2 signature functions are used (See 3.4.4.2 instead of the referenced 3.4.4.1).  The NTLMSSP_MESSGE_SIGNATURE would be the one defined in section 2.2.2.9.2.

    The document will be updated to reflect that enhanced session security uses the NTLMv2 signature functions. 

    In addition, there will be a correction to the key exchange key calculation logic (Section 3.4.5.1 KXKEY). Although the following update on NTLMv1 with session security does not currently extend to encryption, it correctly shows that the KeyExchangeKey is different from the SessionBaseKey.

    When NTLMv1 with enhanced session security and key exchange key is negotiated (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY and NTLMSSP_NEGOTIATE_KEY_EXCH):

    KeyExchangeKey =  HMAC_MD5(SessionBaseKey, ConcatenationOf( ServerChallenge, ClientChallenge))

    Where:    

    SessionBaseKey is calculated from the user’s password

    ServerChallenge is in sent in CHALLENGE_MESSAGE from server to client (see Section 2.2.1.2 ).           

    ClientChallenge is put in the first 8 bytes of the LM challenge response field sent by the client.  The other 16 bytes of the LM response will be zero (see Section 3.3.1).   

     

    Question 4:

    Section 3.4.4.2 refers to NTLMv2. Does it actually mean NTLM v2 session security? The NTLM v1 network trace seems to match this NTLM v2 pseudo code when NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY is defined. In addition, the NTLMSSP_MESSGE_SIGNATURE used in this section is defined in section 2.2.2.9.2, which refers to NTLM v2 session security.

     

    Answer:

    For the clarification on NTLM version and NTLMv2 session security, please refer to the answer for Question 3.

    There is a typo in this section; the reference 2.2.1.4 for the NTLMSSP_MESSAGE_SIGNATURE should be 2.2.2.9, i.e.:

           -- Output:

           --   An NTLMSSP_MESSAGE_SIGNATURE structure whose fields are defined

                in section 2.2.1.4.

    will be updated to:

           -- Output:

           --   An NTLMSSP_MESSAGE_SIGNATURE structure whose fields are defined

                in section 2.2.2.9.

    When NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is negotiated, the NTLMSSP_MESSAGE_SIGNATURE for Extended Session Security is used (see 2.2.2.9.2).

     

    Question 5:

    Section 3.4.4.2 lists two pseudo code sections, and the second one is used when “a key exchange key is negotiated … except the 8 bytes of the HMAC_MD5 are encrypted with RC4”. Indeed, the two sections are the same, and one of them is wrong.

     

    Answer:

    In Section 3.4.4.2 NTLMv2, we will have the following update:

    If message integrity is negotiated, the message signature is calculated as follows:

           Define MAC(Handle, SigningKey, SeqNum, Message) as

                Set NTLMSSP_MESSAGE_SIGNATURE.Version to 0x00000001

                Set NTLMSSP_MESSAGE_SIGNATURE.Checksum to

                    HMAC_MD5(SigningKey,

                    ConcatenationOf(SeqNum, Message))[0..7]

                Set NTLMSSP_MESSAGE_SIGNATURE.SeqNum to SeqNum

                Set SeqNum to SeqNum + 1

           EndDefine

     

     

    Question 6:

    Section 6 definition of ConcatenationOf(…) does not match the usages in pseudo codes.

     

    Answer:

    As shown in the updated pseudo-code below, the API returns multiple blobs, however the application can send them in any order. In fact, the API returns the signature and message, but the application can send them on the wire in the order of its preference.

    The version number in the message signature is sent in little-endian. As stated in Section 2.2 (Message syntax), the protocol uses little-endian order unless otherwise specified.

    3.4.3   Message Confidentiality

           -- Input:

           --   SigningKey - The key used to sign the message.

           --   Message - The message provided by the application to be sealed.

           --   NegFlg, SeqNum - Defined in section 3.1.1.

           --   Handle - The handle to a key state structure corresponding to the

           --   current state of the SealingKey

           --

           -- Output:     

           --   Sealed message – encrypted message

           --   Signature – checksum of sealed message

           --

           --   Functions used:

           --   ConcatenationOf() - Defined in Section 6.

           --   RC4() - Defined in Section 6 and 3.1.

           --   MAC() - Defined in Section 3.4.4.1 and 3.4.4.2.

           --   CRC32() - Defined in Section 6.

            

           If (NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set in NegFlg)

            

              Define SEAL(Handle, SigningKey, SeqNum, Message) as

                Set Sealed message to RC4(Handle, Message)

                Set Signature to MAC(Handle, SigningKey,SeqNum, Message)

              EndDefine

            

           Else

                

              Define SEAL(Handle, SigningKey, SeqNum, Message) as

                Set Sealed message to RC4(Handle, Message)

                Set Signature to ConcatenationOf(0x00000001,

                RC4(Handle, ConcatenationOf(NONCE(4),

                CRC32(ConcatenationOf(SeqNum, Message)), SeqNum)))

              EndDefine

     

    Thanks for helping us to improve the MS-NLMP specification.

     

    Regards,

    Edgar

    Friday, December 5, 2008 10:44 PM
    Moderator
  • Hi Edgar,

    Thanks a lot for your helps. I am impressed by the amount of efforts that you and Microsoft are willing to put to help users.

    The NTLM specification uses NTLM v2 and NTLM v2 session security liberally. They may be obvious to people who knows all the details, but are confusion to outsiders.

     

    I have moved on to Kerberos, and have a few questions. And I would like to your help there.

     

    Best Regards,

     

    Hengli

     

     

    Wednesday, January 21, 2009 9:33 PM
  • Hello,

    I am writing a Microsoft OCS client in java and i get a SIP 200 OK after i register successfully to OCS Server. Here is 200 OK response:

    SIP/2.0 200 OK
    Authentication-Info: NTLM rspauth="01000000000000004388D7B36E884A8A", srand="4BFB0851", snum="1", opaque="EAB39E9A", qop="auth", targetname="avaya.com", realm="SIP Communications Service"
    ms-keep-alive: UAS; tcp=no; hop-hop=yes; end-end=no; timeout=300
    Via: SIP/2.0/TCP 198.152.113.78:11367;ms-received-port=1532;ms-received-cid=5143e00
    From: <sip:rjangam@avaya.com>;tag=6dfc10f44b;epid=38a4235837
    To: <sip:rjangam@avaya.com>;tag=504425B9B8E76FDED17D97C33A0B31E6
    Call-ID: bc286de70ed7493983823b2c9a0032f9
    CSeq: 3 REGISTER
    Contact: <sip:198.152.113.78:1532;transport=tcp;ms-received-cid=5143E00>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";expires=7200
    Expires: 7200
    presence-state: required="yes",resync="yes"
    Allow-Events: vnd-microsoft-provisioning,vnd-microsoft-roaming-contacts,vnd-microsoft-roaming-ACL,presence,presence.wpending
    Supported: adhoclist
    Server: RTC/2.1
    Content-Length: 0

    You can see there are snum, srand and NTLM V1 signature as a response values in Auth-Info header. Now i want to validate the signature using these values. Does anybody knows how can validate this signature as well as how it can be created while sending INVITE or SUBSCRIBE messages to OCS Server??

    I searched in MS-NLMP and MS-SIPAE docs as well. But there not much information on exactly how do i calculate this signature other than just saying that i need to build a security buffer to validate signature.

     

    THanks in Advance,

    Rahul (rahul.jangam@gmail.com)

    Tuesday, August 10, 2010 12:56 PM
  • Rahul,

    I noticed that you also posted your question here. I will follow-up with you regarding your question on that forum thread.

    Dominic Salemno
    Escalation Engineer
    US-CSS DSC Protocols Team

    Tuesday, August 10, 2010 3:40 PM
  • Thanks a lot Dominic.! I appreciate your help.

     

    Regards,

    Rahul

    Tuesday, August 10, 2010 4:02 PM