none
MSRPC and DCE/RPC Security RRS feed

  • Question

  • It is my understanding that MSRPC is Microsoft's implementation of The Open Group's DCE 1.1 standard with some additional customization.  I want to know how the following:

    1) The DCE 1.1 spec seems to only support MD4/MD5 for RPC message integrity.  What about Microsoft's implementation?  Does MSRPC support those as well as others?  If so, which ones?

    2) The DCE 1.1 spec seems to only support DES (single) in CBC-mode for RPC message confidentiality.  What about Microsoft's implementation?  Does MSRPC support that as well as other algorithms and/or modes?  If so, which ones?

    3) Does the "Auth type" play into this? For example, in my packet capture, the Auth type in the "Bind" call is "NTLMSSP (10)".  The "NTLM Secure Service Provider" extension includes the following flags: Negotiate 56 and Negotiate 128.  I assume those correspond to the strength of an encryption algorithm.  56 would match up with DES.  Does 128 refer to RC-4 or AES?  Do these flags mean anything for the RPC PDU encryption or are they for the NTLM authentication piece only?

    Any help would be much appreciated!

    Geoff

    Wednesday, May 11, 2016 6:59 PM

Answers

  • 0)

    In the following I will give a series of references for illustration. Please read through the respective specs (Microsoft specific, or standards) for a complete story.

    Wednesday, May 18, 2016 4:30 PM
    Moderator
  • 1)

    The algorithms used for message integrity (auth_level RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) depend on the security provider (see auth_type and [MS-RPCE] 2.2.1.1.7 Security Providers) and the negotiated parameters for that specific provider.

    [MS-RPCE] defines the use of GSS API [RFC2743]. The processing in the calls to GSS_GetMIC() or GSS_VerifyMIC() is transparent to MS-RPCE.

    The specification provides references to various authentication protocols MS-APDS, MS-NLMP, MS-KILE, RFC4121, MS-SPNG, etc.

    Here are some excerpts:

     

    [MS-RPCE]

     

    2.2.1.1.7               Security Providers

    These extensions do not require support for the dce_c_rpc_authn_protocol_krb5 security provider, as specified in [C706] section 13. All of the requirements specified in [C706] section 13 are removed by these extensions.<22>

     These extensions specify the following values for the security provider.

    Name

    Value

    Security provider

    RPC_C_AUTHN_NONE

    0x00

    No Authentication

    RPC_C_AUTHN_GSS_NEGOTIATE

    0x09

     SPNEGO

    RPC_C_AUTHN_WINNT

    0x0A

    NTLM

    RPC_C_AUTHN_GSS_SCHANNEL

    0x0E

    TLS

    RPC_C_AUTHN_GSS_KERBEROS

    0x10

    Kerberos

    RPC_C_AUTHN_NETLOGON

    0x44

    Netlogon

    RPC_C_AUTHN_DEFAULT

    0xFF

    Same as RPC_C_AUTHN_WINNT

    On the client side, if the higher level protocol requests RPC_C_AUTHN_DEFAULT, the implementation MUST use RPC_C_AUTHN_WINNT instead.

    The security provider underlying protocol and implementation defines the number of legs and whether the number of legs is odd or even that are used in the token exchange process that builds a security context. This information MAY be used for the processing of PDUs during that process. 

    These extensions specify the following number (if known) or even/oddness of the legs needed to build a security context.

    Name

    # of or Even # of Token Exchange Legs

    RPC_C_AUTHN_NONE

    even

    RPC_C_AUTHN_GSS_NEGOTIATE

    even

    RPC_C_AUTHN_WINNT

    3

    RPC_C_AUTHN_GSS_SCHANNEL

    even

    RPC_C_AUTHN_GSS_KERBEROS

    even

    RPC_C_AUTHN_NETLOGON

    3

    RPC_C_AUTHN_DEFAULT

    unknown

     

    <22> Section 2.2.1.1.7: Without the installation of additional software, Windows supports the following authentication types:

    Security Provider

    • Security Provider Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
    • NT LAN Manager (NTLM)
    • Kerberos
    • Netlogon

     

    2.2.1.1.8        Authentication Levels

    These extensions specify the following values for the authentication levels.

    Name

    Value

    Meaning

    RPC_C_AUTHN_LEVEL_DEFAULT

    0x00

    Same as RPC_C_AUTHN_LEVEL_CONNECT

    RPC_C_AUTHN_LEVEL_NONE

    0x01

    No authentication.

    RPC_C_AUTHN_LEVEL_CONNECT

    0x02

    Authenticates the credentials of the client and server.

    RPC_C_AUTHN_LEVEL_CALL

    0x03

    Same as RPC_C_AUTHN_LEVEL_PKT.

    RPC_C_AUTHN_LEVEL_PKT

    0x04

    Same as RPC_C_AUTHN_LEVEL_CONNECT but also prevents replay attacks.

    RPC_C_AUTHN_LEVEL_PKT_INTEGRITY

    0x05

    Same as RPC_C_AUTHN_LEVEL_PKT but also verifies that none of the data transferred between the client and server has been modified.

    RPC_C_AUTHN_LEVEL_PKT_PRIVACY

    0x06

    Same as RPC_C_AUTHN_LEVEL_PKT_INTEGRITY but also ensures that the data transferred can only be seen unencrypted by the client and the server.

    If the higher-level application or protocol requests an authentication level that the implementation or security provider does not support, it MUST upgrade the request to the next highest supported level. RPC_C_AUTHN_LEVEL_PKT_PRIVACY MUST be supported.

    On the client side, if the higher-level protocol requests RPC_C_AUTHN_LEVEL_CALL, the implementation MUST upgrade it to RPC_C_AUTHN_LEVEL_PKT. Similarly, on the server side, if the auth_level field of the sec_trailer structure as specified in sections 2.2.2.11 and 2.2.3.4 is RPC_C_AUTHN_LEVEL_CALL, the implementation MUST process it in the same manner as a packet with auth_level RPC_C_AUTHN_LEVEL_PKT.

    Also, on the client side, if the higher-level protocol requests RPC_C_AUTHN_LEVEL_DEFAULT, the implementation MUST use RPC_C_AUTHN_LEVEL_CONNECT instead.

     

    2.2.2.11                sec_trailer Structure

    auth_type (1 byte):  MUST contain an authentication type. For information on how this is used, see sections 3.1.1.1.1, 3.3.1.5.2, and 3.1.3.1.1. If a request or response is fragmented, all PDUs from that request or response MUST have the same auth_type.

    auth_level (1 byte):  MUST contain one of the authentication levels as specified in section 2.2.1.1.8. The value serves a dual purpose. The first purpose is to specify what security protection is applied to what segment of the PDU, as specified in section 3.3.1.5.2. The second purpose is to serve as a parameter to the security provider that it SHOULD use to determine how to provide protection for the respective PDU segment. For information on how security providers use that, see the documentation for the respective security provider. If a request or response is fragmented, all PDUs from that request or response MUST have the same auth_level.

     

    2.2.2.12                Authentication Tokens

    These extensions require the conceptual model specified in [RFC2743] for all interactions with all security providers. An implementation instructs the Generic Security Services (GSS)-API–compatible security providers to operate in a distributed computing environment (DCE)–compatible manner by setting the DCE Style protocol variable. The following table details what PDU type MUST carry (in its auth_ token segment) the output of what GSS [GSS] call during processing, as specified in section 3.3.1.5.2.2.

     RPC PDU name

     GSS call producing auth_value

     Bind

    First call to GSS_Init_sec_context, as specified in [RFC2743] section 2.2.1.

     bind_ack

    First call to GSS_Accept_sec_context, as specified in [RFC2743] section 2.2.2.

     alter_context, rpc_auth_3

    Second and subsequent calls to GSS_Init_sec_context, as specified in [RFC2743] section 2.2.1.

     alter_context_resp

    Second and subsequent calls to GSS_Accept_sec_context, as specified in [RFC2743] section 2.2.2.

    Request

    If the auth_level (as specified in section 2.2.2.11) is RPC_C_AUTHN_LEVEL_PKT_PRIVACY, call to GSS_WrapEx; else call to GSS_GetMICEx. See section 3.3.1.5.2.2 for details.

    Response

    If the auth_level (as specified in section 2.2.2.11) is RPC_C_AUTHN_LEVEL_PKT_PRIVACY, call to GSS_UnwrapEx; else call to GSS_VerifyMICEx. See section 3.3.1.5.2.2 for details.

     

     

    3.3.1.5.2.1           Building a Security Context

    Once a client decides on the type of PDU, it MUST start the sequence by requesting the security provider for an authentication token using an implementation-specific equivalent of the abstract GSS_Init_sec_context call, as specified in [RFC2743]. See [MS-APDS] section 3.1.5 for NTLM details and see [RFC4121] and [MS-KILE] section 3.2.5.2 for Kerberos details. This PDU MUST be sent to the server with authentication information added, as specified in section 2.2.2.11.

     

    3.3.1.5.2.2           Using a Security Context

    The following table specifies the abstract capability that the RPC runtime MUST request from the security provider when the security context is being created. The capabilities in the following table are further specified in [RFC2743] section 1.2.1.2. The capabilities requested at each level include the ones requested at the previous level.

     Authentication level

     Capability requested

    RPC_C_AUTHN_LEVEL_CONNECT

    None

    RPC_C_AUTHN_LEVEL_PKT

    Replay Detect

    RPC_C_AUTHN_LEVEL_PKT_INTEGRITY

    Sequence Detect, integrity

    RPC_C_AUTHN_LEVEL_PKT_PRIVACY

    Confidentiality

    . . .

    If the client and server Supports Header Signing Flag is TRUE, the party that sends the PDU asks the security provider to apply the following protection to the different PDU segments.

     Authentication level

     PDU header

     PDU body

     sec_trailer

    RPC_C_AUTHN_LEVEL_CONNECT

    None

    None

    None

    RPC_C_AUTHN_LEVEL_PKT

    None

    None

    None

    RPC_C_AUTHN_LEVEL_PKT_INTEGRITY

    Integrity

    Integrity

    Integrity

    RPC_C_AUTHN_LEVEL_PKT_PRIVACY

    Integrity

    Confidentiality

    Integrity

     

    For [MS-NLMP], look at “Section 6            Appendix A: Cryptographic Operations Reference”

    And see how various crypto algorithms are used in the document, e.g. DES, MD4, MD5, RC4.

     

    [MS-NLMP]

    3.3          NTLM v1 and NTLM v2 Messages

    3.3.1      NTLM v1 Authentication

    3.3.1.5.2.2           Using a Security Context

    3.3.2      NTLM v2 Authentication

    3.4.2      Message Integrity

    3.4.4      Message Signature Functions

    3.4.4.1   Without Extended Session Security

    3.4.4.2   With Extended Session Security

    3.4.8      GSS_GetMICEx() Call

    3.4.8.1   Signature Creation for GSS_GetMICEx()

    3.4.9      GSS_VerifyMICEx() Call

    3.4.9.1   Signature Creation for GSS_VerifyMICEx()

    5.1          Security Considerations for Implementers

    5.2          Index of Security Parameters

    Security parameter

    Section

    MD4/MD5 usage in NTLM v1

    3.3.1

    MD4/MD5 usage in NTLM v2

    3.3.2

    MD5/RC4 usage during session security

    3.4

     

    6              Appendix A: Cryptographic Operations Reference

    In the algorithms provided in this documentation, pseudocode is provided to illustrate the process used to compute keys and perform other cryptographic operations prior to protocol exchange. The following table defines the general purpose functions and operations used in this pseudocode.

    . . .

    [MS-KILE]

    3.4.5.1   Three-Leg DCE-Style Mutual Authentication

    3.4.5.7   GSS_VerifyMICEx() Call

    3.4.5.6   GSS_GetMICEx() Call

    [RFC4121] The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2

    Wednesday, May 18, 2016 4:31 PM
    Moderator
  • 2)

    The algorithms used for message confidentiality (auth_level RPC_C_AUTHN_LEVEL_PKT_PRIVACY) depend on the security provider (see auth_type and [MS-RPCE] 2.2.1.1.7 Security Providers) and the negotiated parameters for that specific provider.

    [MS-RPCE] defines the use of GSS API [RFC2743]. "Confidentiality" means that the segment MUST be encrypted (conf_req_flag is TRUE per [RFC2743] section 2.3.3). The processing in the calls to GSS_Wrap, GSS_Unwrap, GSS_WrapEx, or Gss_UnwrapEx is transparent to MS-RPCE.

    Please see MS-NLMP, MS-KILE, or whichever is the specification of the authentication protocol of interest.

    [MS-NLMP]

    3.4.6      GSS_WrapEx() Call

    3.4.6.1   Signature Creation for GSS_WrapEx()

    3.4.7      GSS_UnwrapEx() Call

    3.4.7.1   Signature Creation for GSS_UnwrapEx()

    [MS-KILE]

    3.4.5.4   GSS_WrapEx() Call

    3.4.5.4.1 Kerberos Binding of GSS_WrapEx()

    3.4.5.5   GSS_UnwrapEx() Call

     

    [MS-RPCE]

     

    2.2.1.1.7               Security Providers

    These extensions do not require support for the dce_c_rpc_authn_protocol_krb5 security provider, as specified in [C706] section 13. All of the requirements specified in [C706] section 13 are removed by these extensions.<22>

     These extensions specify the following values for the security provider.

    Name

    Value

    Security provider

    RPC_C_AUTHN_NONE

    0x00

    No Authentication

    RPC_C_AUTHN_GSS_NEGOTIATE

    0x09

     SPNEGO

    RPC_C_AUTHN_WINNT

    0x0A

    NTLM

    RPC_C_AUTHN_GSS_SCHANNEL

    0x0E

    TLS

    RPC_C_AUTHN_GSS_KERBEROS

    0x10

    Kerberos

    RPC_C_AUTHN_NETLOGON

    0x44

    Netlogon

    RPC_C_AUTHN_DEFAULT

    0xFF

    Same as RPC_C_AUTHN_WINNT

    Wednesday, May 18, 2016 4:31 PM
    Moderator
  • 3)

    The auth_type identifies the security provider. The algorithms will depend on the parameters negotiated within that specific security context.

    If your Bind auth_type is "NTLMSSP (10)", please refer to MS-NLMP Section “2.2.2.5 NEGOTIATE” to interpret each bit of the NegotiateFlags.

    In a network parser of the NTLM NegotiateFlags, the bits you have mentioned look as follow. Please refer to MS-NLMP for interpretation and processing rules.

    Negotiate128:                     (..1.............................) Requests 128-bit session key negotiation.

    Negotiate56:                      (1...............................) Requesting 56-bit encryption

    As mentioned in [MS-NLMP] 5.1 Security Considerations for Implementers:

    Implementers need to be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms ([RFC1321]) for integrity, and it uses RC4 for encryption. Deriving a key from a password is as specified in [RFC1320] and [FIPS46-2]. . . .

     

     [MS-NLMP] 2.2.2.5 NEGOTIATE

    https://msdn.microsoft.com/en-us/library/cc236650.aspx

     

    W (1 bit): If set, requests 56-bit encryption. If the client sends NTLMSSP_NEGOTIATE_SEAL or NTLMSSP_NEGOTIATE_SIGN with NTLMSSP_NEGOTIATE_56 to the server in the NEGOTIATE_MESSAGE, the server MUST return NTLMSSP_NEGOTIATE_56 to the client in the CHALLENGE_MESSAGE.   Otherwise it is ignored. If both NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128 are requested and supported by the client and server, NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128 will both be returned to the client. Clients and servers that set NTLMSSP_NEGOTIATE_SEAL SHOULD set NTLMSSP_NEGOTIATE_56 if it is supported. An alternate name for this field is NTLMSSP_NEGOTIATE_56.

    V (1 bit): If set, requests an explicit keyexchange. This capability SHOULD be used because it improves security for message integrity or confidentiality. See sections 3.2.5.1.2, 3.2.5.2.1, and 3.2.5.2.2for details. An alternate name for this field is NTLMSSP_NEGOTIATE_KEY_EXCH.

    U (1 bit): If set, requests 128-bit session keynegotiation. An alternate name for this field is NTLMSSP_NEGOTIATE_128. If the client sends NTLMSSP_NEGOTIATE_128 to the server in the NEGOTIATE_MESSAGE, the server MUST return NTLMSSP_NEGOTIATE_128 to the client in the CHALLENGE_MESSAGE only if the client sets NTLMSSP_NEGOTIATE_SEAL or NTLMSSP_NEGOTIATE_SIGN. Otherwise it is ignored. If both NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128 are requested and supported by the client and server, NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128 will both be returned to the client. Clients and servers that set NTLMSSP_NEGOTIATE_SEAL SHOULD set NTLMSSP_NEGOTIATE_128 if it is supported. An alternate name for this field is NTLMSSP_NEGOTIATE_128.<21>

    . . .

    E (1 bit): If set, requests session key negotiation for message confidentiality. If the client sends NTLMSSP_NEGOTIATE_SEAL to the server in the NEGOTIATE_MESSAGE, the server MUST return NTLMSSP_NEGOTIATE_SEAL to the client in the CHALLENGE_MESSAGE. Clients and servers that set NTLMSSP_NEGOTIATE_SEAL SHOULD always set NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128, if they are supported. An alternate name for this field is NTLMSSP_NEGOTIATE_SEAL.

    . . .



    Wednesday, May 18, 2016 4:32 PM
    Moderator

