There was another move toward more modular Protection Profiles (PPs) with the recent publication of the Extended Package (EP) for WLAN Clients. This EP can be used to extend the Operating System (OS) or Mobile Device Fundamentals (MDF) PPs and replaces the standalone PP for WLAN Clients whose sunset date was at beginning of May. The requirements of the new EP are similar but not identical to many of the wireless requirements currently found in the MDF PP. This will make it easier for MDF PP compliant products to go against this new EP, but it should not be assumed that MDF PP compliance will automatically result in compliance with the WLAN EP.

The first area where the WLAN Client EP adds requirements is audit. This will have a more significant impact on MDF PP TOEs since the current version of the MDF PP does not include FAU_GEN (or any FAU SFRs) as mandatory. The EP adds requirements for cryptography related audit records that are not currently required by the OS PP either. TOEs which meet the MDF PP’s objective requirements for audit generation will be much closer to meeting the WLAN EP’s requirements, although it is currently rare for products to claim conformance to any objective PP requirements. The overlap between those optional requirements and the mandatory requirements of the EP may be something the vendors may wish to take into account when planning their future certification strategy.

In the area of cryptographic support the WLAN Client EP adds requirements for key generation, key distribution and Transport Layer Security (TLS) that are more specifically tailored to wireless encryption. The key generation and distribution requirements are similar to those for WLAN that are already in the MDF PP with some differences. As an example the PP and the EP require different cryptographic key derivation algorithms and different standards for cryptographic key wrap. ST authors will want to take a note of this and be careful not to overlook small differences between the PP and the EP. It’s also interesting that while the OS PP requires supports for TLS 1.2, the WLAN EP only requires TLS 1.0 with 1.1 and 1.2 being optional. An application note in the EP states that this was done because of a current lack of support for TLS 1.2 and it appears very likely that this requirement will be revisited in the near future.

Identification and authentication requirements in the new EP are fairly straightforward with a requirement for 802.1X support and X509 certificate support for EAP-TLS exchanges. Both of these requirements already exist in the MDF PP and neither the SFRs or their associated assurance activities are different in the EP. For security management the EP requires a few wireless network specific management functions and also includes a number of optional wireless related functions. A TOE which meets the MDF PP’s management requirements will also have the mandatory requirements of the new WLAN EP. The EP’s optional capabilities are new and enable ST authors to describe the TOE’s functionality in greater detail than the MDF PP would allow. Protection of the TSF requirements are different from those found in either of the two base PPs but the requirement is a straightforward test of the TOE or platform’s ability to verify the correct function of the TSF.

The WLAN EP’s TOE access requirement is also the same as that found in the MDF PP, although it does add new assurance activities. Finally the EP adds a wireless specific trusted channel requirement which specifies the use of wireless encryption to protect communications between the TOE and an access point. The SFR and its assurance activities are again similar to those from the MDF PP but add tests to detect the modification of trusted channel data and for an appropriate response to the physical interruption of a connection.

In addition to the SFRs described above the WLAN EP has application notes for several cryptographic support SFRs that are specific to one of the two PPs it modifies. No additional SFRs are added, however guidance is provided to ensure that the underlying OS or mobile device provides required cryptographic support.