none
Fetch the Binary Security Token (BST) provided to client during enrollment in SyncML sessions RRS feed

  • Question

  • Hi,

    During enrollment, a security token is given to the client (During discovery service). Is there any way that that token can be obtained from device within a <Get> element in the SyncML sessions ?

    I have a requirement to validate this token and in turn validate the device by my custom server.

    My reference of CSPs was:

    https://msdn.microsoft.com/en-us/library/windows/hardware/dn920025%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

    From here I found a Provisioning CSP:

    https://msdn.microsoft.com/en-us/library/windows/hardware/mt203665(v=vs.85).aspx

    So I sent it in a <Get> command, however the client returned following in the <Status> block:

     <Status>
             <CmdID>46</CmdID>
             <MsgRef>1</MsgRef>
             <CmdRef>5</CmdRef>
             <Cmd>Get</Cmd>
             <TargetRef>./Vendor/MSFT/Provisioning/Enrollments/UPN/Secret</TargetRef>
             <Data>404</Data>
    </Status>

    Can I not fetch this token at all ? Need urgent help here please..

    Wednesday, March 30, 2016 10:28 AM

Answers

  • Here is a summary of the answer we delivered offline:

    Dhruvesh,

     

    Please start with MS-MDM Section 1.3 Overview and 2.1 Transport, and most importantly [OMA-DMP1.2.1]. The client and server do certificate-based authentication over an SSL channel.

     

    “The MDM server can identify a connecting device by examining the device client identity certificate issued earlier at MDM enrollment time. The device client identity certificate is used to establish the SSL/TLS connection to the MDM server.”

     

    Here are a few excerpts:

     

    MS-MDM

     

    1.3 Overview

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

     

    A DM session can be divided into two phases:

    • Setup phase: In response to a trigger event, a client sends an initiating message to a DM server. The client and server exchange needed authentication and client information. This phase is represented by steps 1, 2, and 3 in the following table.
    • Management phase: The DM server is in control. It sends management commands to the client, and the phone responds. The second phase ends when the DM server stops sending commands and terminates the session. This phase is represented by steps 3, 4, and 5 in the following table.

    Step

    Action

    Description

    1

    The client task schedule invokes the device management client.

    At the scheduled time, the client is invoked periodically to call back to the enterprise management server over HTTPS.

    2

    The client sends a message, over an IP connection, to initiate the session.

    This message includes client information and credentials. The client and server do certificate-based authentication over an SSL channel.

    3

    The server responds, over an IP connection (HTTPS).

    The server sends initial device management commands, if any.

    4

    The client responds to server management commands.

    This message includes the results of performing the specified device management operations.

    5

    The server terminates the session or sends another command.

    The session ends, or step 4 is repeated.

     

    1.3.1 Server requirements for the OMA Device Management Protocol

    The following are the general server requirements for using the OMA Device Management Protocol (OMA-DM), as specified in [OMA-DMP1.2.1], to manage the client:

    The OMA-DM server MUST support the OMA-DM version 2.1 or later protocol.

    Secure Sockets Layer (SSL) MUST be on the OMA-DM server, and it MUST provide server certificate-based authentication, data integrity checking, and data encryption. If the certificate is not issued by a commercial certification authority whose root certificate is preinstalled in the client, you MUST provision the company's root certificate in the client's ROOT store.

    To authenticate the client, you MUST use either Basic or MD5 client authentication at the application level. At the SSL level, use client certificate-based authentication.

    The server MD5 nonce MUST be renewed in each DM session for the next DM session. The DM client sends the new server nonce for the next session to the server by using the Status element in every DM session.

    The MD5 binary nonce is sent over XML in B64-encoded format, but the octal form of the binary data SHOULD be used when the server calculates the hash.

    For more information about Basic or MD5 client authentication, MD5 hash generation, and MD5 nonce, see the OMA Device Management Security specification ([OMA-DMS1.2.1]) and OMA Device Management Protocol specification ([OMA-DMP1.2.1]).

    2.1 Transport

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

    Note 4: When an MDM device establishes an SSL/TLS connection with the MDM server through SSL bridging–enabled proxies, the client device identity certificate obtained by the target MDM server from transport security will be the intermediate proxy server client authentication certificate instead of the actual device client identity certificate.<4> It is required that the MDM client and MDM server have a mechanism to send and verify device identity securely in this case. This is achieved by including a client certificate related HTTP header in a DM package. The MDM server can identify a connecting device by examining the device client identity certificate issued earlier at MDM enrollment time. The device client identity certificate is used to establish the SSL/TLS connection to the MDM server.

    • Every SyncML message that comes from the MDM client carries an additional HTTP header named MS-Signature and Authorization. This header contains a BASE64-encoded CMS (Cryptographic Message Syntax) Detached Signature of the complete SyncML message (SyncHdr, SyncBody) SHA-2 hash. Signing is performed using the private key of the device identify certificate.
    • The device identity certificate (public key) and PKCS9 UTC signing time stamp are included as part of the authenticated attributes in the signature.
    • This is an opt-in function. By default, the MDM client doesn’t sign the DM package. During MDM enrollment, the server could require the DM client to sign the outgoing MD package via RequireMessageSigning node in DMClient CSP. For more information about device enrollment and DMClient CSP, see [MS-MDE2].
    • The MDM server validates the signature, and time stamp using a device identity certificate. It ensures the device’s client identity certificate is valid (issued by MDM at enrollment time), the time is valid (optional), and the signature is valid and trusted by the MDM server as of today.

     

     

    Reference:

     

    [OMA-DMP1.2.1] Open Mobile Alliance, "OMA Device Management Protocol, Approved Version 1.2.1", OMA-TS-DM_Protocol-V1_2_1-20080617-A, June 2008, http://technical.openmobilealliance.org/Technical/release_program/docs/DM/V1_2_1-20080617-A/OMA-TS-DM_Protocol-V1_2_1-20080617-A.pdf

     

    The MS-MDE protocol sequence is as follows.

    [MS-MDE] https://msdn.microsoft.com/en-us/library/dn410708.aspx

    [MS-MDE]: Overview - msdn.microsoft.com

    msdn.microsoft.com

    MDE enables a device to be enrolled with the Device Management Service (DMS) through an Enrollment Service (ES), including the discovery of the Management Enrollment ...

     

     

    1.3 Overview

    MDE enables a device to be enrolled with the Device Management Service (DMS) through an Enrollment Service (ES), including the discovery of the Management Enrollment Service (MES) and enrollment with the ES. After a device is enrolled, the device can be managed with the DMS using MDM.

    The process for enrolling a device using MDE is shown in the following diagram.

    picte520d1ae-b7ba-f597-3ea9-d2ab0c83a453.jpg

    Figure 1: Typical sequence for enrolling a message using MDE

    The enrollment process consists of the following steps.

    1.       The user’s email name is entered via the enrollment client.
    2.       The enrollment client extracts the domain suffix from the email address, prepends the domain name with a well-known label, and resolves the address to the Discovery Service (DS). The administrator configures the network name resolution service (that is, the Domain Name System (DNS)) appropriately.
    3.       The enrollment client sends an HTTP GET request to the Discovery Service (DS) to validate the existence of the service endpoint.
    4.       The enrollment client sends a Discover message (section 3.1.4.1.1.1) to the Discovery Service (DS). The Discovery Service (DS) responds with a DiscoverResponse message (section 3.1.4.1.1.2) containing the Uniform Resource Locators (URLs) of service endpoints required for the following steps.
    5.       The enrollment client communicates with the security token service (STS) (section 3.2) to obtain a security token to authenticate with the ES.
    6.       The enrollment client sends a GetPolicies message (section 3.3.4.1.1.1) the ES endpoint [MS-XCEP] using the security token received in the previous step. The ES endpoint [MS-XCEP] responds with a GetPoliciesResponse message (section 3.3.4.1.1.2) containing the certificate policies required for the next step. For more information about these messages, see [MS-XCEP] sections 3.1.4.1.1.1 and 3.1.4.1.1.2.
    7.       Part a.The enrollment client can send a RequestSecurityToken message (section 3.4.4.1.1.1) to the ES endpoint [MS-WSTEP] using the security token received in step 4. The ES endpoint [MS-WSTEP] responds with a RequestSecurityTokenResponseCollection message (section 3.4.4.1.1.3) containing the identity and provisioning information for the device management client [MS-MDM]. For more information about these messages, see [MS-WSTEP] sections 3.1.4.1.1.1 and 3.1.4.1.1.2.

    Part b.The enrollment client can send a RequestSecurityTokenOnBehalfOf message (section 3.4.4.1.1.3) to the ES endpoint [MS-WSTEP] using the security token received in step 4. The ES endpoint [MS-WSTEP] responds with a RequestSecurityTokenResponseCollection message (section 3.4.4.1.1.3) containing the identity and provisioning information for the device management client [MS-MDM]. For more information about these messages, see [MS-WSTEP] sections 3.1.4.1.1.1 and 3.1.4.1.1.2.

    The steps for MDE device enrollment correspond to five phases as shown in the following diagram.

    pictb89214b1-4798-abd7-69b3-4c81b51cee79.jpg

    Figure 2: MDE device enrollment phases

    Wednesday, May 11, 2016 5:03 PM
    Moderator