All replies

  • Hi Geoff,

    Thank you for contacting Microsoft Open Protocols support.  We have received the request and someone from the team will be in touch.

    Thank you,

    Nathan Manis

    Microsoft Open Specifications Support

    Thursday, May 12, 2016 2:15 AM
    Moderator
  • Great!  Thank you for the help.

    Is there an ETA on this?

    Geoff

    Monday, May 16, 2016 2:14 PM
  • Hi Geoff,

    For Microsoft implementation, MS-RPCE should be the starting point.  I am reviewing your specific questions and will respond with specific references. In a nutshell, it should be MS-RPCE, DCE 1.1 RPC, MS-NTLM, MS-KILE, GSS API RFCs.

    [MS-RPCE]: Remote Procedure Call Protocol Extensions
    https://msdn.microsoft.com/en-us/library/cc243560.aspx

    The Remote Procedure Call Protocol Extensions define a set of extensions to the DCE 1.1: Remote Procedure Call (RPC), as specified in [C706]. This specification assumes that the reader has familiarity with the concepts and requirements specified in [C706]. Concepts and requirements specified in [C706] are not repeated in this specification, except where required to specify how the definitions are extended. The reader may also find it helpful to be familiar with [C441], which describes the Generic Security Service API (GSS-API) Base.

    Thank you,

    Edgar

    Monday, May 16, 2016 5:07 PM
    Moderator
  • 0)

    In the following I will give a series of references for illustration. Please read through the respective specs (Microsoft specific, or standards) for a complete story.

    Wednesday, May 18, 2016 4:30 PM
    Moderator
  • 1)

    The algorithms used for message integrity (auth_level RPC_C_AUTHN_LEVEL_PKT_INTEGRITY) depend on the security provider (see auth_type and [MS-RPCE] 2.2.1.1.7 Security Providers) and the negotiated parameters for that specific provider.

    [MS-RPCE] defines the use of GSS API [RFC2743]. The processing in the calls to GSS_GetMIC() or GSS_VerifyMIC() is transparent to MS-RPCE.

    The specification provides references to various authentication protocols MS-APDS, MS-NLMP, MS-KILE, RFC4121, MS-SPNG, etc.

    Here are some excerpts:

     

    [MS-RPCE]

     

    2.2.1.1.7               Security Providers

    These extensions do not require support for the dce_c_rpc_authn_protocol_krb5 security provider, as specified in [C706] section 13. All of the requirements specified in [C706] section 13 are removed by these extensions.<22>

     These extensions specify the following values for the security provider.

    Name

    Value

    Security provider

    RPC_C_AUTHN_NONE

    0x00

    No Authentication

    RPC_C_AUTHN_GSS_NEGOTIATE

    0x09

     SPNEGO

    RPC_C_AUTHN_WINNT

    0x0A

    NTLM

    RPC_C_AUTHN_GSS_SCHANNEL

    0x0E

    TLS

    RPC_C_AUTHN_GSS_KERBEROS

    0x10

    Kerberos

    RPC_C_AUTHN_NETLOGON

    0x44

    Netlogon

    RPC_C_AUTHN_DEFAULT

    0xFF

    Same as RPC_C_AUTHN_WINNT

    On the client side, if the higher level protocol requests RPC_C_AUTHN_DEFAULT, the implementation MUST use RPC_C_AUTHN_WINNT instead.

    The security provider underlying protocol and implementation defines the number of legs and whether the number of legs is odd or even that are used in the token exchange process that builds a security context. This information MAY be used for the processing of PDUs during that process. 

    These extensions specify the following number (if known) or even/oddness of the legs needed to build a security context.

    Name

    # of or Even # of Token Exchange Legs

    RPC_C_AUTHN_NONE

    even

    RPC_C_AUTHN_GSS_NEGOTIATE

    even

    RPC_C_AUTHN_WINNT

    3

    RPC_C_AUTHN_GSS_SCHANNEL

    even

    RPC_C_AUTHN_GSS_KERBEROS

    even

    RPC_C_AUTHN_NETLOGON

    3

    RPC_C_AUTHN_DEFAULT

    unknown

     

    <22> Section 2.2.1.1.7: Without the installation of additional software, Windows supports the following authentication types:

    Security Provider

    • Security Provider Simple and Protected GSS-API Negotiation Mechanism (SPNEGO)
    • NT LAN Manager (NTLM)
    • Kerberos
    • Netlogon

     

    2.2.1.1.8        Authentication Levels

    These extensions specify the following values for the authentication levels.

    Name

    Value

    Meaning

    RPC_C_AUTHN_LEVEL_DEFAULT

    0x00

    Same as RPC_C_AUTHN_LEVEL_CONNECT

    RPC_C_AUTHN_LEVEL_NONE

    0x01

    No authentication.

    RPC_C_AUTHN_LEVEL_CONNECT

    0x02

    Authenticates the credentials of the client and server.

    RPC_C_AUTHN_LEVEL_CALL

    0x03

    Same as RPC_C_AUTHN_LEVEL_PKT.

    RPC_C_AUTHN_LEVEL_PKT

    0x04

    Same as RPC_C_AUTHN_LEVEL_CONNECT but also prevents replay attacks.

    RPC_C_AUTHN_LEVEL_PKT_INTEGRITY

    0x05

    Same as RPC_C_AUTHN_LEVEL_PKT but also verifies that none of the data transferred between the client and server has been modified.

    RPC_C_AUTHN_LEVEL_PKT_PRIVACY

    0x06

    Same as RPC_C_AUTHN_LEVEL_PKT_INTEGRITY but also ensures that the data transferred can only be seen unencrypted by the client and the server.

    If the higher-level application or protocol requests an authentication level that the implementation or security provider does not support, it MUST upgrade the request to the next highest supported level. RPC_C_AUTHN_LEVEL_PKT_PRIVACY MUST be supported.

    On the client side, if the higher-level protocol requests RPC_C_AUTHN_LEVEL_CALL, the implementation MUST upgrade it to RPC_C_AUTHN_LEVEL_PKT. Similarly, on the server side, if the auth_level field of the sec_trailer structure as specified in sections 2.2.2.11 and 2.2.3.4 is RPC_C_AUTHN_LEVEL_CALL, the implementation MUST process it in the same manner as a packet with auth_level RPC_C_AUTHN_LEVEL_PKT.

    Also, on the client side, if the higher-level protocol requests RPC_C_AUTHN_LEVEL_DEFAULT, the implementation MUST use RPC_C_AUTHN_LEVEL_CONNECT instead.

     

    2.2.2.11                sec_trailer Structure

    auth_type (1 byte):  MUST contain an authentication type. For information on how this is used, see sections 3.1.1.1.1, 3.3.1.5.2, and 3.1.3.1.1. If a request or response is fragmented, all PDUs from that request or response MUST have the same auth_type.

    auth_level (1 byte):  MUST contain one of the authentication levels as specified in section 2.2.1.1.8. The value serves a dual purpose. The first purpose is to specify what security protection is applied to what segment of the PDU, as specified in section 3.3.1.5.2. The second purpose is to serve as a parameter to the security provider that it SHOULD use to determine how to provide protection for the respective PDU segment. For information on how security providers use that, see the documentation for the respective security provider. If a request or response is fragmented, all PDUs from that request or response MUST have the same auth_level.

     

    2.2.2.12                Authentication Tokens

    These extensions require the conceptual model specified in [RFC2743] for all interactions with all security providers. An implementation instructs the Generic Security Services (GSS)-API–compatible security providers to operate in a distributed computing environment (DCE)–compatible manner by setting the DCE Style protocol variable. The following table details what PDU type MUST carry (in its auth_ token segment) the output of what GSS [GSS] call during processing, as specified in section 3.3.1.5.2.2.

     RPC PDU name

     GSS call producing auth_value

     Bind

    First call to GSS_Init_sec_context, as specified in [RFC2743] section 2.2.1.

     bind_ack

    First call to GSS_Accept_sec_context, as specified in [RFC2743] section 2.2.2.

     alter_context, rpc_auth_3

    Second and subsequent calls to GSS_Init_sec_context, as specified in [RFC2743] section 2.2.1.

     alter_context_resp

    Second and subsequent calls to GSS_Accept_sec_context, as specified in [RFC2743] section 2.2.2.

    Request

    If the auth_level (as specified in section 2.2.2.11) is RPC_C_AUTHN_LEVEL_PKT_PRIVACY, call to GSS_WrapEx; else call to GSS_GetMICEx. See section 3.3.1.5.2.2 for details.

    Response

    If the auth_level (as specified in section 2.2.2.11) is RPC_C_AUTHN_LEVEL_PKT_PRIVACY, call to GSS_UnwrapEx; else call to GSS_VerifyMICEx. See section 3.3.1.5.2.2 for details.

     

     

    3.3.1.5.2.1           Building a Security Context

    Once a client decides on the type of PDU, it MUST start the sequence by requesting the security provider for an authentication token using an implementation-specific equivalent of the abstract GSS_Init_sec_context call, as specified in [RFC2743]. See [MS-APDS] section 3.1.5 for NTLM details and see [RFC4121] and [MS-KILE] section 3.2.5.2 for Kerberos details. This PDU MUST be sent to the server with authentication information added, as specified in section 2.2.2.11.

     

    3.3.1.5.2.2           Using a Security Context

    The following table specifies the abstract capability that the RPC runtime MUST request from the security provider when the security context is being created. The capabilities in the following table are further specified in [RFC2743] section 1.2.1.2. The capabilities requested at each level include the ones requested at the previous level.

     Authentication level

     Capability requested

    RPC_C_AUTHN_LEVEL_CONNECT

    None

    RPC_C_AUTHN_LEVEL_PKT

    Replay Detect

    RPC_C_AUTHN_LEVEL_PKT_INTEGRITY

    Sequence Detect, integrity

    RPC_C_AUTHN_LEVEL_PKT_PRIVACY

    Confidentiality

    . . .

    If the client and server Supports Header Signing Flag is TRUE, the party that sends the PDU asks the security provider to apply the following protection to the different PDU segments.

     Authentication level

     PDU header

     PDU body

     sec_trailer

    RPC_C_AUTHN_LEVEL_CONNECT

    None

    None

    None

    RPC_C_AUTHN_LEVEL_PKT

    None

    None

    None

    RPC_C_AUTHN_LEVEL_PKT_INTEGRITY

    Integrity

    Integrity

    Integrity

    RPC_C_AUTHN_LEVEL_PKT_PRIVACY

    Integrity

    Confidentiality

    Integrity

     

    For [MS-NLMP], look at “Section 6            Appendix A: Cryptographic Operations Reference”

    And see how various crypto algorithms are used in the document, e.g. DES, MD4, MD5, RC4.

     

    [MS-NLMP]

    3.3          NTLM v1 and NTLM v2 Messages

    3.3.1      NTLM v1 Authentication

    3.3.1.5.2.2           Using a Security Context

    3.3.2      NTLM v2 Authentication

    3.4.2      Message Integrity

    3.4.4      Message Signature Functions

    3.4.4.1   Without Extended Session Security

    3.4.4.2   With Extended Session Security

    3.4.8      GSS_GetMICEx() Call

    3.4.8.1   Signature Creation for GSS_GetMICEx()

    3.4.9      GSS_VerifyMICEx() Call

    3.4.9.1   Signature Creation for GSS_VerifyMICEx()

    5.1          Security Considerations for Implementers

    5.2          Index of Security Parameters

    Security parameter

    Section

    MD4/MD5 usage in NTLM v1

    3.3.1

    MD4/MD5 usage in NTLM v2

    3.3.2

    MD5/RC4 usage during session security

    3.4

     

    6              Appendix A: Cryptographic Operations Reference

    In the algorithms provided in this documentation, pseudocode is provided to illustrate the process used to compute keys and perform other cryptographic operations prior to protocol exchange. The following table defines the general purpose functions and operations used in this pseudocode.

    . . .

    [MS-KILE]

    3.4.5.1   Three-Leg DCE-Style Mutual Authentication

    3.4.5.7   GSS_VerifyMICEx() Call

    3.4.5.6   GSS_GetMICEx() Call

    [RFC4121] The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2

    Wednesday, May 18, 2016 4:31 PM
    Moderator
  • 2)

    The algorithms used for message confidentiality (auth_level RPC_C_AUTHN_LEVEL_PKT_PRIVACY) depend on the security provider (see auth_type and [MS-RPCE] 2.2.1.1.7 Security Providers) and the negotiated parameters for that specific provider.

    [MS-RPCE] defines the use of GSS API [RFC2743]. "Confidentiality" means that the segment MUST be encrypted (conf_req_flag is TRUE per [RFC2743] section 2.3.3). The processing in the calls to GSS_Wrap, GSS_Unwrap, GSS_WrapEx, or Gss_UnwrapEx is transparent to MS-RPCE.

    Please see MS-NLMP, MS-KILE, or whichever is the specification of the authentication protocol of interest.

    [MS-NLMP]

    3.4.6      GSS_WrapEx() Call

    3.4.6.1   Signature Creation for GSS_WrapEx()

    3.4.7      GSS_UnwrapEx() Call

    3.4.7.1   Signature Creation for GSS_UnwrapEx()

    [MS-KILE]

    3.4.5.4   GSS_WrapEx() Call

    3.4.5.4.1 Kerberos Binding of GSS_WrapEx()

    3.4.5.5   GSS_UnwrapEx() Call

     

    [MS-RPCE]

     

    2.2.1.1.7               Security Providers

    These extensions do not require support for the dce_c_rpc_authn_protocol_krb5 security provider, as specified in [C706] section 13. All of the requirements specified in [C706] section 13 are removed by these extensions.<22>

     These extensions specify the following values for the security provider.

    Name

    Value

    Security provider

    RPC_C_AUTHN_NONE

    0x00

    No Authentication

    RPC_C_AUTHN_GSS_NEGOTIATE

    0x09

     SPNEGO

    RPC_C_AUTHN_WINNT

    0x0A

    NTLM

    RPC_C_AUTHN_GSS_SCHANNEL

    0x0E

    TLS

    RPC_C_AUTHN_GSS_KERBEROS

    0x10

    Kerberos

    RPC_C_AUTHN_NETLOGON

    0x44

    Netlogon

    RPC_C_AUTHN_DEFAULT

    0xFF

    Same as RPC_C_AUTHN_WINNT

    Wednesday, May 18, 2016 4:31 PM
    Moderator
  • 3)

    The auth_type identifies the security provider. The algorithms will depend on the parameters negotiated within that specific security context.

    If your Bind auth_type is "NTLMSSP (10)", please refer to MS-NLMP Section “2.2.2.5 NEGOTIATE” to interpret each bit of the NegotiateFlags.

    In a network parser of the NTLM NegotiateFlags, the bits you have mentioned look as follow. Please refer to MS-NLMP for interpretation and processing rules.

    Negotiate128:                     (..1.............................) Requests 128-bit session key negotiation.

    Negotiate56:                      (1...............................) Requesting 56-bit encryption

    As mentioned in [MS-NLMP] 5.1 Security Considerations for Implementers:

    Implementers need to be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms ([RFC1321]) for integrity, and it uses RC4 for encryption. Deriving a key from a password is as specified in [RFC1320] and [FIPS46-2]. . . .

     

     [MS-NLMP] 2.2.2.5 NEGOTIATE

    https://msdn.microsoft.com/en-us/library/cc236650.aspx

     

    W (1 bit): If set, requests 56-bit encryption. If the client sends NTLMSSP_NEGOTIATE_SEAL or NTLMSSP_NEGOTIATE_SIGN with NTLMSSP_NEGOTIATE_56 to the server in the NEGOTIATE_MESSAGE, the server MUST return NTLMSSP_NEGOTIATE_56 to the client in the CHALLENGE_MESSAGE.   Otherwise it is ignored. If both NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128 are requested and supported by the client and server, NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128 will both be returned to the client. Clients and servers that set NTLMSSP_NEGOTIATE_SEAL SHOULD set NTLMSSP_NEGOTIATE_56 if it is supported. An alternate name for this field is NTLMSSP_NEGOTIATE_56.

    V (1 bit): If set, requests an explicit keyexchange. This capability SHOULD be used because it improves security for message integrity or confidentiality. See sections 3.2.5.1.2, 3.2.5.2.1, and 3.2.5.2.2for details. An alternate name for this field is NTLMSSP_NEGOTIATE_KEY_EXCH.

    U (1 bit): If set, requests 128-bit session keynegotiation. An alternate name for this field is NTLMSSP_NEGOTIATE_128. If the client sends NTLMSSP_NEGOTIATE_128 to the server in the NEGOTIATE_MESSAGE, the server MUST return NTLMSSP_NEGOTIATE_128 to the client in the CHALLENGE_MESSAGE only if the client sets NTLMSSP_NEGOTIATE_SEAL or NTLMSSP_NEGOTIATE_SIGN. Otherwise it is ignored. If both NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128 are requested and supported by the client and server, NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128 will both be returned to the client. Clients and servers that set NTLMSSP_NEGOTIATE_SEAL SHOULD set NTLMSSP_NEGOTIATE_128 if it is supported. An alternate name for this field is NTLMSSP_NEGOTIATE_128.<21>

    . . .

    E (1 bit): If set, requests session key negotiation for message confidentiality. If the client sends NTLMSSP_NEGOTIATE_SEAL to the server in the NEGOTIATE_MESSAGE, the server MUST return NTLMSSP_NEGOTIATE_SEAL to the client in the CHALLENGE_MESSAGE. Clients and servers that set NTLMSSP_NEGOTIATE_SEAL SHOULD always set NTLMSSP_NEGOTIATE_56 and NTLMSSP_NEGOTIATE_128, if they are supported. An alternate name for this field is NTLMSSP_NEGOTIATE_SEAL.

    . . .



    Wednesday, May 18, 2016 4:32 PM
    Moderator