References:

PP_MDM_v1.1: requirements FCS_IPSEC_EXT.1.13(1), FCS_IPSEC_EXT.1.13(2), and FMT_SMF.1.1(3)

PP_MDM_v2.0: requirements FCS_IPSEC_EXT.1.15 and FMT_SMF.1.1(2)

PP_ND_VPN_GW_EP_v1.1: requirements FIA_X509_EXT.1.9 and FMT_SMF.1.1; tests 2 and 7 under FCS_IPSEC_EXT.1.12

PP_VPN_IPSEC_CLIENT_v1.4: requirement FCS_IPSEC_EXT.1.13 and FMT_SMF.1.1; tests 2 and 4 under FCS_IPSEC_EXT.1.12

PP_SV_v1.0: requirement FCS_IPSEC_EXT.1.14 and FMT_SMF.1.1

Issue Description:

Each of these PPs has a requirement that an IPsec connection shall not be established if the DN in a certificate does not match the expected DN for the entity.  Is this requirement enforcing RFC 4945? Whose certificate is being compared and how is the expected DN established for the purposes of this matching?

This requirement ensures that the TOE performs identity verification of the connecting peer.  The TOE will use the presented identifier (termed “DN in a certificate” in the original requirement) to match to a reference identifier (termed “expected DN” in the original requirement). The reference identifier is to be configured by the administrator, and the presented identifier is sent by the peer in a certificate and in the ID payload.

The referenced IPSEC or X509 requirements shall be replaced with the following two elements with any necessary modifications of the subject per the original PP text (i.e. in the MDM PP v2.0 “TSF” below is the selection of MDM Server or MDM Server platform):

The TSF shall support peer identifiers of the following types: [selection: IP address, Fully Qualified Domain Name (FQDN), user FQDN, Distinguished Name (DN)] and [selection: no other reference identifier type, [assignment: other supported reference identifier types]].

Application Note: The TOE must support at least one of the following identifier types: IP address, Fully Qualified Domain Name (FQDN), user FQDN, or Distinguished Name (DN).  In the future, the TOE will be required to support all of these identifier types.  The TOE is expected to support as many IP address formats (IPv4 and IPv6) as IP versions supported by the TOE in general. The ST author may assign additional supported identifier types in the second selection.

Assurance Activity: The assurance activities for this element are performed in conjunction with the assurance activities for the next element.

The TSF shall not establish an SA if the presented identifier does not match the configured reference identifier of the peer.

Application Note: At this time, only the comparison between the presented identifier in the peer’s certificate and the peer’s reference identifier is mandated by the testing below.  However, in the future, this requirement will address two aspects of the peer certificate validation: 1) comparison of the peer’s ID payload to the peer’s certificate which are both presented identifiers, as required by RFC 4945 and 2) verification that the peer identified by the ID payload and the certificate is the peer expected by the TOE (per the reference identifier). At that time, the TOE will be required to demonstrate both aspects (i.e. that the TOE enforces that the peer’s ID payload matches the peer’s certificate which both match configured peer reference identifiers).

Excluding the DN identifier type (which is necessarily the Subject DN in the peer certificate), the TOE may support the identifier in either the Common Name or Subject Alternative Name (SAN) or both.  If both are supported, the preferred logic is to compare the reference identifier to a presented SAN, and only if the peer’s certificate does not contain a SAN, to fall back to a comparison against the Common Name. In the future, the TOE will be required to compare the reference identifier to the presented identifier in the SAN only, ignoring the Common Name.

The configuration of the peer reference identifier is addressed by FMT_SMF.1.1.

Assurance Activity:

TSS

The evaluator shall ensure that the TSS describes how the TOE compares the peer’s presented identifier to the reference identifier.  This description shall include whether the certificate presented identifier is compared to the ID payload presented identifier, which field(s) of the certificate are used as the presented identifier (DN, Common Name, or SAN), and, if multiple fields are supported, the logical order comparison.  If the ST author assigned an additional identifier type, the TSS description shall also include a description of that type and the method by which that type is compared to the peer’s presented certificate.

GUIDANCE

The evaluator shall ensure that the operational guidance includes the configuration of the reference identifier(s) for the peer.

TEST

For each supported identifier type (excluding DNs), the evaluator shall repeat the following tests:

Test 1: For each field of the certificate supported for comparison, the evaluator shall configure the peer’s reference identifier on the TOE (per the administrative guidance) to match the field in the peer’s presented certificate and shall verify that the IKE authentication succeeds.

Test 2: For each field of the certificate support for comparison, the evaluator shall configure the peer’s reference identifier on the TOE (per the administrative guidance) to not match the field in the peer’s presented certificate and shall verify that the IKE authentication fails.

The following tests are conditional:

Test 3: (conditional) If, according to the TSS, the TOE supports both Common Name and SAN certificate fields and uses the preferred logic outlined in the Application Note, the tests above with the Common Name field shall be performed using peer certificates with no SAN extension.  Additionally, the evaluator shall configure the peer’s reference identifier on the TOE to not match the SAN in the peer’s presented certificate but to match the Common Name in the peer’s presented certificate, and verify that the IKE authentication fails.

Test 4: (conditional) If the TOE supports DN identifier types, the evaluator shall configure the peer’s reference identifier on the TOE (per the administrative guidance) to match the subject DN in the peer’s presented certificate and shall verify that the IKE authentication succeeds. To demonstrate a bit-wise comparison of the DN, the evaluator shall change a single bit in the DN (preferably, in an Object Identifier (OID) in the DN) and verify that the IKE authentication fails.

Test 5: (conditional) If the TOE supports both IPv4 and IPv6 and supports IP address identifier types, the evaluator must repeat test 1 and 2 with both IPv4 address identifiers and IPv6 identifiers. Additionally, the evaluator shall verify that the TOE verifies that the IP header matches the identifiers by setting the presented identifiers and the reference identifier with the same IP address that differs from the actual IP address of the peer in the IP headers and verifying that the IKE authentication fails.

Test 6: (conditional) If, according to the TSS, the TOE performs comparisons between the peer’s ID payload and the peer’s certificate, the evaluator shall repeat the following test for each combination of supported identifier types and supported certificate fields (as above). The evaluator shall configure the peer to present a different ID payload than the field in the peer’s presented certificate and verify that the TOE fails to authenticate the IKE peer.

As NIAP updates each referenced PP, the timeline for making the future changes identified in the Application Note above will be made explicit.

For any product including this requirement in their ST, the referenced FMT_SMF.1 requirement shall include a management function: “configure the reference identifier for the peer” with the following application note and assurance activities.

Application Note: For TOEs that support only IP address and FQDN identifier types, configuration of the reference identifier may be the same as configuration of the peer’s name for the purposes of connection.

Assurance Activity:

GUIDANCE

The evaluator shall ensure that the operational guidance instructs the administrator on configuring the reference identifier of the peer. 

TEST

The evaluator follows this guidance in the performance of the assurance activities for the appropriate FCS_IPSEC or FIA_X509 requirement.

For PP_ND_VPN_GW_EP_v1.1 and VPN Gateway head-ends, the following Application Note applies to the referenced requirements:

Application Note: The reference identifier may be established with a local directory, using a connection to a directory server or authentication server, or using a rule-based reference identifier (e.g. defining all of the peer’s subject DN except the Common Name, defining a partial user FQDN such as *@example.com).

The updated requirements provide clarity on the intended functionality and tests for this requirement.