FIA_BLT_EXT.2 is an optional requirement in the MDF PP V2.0. The two elements in this requirement are unrelated, but because they are part of the same component, a vendor cannot claim one of them.

FIA_BLT_EXT.2 will remain and consist of just FIA_BLT_EXT.2.1. FIA_BLT_EXT.2.2 and its related assurance activities will become FIA_BLT_EXT.3.  The components should be revised as follows:

D.4.1.2 Bluetooth Authentication

FIA_BLT_EXT.2 Extended: Bluetooth Mutual Authentication

FIA_BLT_EXT.2.1 The TSF shall require Bluetooth mutual authentication between devices prior to any data transfer over the Bluetooth link.

Application Note: If devices are not already paired, the pairing process must be initiated. If the devices are already paired, mutual authentication based on the current link key must succeed before any data passes over the link.

Assurance Activity:

The evaluator shall ensure that the TSS describes how data transfer of any type is prevented before the Bluetooth pairing is completed. The TSS shall specifically call out any supported RFCOMM and L2CAP data transfer mechanisms. The evaluator shall ensure that the description in the TSS is detailed enough so that the evaluator can determine that data transfers are only completed after the Bluetooth devices are paired and mutually authenticated.

The evaluator shall perform the following test:

Test 1: The evaluator shall use a Bluetooth tool to attempt to access TOE files using the OBEX Object Push service and verify that pairing and mutual authentication are required by the TOE before allowing access. (If the OBEX Object Push service is unsupported on the TOE, a different service that transfers data over Bluetooth L2CAP and/or RFCOMM may be used in this test.)

D.4.1.3 Rejection of Duplicate Bluetooth Connections

FIA_BLT_EXT.3 Rejection of Duplicate Bluetooth Connections

FIA_BLT_EXT.3.1 The TSF shall discard connection attempts from a Bluetooth device address (BD_ADDR) to which a current connection already exists.

Application Note: If the TOE already has a connection to a remote Bluetooth device, a new connection attempt from a device claiming the same Bluetooth device address may be malicious and should be rejected/ignored. Only one connection to a single remote BD_ADDR may be supported at a time.

This requirement will be moved to Section 5 and will be mandatory for products entering into evaluation after Quarter 3, 2015.

Assurance Activity:

The evaluator shall ensure that the TSS describes how Bluetooth connections are maintained such that two devices with the same Bluetooth device address are not simultaneously connected and such that the initial connection is not superseded by any following connection attempts. The evaluator shall ensure that this description explicitly details the sequence of events that occurs when the TOE receives a new connection request from a device with which it has a current established Bluetooth connection.

The evaluator shall perform the following test:

Test 1: The evaluator shall perform the following steps:

Step 1 - Make a Bluetooth connection between the TOE and a remote Bluetooth device with address a known address (BD_ADDR1).
Step 2 - Attempt a connection to the same TOE from a second remote Bluetooth device claiming to have a Bluetooth device address matching BD_ADDR1.
Step 3 - Using a Bluetooth protocol analyzer, verify that the second connection attempt is ignored by the TOE and that the initial connection to the device with BR_ADDR1 is unaffected.

Section 4 and other tables in the PP that list requirement components must be updated to reflect the new component.

The elements of FIA_BLT_EXT.2 are unrelated and belong in separate components so they can be claimed separately.