none
MS-WSMV CredSSP Message Encryption RRS feed

  • Question

  • 
    Hi

    I'm trying to get message encryption for MS-WSMV working when using CredSSP authentication and am coming across some issues when dealing with different cipher suites. I am creating the message payload to send to the server but the issue seems to be around the calculation of Length-Field. According to the MS-WSMV docs https://msdn.microsoft.com/en-us/library/dd341036.aspx...

    The Length-Field MUST follow immediately after the previous token. It MUST be a 32-bit unsigned integer that specifies the length of any trailer portion of the Message field.

    This does not mean much to me but currently I am using this logic to determine the value. 

    len(encrypted_message) - len(original_message) - constant

    The value of constant is a value I am setting manually based on the cipher suite and protocol negotiated in the TLS handshake. These are the values I've had to use for constant so far for various protocol and cipher suites

    Constant = 5 (TLS 1.0)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

    Constant = 13 (TLS 1.2)
    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

    Constant = 21 (TLS 1.2)
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

    Unfortunately this doesn't help me too much as I need a way to determining the Length-Field value dynamically and I am trying to avoid case statements with values that can potentially change in the future. Is there some sort of algorithm I need to use to be able to determine this value or is someone able to shed some more details on that field from MS-WSMV as it seems a bit vague to me.

    On a side note the library I am developing on is cross platform so I don't access access to any Win32 APIs to be able to do this for me. The code I have so far can be found at https://github.com/jborean93/pywinrm/blob/ntlm-encryption/winrm/encryption.py.

    Thanks

    Jordan

    Monday, July 10, 2017 3:49 AM

Answers

All replies

  • Hello Jodan:

    Thank you for your inquiry about Microsoft office specification. We have created an incident for investigating this issue. One of the Open specifications team member will contact you shortly.

    Thanks.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Monday, July 10, 2017 2:39 PM
  • Hello Jordan,
    I will be working with you on this issue. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Monday, July 10, 2017 7:48 PM
    Moderator
  • Hey Sreekanth

    Were you able to find out more info, I've tried doing some investigation myself and the only thing I can thing of that would relate to this length is the padding or MAC fields https://en.wikipedia.org/wiki/Transport_Layer_Security#Application_protocol. It would be good to get confirmation or more concrete information about this if possible.

    Thanks

    Jordan

    Sunday, July 16, 2017 10:56 PM
  • Hello Jordan,
    I'm setting up a local repro to study the code path. Thank you for your patience. Should have an answer soon.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Monday, July 17, 2017 9:13 PM
    Moderator
  • Hello Jordan,
    Length-Field holds the size of the cipher trailer of encrypted data. On Windows platforms, it can be retrieved from SecPkgContext_StreamSizes via  QueryContextAttributes function. Your libraries may have similar mechanism to access this value.

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa380503(v=vs.85).aspx
    https://msdn.microsoft.com/en-us/library/windows/desktop/aa380098(v=vs.85).aspx

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Tuesday, July 18, 2017 5:45 PM
    Moderator
  • Hey Sreekanth

    Thanks for the reply, this is what I feared as it doesn't seem like OpenSSL or any other codebase has a method available to achieve the same think as SecPkgContext_StreamSizes. Unfortunately it means I will have to write the logic myself and go from there. I'll post more details once I have figured it out here in case anybody in the future needs to refer back tot his.

    I do have one more question around CredSSP if that is ok. Currently with NTLM and Kerberos there is the option to add channel bindings to the auth process through SEC_CHANNEL_BINDINGS https://msdn.microsoft.com/en-us/library/windows/desktop/dd919963(v=vs.85).aspx. I was trying this out and it doesn't seem like this is required with CredSSP authentication as even if the WinRM service has set CbtHardeningLevel to Strict the auth still passes even if I don't bind the channel bindings. Are you able to confirm if CredSSP doesn't need CBT?

    Thanks

    Jordan

    Wednesday, July 19, 2017 8:57 PM
  • Hi Jordan, I will do some research and confirm.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Thursday, July 20, 2017 2:02 AM
    Moderator
  • Hello Jordan,
    Section 3.1.5 in [MS-CSSP] describes how TLS session-binding is performed to prevent MITM attack. This does not use Channel binding token since we explicitly verify the certificate by sending encrypted public key. So this explains why setting CbtHardeningLevel to Strict has no effect.


    2.2.1 TSRequest
    https://msdn.microsoft.com/en-us/library/cc226780.aspx

    3.1.5 Processing Events and Sequencing Rules
    https://msdn.microsoft.com/en-us/library/cc226791.aspx


    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

    Monday, July 24, 2017 9:09 PM
    Moderator
  • Sorry for the late reply but thanks Sreekanth for your help.

    In case anyone is interested, I've tried to implement this logic here https://github.com/jborean93/requests-credssp/blob/master/tests/functional/test_credssp_connection.py#L113-L154 and haven't come across any issues so far.

    Tuesday, August 29, 2017 4:56 AM