The MDM PP needs to be updated to support a use case where policy authenticity is not normally handled by certificates. 

This TD is effective 24 August 2023.

PP_MDM_V4.0 is updated as follows, with green highlight indicating additions:

FMT_POL_EXT.1 is updated to add the following two elements:

FMT_POL_EXT.1.2

The TSF shall sign policies and policy updates using a private key associated with [selection: an X509 certificate, a public key provisioned to the agent] trusted by the agent for policy verification.

Application note: if 'an X509 certificate' is selected, the 'policy signing' option in FIA_X509_EXT.2 is also claimed.

FMT_POL_EXT.1.3

For each unique policy managed by the TSF, the TSF shall validate that the policy is appropriate for an agent using [selection: client authentication via an X509 certificate representing the agent, a token issued to the agent and associated with a policy signing key uniquely associated to the policy].

Application Note: If 'client authentication via an X509 certificate representing the agent' is claimed, the appropriate protocol in FIA_X509_EXT.2 is also claimed. If 'a token issued to the agent and associated with a unique policy signing key' is claimed, FIA_TOK_EXT.1.1 is also claimed and the TSF maintains the association of the key pairs and the agent tokens. When multiple policies are supported, a unique policy signing key for each policy is used.

The TSS Evaluation Activity for FMT_POL_EXT.1 is replaced as follows (the AGD and Tests remain unchanged)

The evaluator shall verify that the ST describes how policies are signed, to include whether the private key used for signing is associated with an X509 certificate or public key, the method for distributing the policy verification material (a certificate or provisioned public key) to the agent, and the method for distinguishing whether a policy is appropriate for an agent. If tokens are claimed in FMT_POL_EXT.1.3, the evaluator shall verify the ST describes how tokens are established and distributed to the agent.

FIA_X509_EXT.5 is REMOVED and replaced with the following mandatory SFR:

FIA_CLI_EXT.1 Client Authorization

FIA_CLI_EXT.1.1

The TSF shall require a unique [selection: certificate, token as defined in FIA_TOK_EXT.1] for each client device.

Application Note: Token here is used in a generic way to be some form of unique identifier that is not certificate-based as defined in FIA_TOK_EXT.1. If “token as defined in FIA_TOK_EXT.1” is selected, FIA_TOK_EXT.1 must be included in the ST.

Evaluation Activity

TSS

The evaluator shall ensure that the TSS describes how the client is uniquely identified.

Guidance

None.

Tests

None.

The following selection-based SFR is added:

FIA_TOK_EXT.1 Client Tokens

FIA_TOK_EXT.1.1

The TSF shall [selection: invoke platform-provided functionality, implement functionality] to use [selection: IMEI, [assignment: other unique device ID]] to generate a unique token for each client device.

Application Note: This SFR is included in the ST if “token as defined in FIA_TOK_EXT.1” is selected in FIA_CLI_EXT.1.

Evaluation Activity

TSS

The evaluator shall review the TSS and verify that the TSF utilizes either unique identifier(s) from the client device or a server-specific mechanism to generate a unique token that will be used for verifying the identity of the client device. If the server generates the token using cryptographic functions, it must use algorithms in FCS_COP.1(ANY) (specific algorithms as needed by the vendor).

If "invoke platform-provided functionality" is selected, the evaluator shall examine the TSS to verify that it describes (for each supported platform) how this functionality is invoked (it should be noted that this may be through a mechanism that is not implemented by the MDM Server; nonetheless, that mechanism will be identified in the TSS as part of this evaluation activity).

If "implement functionality" is selected, the evaluator shall examine the TSS to verify that it describes the methods to generate the token.

Guidance

None.

Tests

For each MDM Agent/platform listed as supported in the ST:

The evaluator shall utilize appropriate combinations of specialized operational environment and development tools (debuggers, simulators, etc.) for the TOE and instrumented TOE builds as needed to perform this test.

The evaluator shall concurrently enroll 10 devices and ensure that the token for each is unique, per the methods described in the TSS.

These changes (along with TD 0755) will allow for the use of server-generated raw key pairs without certificates to be used for signing policies to be sent to the client (similar to SSH). This would follow with the current requirements in that policies are signed by the server when delivered to the client device, but would eliminate the need for a certificate authority and related infrastructure and checks.