none
[MS-NRPC] clarifications RRS feed

  • Question

  • Re: [MS-NRPC]

    3.4.5.3.2 says that the UserSessionKey and Expansion room is encrypted, but does not say how. It appears AES is used when AES is negotiated.

    AES128 should be clarified as AES128 in 8 bit CFB mode.

    3.3.4.2.1.8 should note that the RC4 cipherstate is reset after encrypting the confounder.

    3.3.4.2.1.7 should note that the the SHA-256 checksum is truncated to 8 bytes, but padded to 32 with data that should be ignored on receipt.

    2.2.1.3.7: it's not clear how NL_TRUST_PASSWORD is supposed to work when NDR is used in big-endian mode. It seems to me this should be redefined as NL_ENCRYPTED_TRUST_PASSWORD, with the same layout as SAMPR_ENCRYPTED_USER_PASSWORD ([MS-SAMR] 2.2.7.21).

    Also, is NL_TRUST_PASSWORD always encrypted with RC4, or is AES used when AES is negotiated?

    -- Luke
    Tuesday, February 9, 2010 6:27 PM

Answers

  • Luke,

     

       I have some updates for the questions below.

     

    Question :    3.4.5.3.2 says that the UserSessionKey and Expansion room is encrypted, but does not say how. It appears AES is used when AES is negotiated.

     

     

     

     

       ANS:   We are still working on this issue.

     

      ANS:  The Section 3.4.5.2.5   Calling NetrServerPasswordSet2, Section 3.4.5.6.4   Calling NetrLogonSendToSam, Section 3.5.5.3.5   NetrServerPasswordSet2 (Opnum 30), Section 3.5.5.7.4   NetrLogonSendToSam (Opnum 32) are all updated to indicate that the encryption is done “using the negotiated encryption algorithm (determined by bits C, O, or W, respectively, in the NegotiateFlags”

     

     

    Thanks!

     

    Hongwei

     

    Question:   Also, is NL_TRUST_PASSWORD always encrypted with RC4, or is AES used when AES is negotiated?

       ANS:    We have double checked again and confirmed that  the state is not  reset when we encrypt the Confounder and the Data supplied by the application.    Is there any information showing the state is reset ?    

     

     

    Question:   2.2.1.3.7: it's not clear how NL_TRUST_PASSWORD is supposed to work when NDR is used in big-endian mode. It seems to me this should be redefined as NL_ENCRYPTED_TRUST_PASSWORD, with the same layout as SAMPR_ENCRYPTED_USER_PASSWORD ([MS-SAMR] 2.2.7.21).

         ANS:    Yes, we agree that AES negotiated over secure channel are all in 8 bit CFB mode.   Therefore,  we updated the section 3.1.4.2 as follows

     

    Section 3.1.4.2   Netlogon Negotiable Options

    Supports AES encryption (128 bit in 8-bit CFB mode) and SHA2 hashing as specified in sections 2.2.1.3.3, 3.1.4.3, 3.1.4.4, and 3.3.<80>

     

    Question :    3.3.4.2.1.8 should note that the RC4 cipherstate is reset after encrypting the confounder.

    ANS:   Encryption  at the RPC layer (by Netlogon SSP) or the application layer (Netlogon component itself) is done based on NegotiatedFlags. The algorithms are the same in both cases.  We will update the corresponding sections  of MS-NRPC to reflect that.  Thanks for your suggestion.  

     

    Question :   AES128 should be clarified as AES128 in 8 bit CFB mode.


    Hongwei Sun -MSFT
    Wednesday, March 3, 2010 11:52 PM

All replies

  • Thank you for your question Luke. Someone from our team will be assisting you shortly in regards to your questions.

    Dominic Michael Salemno
    Senior Support Escalation Engineer
    US-CSS DSC Protocols Team
    Tuesday, February 9, 2010 8:08 PM
  • Hi, Luke,

     

       I finished the investigation on all questions.  Please see the responses inline.

     

      3.4.5.3.2 says that the UserSessionKey and Expansion room is encrypted, but does not say how. It appears AES is used when AES is negotiated.

     

     >>>ANS:    The NetrLogonSamrLogonEx function documented in 3.4.5.3.2 can  be called only  after the secure channel has been established.  So the encryption type will be dependent on the NegotiateFlags used between the client and the server  during the secure channel establishment.   Therefore , they could be encrypted by either RC4 or AES using the session key computed as described in   3.1.4.3.        

     

      AES128 should be clarified as AES128 in 8 bit CFB mode.

     

    >>>ANS:  This has been  clarified   in  section 3.1.4.4.1.  Please review the section.

     

      3.3.4.2.1.8 should note that the RC4 cipherstate is reset after encrypting the confounder.

     

    >>>ANS:    The encryption (RC4 or AES128)  will be re-initialized with a different encryption key  after cofounder and message data are encrypted.   Then SequenceNumber will be encrypted using the new encryption key that is the combination of checksum and session key.   The documentation is correct in this regard.

     

      3.3.4.2.1.7 should note that the the SHA-256 checksum is truncated to 8 bytes, but padded to 32 with data that should be ignored on receipt.

     

    >>> ANS:   This is implicitly indicated by the structure of NL_AUTH_SHA2_SIGNATURE(2.2.1.3.3),  where the checksum is defined as 32 bytes.  In  step 11 of 3.3.4.2.2,  it also states that the server MUST only  use the first 8 bytes of computed signature to compare with the  checksum  in NL_AUTH_SHA2_SIGNATURE .   Therefore, the documentation is adequate in this issue.  

     

      2.2.1.3.7: it's not clear how NL_TRUST_PASSWORD is supposed to work when NDR is used in big-endian mode. It seems to me this should be redefined as NL_ENCRYPTED_TRUST_PASSWORD, with the same layout as SAMPR_ENCRYPTED_USER_PASSWORD ([MS-SAMR] 2.2.7.21).

     

    >>> ANS:  The  layout of both NL_ENCRYPTED_TRUST_PASSWORD and NL_TRUST_PASSWORD are essentially the same.  They both have 256 WCHAR (512 byte) plus four bytes of length.

     

      Also, is NL_TRUST_PASSWORD always encrypted with RC4, or is AES used when AES is negotiated?

     

    >>>ANS:   No,  It is dependent on the NegotiateFlag used when secure channel is established.  It could be RC4  when AES is not negotiated or AES when AES is negotiated.  Currently the document only mentions RC4.  We will fix this in the section 3.4.5.2.5 of  future release.

     

    Thanks so much for your effort to help us improve Open Protocol Documentation.

     


    Hongwei Sun -MSFT
    Friday, February 12, 2010 6:38 PM
  •    I finished the investigation on all questions.  Please see the responses inline.

     

      3.4.5.3.2 says that the UserSessionKey and Expansion room is encrypted, but does not say how. It appears AES is used when AES is negotiated.

     

     >>>ANS:    The NetrLogonSamrLogonEx function documented in 3.4.5.3.2 can  be called only  after the secure channel has been established.  So the encryption type will be dependent on the NegotiateFlags used between the client and the server  during the secure channel establishment.   Therefore , they could be encrypted by either RC4 or AES using the session key computed as described in   3.1.4.3.        

     

    This is still a little unclear. The previous references to encryption as far as I can tell regard credential and RPC layer encryption. Which algorithm is used for application layer encryption is unclear.

     

    I suggest you explicitly define application layer encryption, with respect to flags C and W of the negotiable options, and then refer to it sections that presently reference encryption at the application layer, such as NetrLogonSamrLogonEx, NetrLogonSendToSam, NLPR_USER_PRIVATE_INFO, etc.

     

     AES128 should be clarified as AES128 in 8 bit CFB mode.

     

    >>>ANS:  This has been  clarified   in  section 3.1.4.4.1.  Please review the section.

     

    This is still unclear: it's not just the credentials that are computed with AES-128 in 8 bit CFB mode, it is anything that is encrypted over the secure channel using AES. See above.

     

      3.3.4.2.1.8 should note that the RC4 cipherstate is reset after encrypting the confounder.

     

    >>>ANS:    The encryption (RC4 or AES128)  will be re-initialized with a different encryption key  after cofounder and message data are encrypted.   Then SequenceNumber will be encrypted using the new encryption key that is the combination of checksum and session key.   The documentation is correct in this regard.

     

    You misunderstand my question. My question refers to the RC4 cipherstate being reinitialised after encrypting the confounder and before encrypting the data, which is a design flaw that defeats the purpose of the confounder. My question does not refer to the cipherstate being reset before encrypting the SequenceNumber; that falls out from a different key being used.

     

      3.3.4.2.1.7 should note that the the SHA-256 checksum is truncated to 8 bytes, but padded to 32 with data that should be ignored on receipt.

     

    >>> ANS:   This is implicitly indicated by the structure of NL_AUTH_SHA2_SIGNATURE(2.2.1.3.3),  where the checksum is defined as 32 bytes.  In  step 11 of 3.3.4.2.2,  it also states that the server MUST only  use the first 8 bytes of computed signature to compare with the  checksum  in NL_AUTH_SHA2_SIGNATURE .   Therefore, the documentation is adequate in this issue.  

     

    Noted, although some clarification may be desirable given that truncating a SHA-256 signature to 8 bytes is an unusual design choice.

     

      2.2.1.3.7: it's not clear how NL_TRUST_PASSWORD is supposed to work when NDR is used in big-endian mode. It seems to me this should be redefined as NL_ENCRYPTED_TRUST_PASSWORD, with the same layout as SAMPR_ENCRYPTED_USER_PASSWORD ([MS-SAMR] 2.2.7.21).

     

    >>> ANS:  The  layout of both NL_ENCRYPTED_TRUST_PASSWORD and NL_TRUST_PASSWORD are essentially the same.  They both have 256 WCHAR (512 byte) plus four bytes of length.

     

    This will create an interoperability problem on non-little-endian systems. NL_ENCRYPTED_TRUST_PASSWORD should be defined as a byte array or you should explicitly indicate how NL_TRUST_PASSWORD is used with stream ciphers. The former is preferable as it is consistent with SAMPR_ENCRYPTED_USER_PASSWORD.

     

      Also, is NL_TRUST_PASSWORD always encrypted with RC4, or is AES used when AES is negotiated?

     

    >>>ANS:   No,  It is dependent on the NegotiateFlag used when secure channel is established.  It could be RC4  when AES is not negotiated or AES when AES is negotiated.  Currently the document only mentions RC4.  We will fix this in the section 3.4.5.2.5 of  future release.

     

    Thank you for the clarifications.

     

    Monday, February 22, 2010 4:25 PM
  • Thanks!  Luke. 

    I have been working on further clarifications to your comments.  I will let you know once the investigation is done.


    Hongwei Sun -MSFT
    Tuesday, February 23, 2010 12:02 AM
  • Luke,

     

       I have some updates for the questions below.

     

    Question :    3.4.5.3.2 says that the UserSessionKey and Expansion room is encrypted, but does not say how. It appears AES is used when AES is negotiated.

     

     

     

     

       ANS:   We are still working on this issue.

     

      ANS:  The Section 3.4.5.2.5   Calling NetrServerPasswordSet2, Section 3.4.5.6.4   Calling NetrLogonSendToSam, Section 3.5.5.3.5   NetrServerPasswordSet2 (Opnum 30), Section 3.5.5.7.4   NetrLogonSendToSam (Opnum 32) are all updated to indicate that the encryption is done “using the negotiated encryption algorithm (determined by bits C, O, or W, respectively, in the NegotiateFlags”

     

     

    Thanks!

     

    Hongwei

     

    Question:   Also, is NL_TRUST_PASSWORD always encrypted with RC4, or is AES used when AES is negotiated?

       ANS:    We have double checked again and confirmed that  the state is not  reset when we encrypt the Confounder and the Data supplied by the application.    Is there any information showing the state is reset ?    

     

     

    Question:   2.2.1.3.7: it's not clear how NL_TRUST_PASSWORD is supposed to work when NDR is used in big-endian mode. It seems to me this should be redefined as NL_ENCRYPTED_TRUST_PASSWORD, with the same layout as SAMPR_ENCRYPTED_USER_PASSWORD ([MS-SAMR] 2.2.7.21).

         ANS:    Yes, we agree that AES negotiated over secure channel are all in 8 bit CFB mode.   Therefore,  we updated the section 3.1.4.2 as follows

     

    Section 3.1.4.2   Netlogon Negotiable Options

    Supports AES encryption (128 bit in 8-bit CFB mode) and SHA2 hashing as specified in sections 2.2.1.3.3, 3.1.4.3, 3.1.4.4, and 3.3.<80>

     

    Question :    3.3.4.2.1.8 should note that the RC4 cipherstate is reset after encrypting the confounder.

    ANS:   Encryption  at the RPC layer (by Netlogon SSP) or the application layer (Netlogon component itself) is done based on NegotiatedFlags. The algorithms are the same in both cases.  We will update the corresponding sections  of MS-NRPC to reflect that.  Thanks for your suggestion.  

     

    Question :   AES128 should be clarified as AES128 in 8 bit CFB mode.


    Hongwei Sun -MSFT
    Wednesday, March 3, 2010 11:52 PM