All replies

  • Why am I getting 404 if the MSDN link specifies that Provisioning CSP is supported ??

          <Status>
             <CmdID>46</CmdID>
             <MsgRef>1</MsgRef>
             <CmdRef>5</CmdRef>
             <Cmd>Get</Cmd>
             <TargetRef>./Vendor/MSFT/Provisioning/Enrollments/UPN/Secret</TargetRef>
             <Data>404</Data>
          </Status>
          <Status>
             <CmdID>47</CmdID>
             <MsgRef>1</MsgRef>
             <CmdRef>5</CmdRef>
             <Cmd>Get</Cmd>
             <TargetRef>./Vendor/MSFT/Provisioning/Enrollments/UPN/AuthPolicy</TargetRef>
             <Data>404</Data>
          </Status>
          <Status>
             <CmdID>48</CmdID>
             <MsgRef>1</MsgRef>
             <CmdRef>5</CmdRef>
             <Cmd>Get</Cmd>
             <TargetRef>./Vendor/MSFT/Provisioning/Enrollments/UPN/DiscoveryServiceFullURL</TargetRef>
             <Data>404</Data>
          </Status>
          <Status>
             <CmdID>49</CmdID>
             <MsgRef>1</MsgRef>
             <CmdRef>5</CmdRef>
             <Cmd>Get</Cmd>
             <TargetRef>./Vendor/MSFT/Provisioning/Enrollments/UPN/PolicyServiceFullURL</TargetRef>
             <Data>404</Data>
          </Status>
          <Status>
             <CmdID>50</CmdID>
             <MsgRef>1</MsgRef>
             <CmdRef>5</CmdRef>
             <Cmd>Get</Cmd>
             <TargetRef>./Vendor/MSFT/Provisioning/Enrollments/UPN/EnrollmentServiceFullURL</TargetRef>
             <Data>404</Data>
          </Status>

    Wednesday, March 30, 2016 1:22 PM
  • Hi DhruveshRathore,

    Thank you for your question regarding Binary Security Token and SyncML. One of the Open Specifications team members will respond to begin working with you shortly.

    Best regards,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications

    Wednesday, March 30, 2016 3:06 PM
    Moderator
  • Hi,

    I am looking into this and will follow-up.

    Thank you,

    Edgar

    Wednesday, March 30, 2016 9:30 PM
    Moderator
  • Hi,

    Has anyone come across a solution or approach to the above problem ??

    Thanks,

    Dhruvesh

    Friday, April 1, 2016 5:12 PM
  • Hi,

    Any update on the same Tom. Thanks in anticipation.

    Regards,

    Dhruvesh

    Monday, April 4, 2016 5:08 AM
  • Dhruvesh,

    Can you send a email to my attention to this address: dochelp <at > microsoft < dot > com

    Please mention this thread.

    I'd like to learn about what you are trying to achieve. Anything necessary should be available in the specs. Many vendors have successfully implemented MDM servers.

    Thanks,

    Edgar

    Tuesday, April 5, 2016 3:22 PM
    Moderator
  • Will do Edgar. I'll send you a mail.

    Regards

    Thursday, April 7, 2016 9:39 AM
  • Here is a summary of the answer we delivered offline:

    Dhruvesh,

     

    Please start with MS-MDM Section 1.3 Overview and 2.1 Transport, and most importantly [OMA-DMP1.2.1]. The client and server do certificate-based authentication over an SSL channel.

     

    “The MDM server can identify a connecting device by examining the device client identity certificate issued earlier at MDM enrollment time. The device client identity certificate is used to establish the SSL/TLS connection to the MDM server.”

     

    Here are a few excerpts:

     

    MS-MDM

     

    1.3 Overview

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

     

    A DM session can be divided into two phases:

    • Setup phase: In response to a trigger event, a client sends an initiating message to a DM server. The client and server exchange needed authentication and client information. This phase is represented by steps 1, 2, and 3 in the following table.
    • Management phase: The DM server is in control. It sends management commands to the client, and the phone responds. The second phase ends when the DM server stops sending commands and terminates the session. This phase is represented by steps 3, 4, and 5 in the following table.

    Step

    Action

    Description

    1

    The client task schedule invokes the device management client.

    At the scheduled time, the client is invoked periodically to call back to the enterprise management server over HTTPS.

    2

    The client sends a message, over an IP connection, to initiate the session.

    This message includes client information and credentials. The client and server do certificate-based authentication over an SSL channel.

    3

    The server responds, over an IP connection (HTTPS).

    The server sends initial device management commands, if any.

    4

    The client responds to server management commands.

    This message includes the results of performing the specified device management operations.

    5

    The server terminates the session or sends another command.

    The session ends, or step 4 is repeated.

     

    1.3.1 Server requirements for the OMA Device Management Protocol

    The following are the general server requirements for using the OMA Device Management Protocol (OMA-DM), as specified in [OMA-DMP1.2.1], to manage the client:

    The OMA-DM server MUST support the OMA-DM version 2.1 or later protocol.

    Secure Sockets Layer (SSL) MUST be on the OMA-DM server, and it MUST provide server certificate-based authentication, data integrity checking, and data encryption. If the certificate is not issued by a commercial certification authority whose root certificate is preinstalled in the client, you MUST provision the company's root certificate in the client's ROOT store.

    To authenticate the client, you MUST use either Basic or MD5 client authentication at the application level. At the SSL level, use client certificate-based authentication.

    The server MD5 nonce MUST be renewed in each DM session for the next DM session. The DM client sends the new server nonce for the next session to the server by using the Status element in every DM session.

    The MD5 binary nonce is sent over XML in B64-encoded format, but the octal form of the binary data SHOULD be used when the server calculates the hash.

    For more information about Basic or MD5 client authentication, MD5 hash generation, and MD5 nonce, see the OMA Device Management Security specification ([OMA-DMS1.2.1]) and OMA Device Management Protocol specification ([OMA-DMP1.2.1]).

    2.1 Transport

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

    Note 4: When an MDM device establishes an SSL/TLS connection with the MDM server through SSL bridging–enabled proxies, the client device identity certificate obtained by the target MDM server from transport security will be the intermediate proxy server client authentication certificate instead of the actual device client identity certificate.<4> It is required that the MDM client and MDM server have a mechanism to send and verify device identity securely in this case. This is achieved by including a client certificate related HTTP header in a DM package. The MDM server can identify a connecting device by examining the device client identity certificate issued earlier at MDM enrollment time. The device client identity certificate is used to establish the SSL/TLS connection to the MDM server.

    • Every SyncML message that comes from the MDM client carries an additional HTTP header named MS-Signature and Authorization. This header contains a BASE64-encoded CMS (Cryptographic Message Syntax) Detached Signature of the complete SyncML message (SyncHdr, SyncBody) SHA-2 hash. Signing is performed using the private key of the device identify certificate.
    • The device identity certificate (public key) and PKCS9 UTC signing time stamp are included as part of the authenticated attributes in the signature.
    • This is an opt-in function. By default, the MDM client doesn’t sign the DM package. During MDM enrollment, the server could require the DM client to sign the outgoing MD package via RequireMessageSigning node in DMClient CSP. For more information about device enrollment and DMClient CSP, see [MS-MDE2].
    • The MDM server validates the signature, and time stamp using a device identity certificate. It ensures the device’s client identity certificate is valid (issued by MDM at enrollment time), the time is valid (optional), and the signature is valid and trusted by the MDM server as of today.

     

     

    Reference:

     

    [OMA-DMP1.2.1] Open Mobile Alliance, "OMA Device Management Protocol, Approved Version 1.2.1", OMA-TS-DM_Protocol-V1_2_1-20080617-A, June 2008, http://technical.openmobilealliance.org/Technical/release_program/docs/DM/V1_2_1-20080617-A/OMA-TS-DM_Protocol-V1_2_1-20080617-A.pdf

     

    The MS-MDE protocol sequence is as follows.

    [MS-MDE] https://msdn.microsoft.com/en-us/library/dn410708.aspx

    [MS-MDE]: Overview - msdn.microsoft.com

    msdn.microsoft.com

    MDE enables a device to be enrolled with the Device Management Service (DMS) through an Enrollment Service (ES), including the discovery of the Management Enrollment ...

     

     

    1.3 Overview

    MDE enables a device to be enrolled with the Device Management Service (DMS) through an Enrollment Service (ES), including the discovery of the Management Enrollment Service (MES) and enrollment with the ES. After a device is enrolled, the device can be managed with the DMS using MDM.

    The process for enrolling a device using MDE is shown in the following diagram.

    picte520d1ae-b7ba-f597-3ea9-d2ab0c83a453.jpg

    Figure 1: Typical sequence for enrolling a message using MDE

    The enrollment process consists of the following steps.

    1.       The user’s email name is entered via the enrollment client.
    2.       The enrollment client extracts the domain suffix from the email address, prepends the domain name with a well-known label, and resolves the address to the Discovery Service (DS). The administrator configures the network name resolution service (that is, the Domain Name System (DNS)) appropriately.
    3.       The enrollment client sends an HTTP GET request to the Discovery Service (DS) to validate the existence of the service endpoint.
    4.       The enrollment client sends a Discover message (section 3.1.4.1.1.1) to the Discovery Service (DS). The Discovery Service (DS) responds with a DiscoverResponse message (section 3.1.4.1.1.2) containing the Uniform Resource Locators (URLs) of service endpoints required for the following steps.
    5.       The enrollment client communicates with the security token service (STS) (section 3.2) to obtain a security token to authenticate with the ES.
    6.       The enrollment client sends a GetPolicies message (section 3.3.4.1.1.1) the ES endpoint [MS-XCEP] using the security token received in the previous step. The ES endpoint [MS-XCEP] responds with a GetPoliciesResponse message (section 3.3.4.1.1.2) containing the certificate policies required for the next step. For more information about these messages, see [MS-XCEP] sections 3.1.4.1.1.1 and 3.1.4.1.1.2.
    7.       Part a.The enrollment client can send a RequestSecurityToken message (section 3.4.4.1.1.1) to the ES endpoint [MS-WSTEP] using the security token received in step 4. The ES endpoint [MS-WSTEP] responds with a RequestSecurityTokenResponseCollection message (section 3.4.4.1.1.3) containing the identity and provisioning information for the device management client [MS-MDM]. For more information about these messages, see [MS-WSTEP] sections 3.1.4.1.1.1 and 3.1.4.1.1.2.

    Part b.The enrollment client can send a RequestSecurityTokenOnBehalfOf message (section 3.4.4.1.1.3) to the ES endpoint [MS-WSTEP] using the security token received in step 4. The ES endpoint [MS-WSTEP] responds with a RequestSecurityTokenResponseCollection message (section 3.4.4.1.1.3) containing the identity and provisioning information for the device management client [MS-MDM]. For more information about these messages, see [MS-WSTEP] sections 3.1.4.1.1.1 and 3.1.4.1.1.2.

    The steps for MDE device enrollment correspond to five phases as shown in the following diagram.

    pictb89214b1-4798-abd7-69b3-4c81b51cee79.jpg

    Figure 2: MDE device enrollment phases

    Wednesday, May 11, 2016 5:03 PM
    Moderator