Welcome to the Acumen Security Blog

A New EP For Voice And Video Over IP

For the past couple of years the Protection Profile for Voice Over IP Applications (VOIP_PP) has been available for vendors who want to get a VoIP client Common Criteria certified. In March of 2017 this PP will reach its sunset date. Its place will be taken by the newly developed Extended Package for Voice and Video over IP (VOIP_EP). This EP, which was released in September of this year, will extend either the Application Protection Profile (APP_PP) or the collaborative Network Device Protection Profile (NDcPP).

One of the most significant differences between the old VOIP_PP and the new VOIP_EP is the types of TOEs it is meant to cover. The VOIP_PP was meant for software applications running on a host platform, typically one certified against an Operating System or Mobile Device PP. VOIP_PP TOEs were required to use SDES-SRTP for protected voice communications and SIP over TLS for call control.  By extending either the APP_PP or the NDcPP the VOIP_EP can be used for both software applications or dedicated network appliances. The VOIP_EP is now also clearly meant to cover TOEs that offer video capabilities, while the old VOIP_PP only covered voice data.

One unusual limitation that was noted in the “Use Cases” section of the EP was that a Software Application TOE should be running on a general purpose computer with an operating system that is conformant to the General Purpose Operating System Protection Profile. This statement would appear to exclude mobile applications that run on Mobile Device PP certified platforms. While we believe this was an oversight in the VOIP_EP, vendors who are planning on certifying mobile applications should confirm with NIAP that that a Mobile Device PP certified platform is acceptable.

The most notable difference in requirements between the VOIP_PP and the VOIP_EP is the addition of audit requirements to the EP. Any VOIP_EP TOE that extends the NDcPP would have to meet NDcPP audit requirements, but VVOIP audit requirements have also been added in that apply to both NDcPP and APP_PP based TOEs. This is important to remember since most CC evaluations of mobile applications do not include any SFRs that cover audit. Since the EP only contains FAU_GEN.1 this also means that APP_PP based TOEs will have a requirement to generate audit records but without the usual corresponding requirements for audit data protection or storage. There is an optional Audit Event Storage SFR for TOEs that claim APP_PP conformance. Interestingly the language in that optional SFR says that it shall be included for APP_PP evaluations, which makes it sound like a selection-based SFR rather than an optional one. This is something that should be clarified by NIAP before a TOE enters evaluation under this EP.

Another significant change in the VOIP_EP is the addition of a requirement that the TOE use a constant bit rate voice vocoder. This is meant to avoid potential vulnerabilities than can result when you encrypt the output of a variable rate vocoder. There is also a new requirement that the TOE close all ports that are not in active use.

A new option that has been made available to developers in the VOIP_EP is the option to use H.323 rather than SIP for communication with an Enterprise Session Controller. H.323/H.235 is now also an acceptable alternative to SRTP for protecting communications with another VVOIP endpoint. This was presumably included because of the EP’s coverage of both voice and video clients.

The release of the VOIP_EP is another step in NIAP’s attempt to move to more modular Protection Profiles. By extending two very common PPs it should make Common Criteria certification possible for a wide variety of voice and video over IP products. Everything from a standalone phone to a desktop software application can now be evaluated, giving vendors and clients more options for CC-compliant voice and video clients.

Version 1.2 of the Application PP

On October 25 version 1.1 of the Application Software Protection Profile (PP_APP) will sunset. It is being replaced with PP_APP version 1.2.

Like its predecessor PP_APP 1.2 is aimed at mobile, server and desktop application software. It is meant to be used in conjunction with Extended Packages (EPs) for more specialized applications. EPs that currently exist for this PP include the Redaction Tools EP, the SSH EP and the VoIP EP.

The changes to this version of the PP_APP are relatively modest. It has the same TOE boundary as previous versions, addresses the same use cases and includes the same threats, objectives and assumptions.

The mandatory cryptographic support (FCS) and security management (FMT) requirements have not been changed in this version of the PP. In the User Data Protection (FDP) requirements FDP_DEC_EXT.1.3 through 1.5 have been removed. What used to be FDP_DEC_EXT.1.4 is now a separate SFR named FDP_NET_EXT.1.1. FDP_DEC_EXT.1.3 and 1.5 which cover justification for accessing resources and protection of Personally Identifiable Information (PII) have been taken out completely. In addition, there have been some minor changes to the Android assurance activities for FDP_DEC_EXT.1.1 and 1.2. As in the previous version PP_APP 1.2 does not have any mandatory identification and authentication (FIA) SFRs.

To cover the PII related requirement that was removed from FDP this new PP adds a privacy related SFR named FPR_ANO_EXT.1. Even though the name and family of the SFR has changed the wording of the requirement and the related assurance activity have remained the same.

Mandatory requirements for the protection of the (FPT) have also remained the same in this PP update. In the trusted path/channel (FTP) requirements it is now permissible to use SSH to protect data in transit if the SSH EP is used as well. This is covered in FTP_DIT_EXT.1. The assurance activities for that SFR now also include more specific instructions for TOEs running on iOS and Android.

In its optional requirements the updated PP now includes an SFR for the generation of symmetric cryptographic keys. The purpose of this SFR is to support the generation of keys along a key chain. At this time the assurance activities for this SFR are purely documentation based, although it also relies on FCS_RBG_EXT.1. The other minor change to optional requirements has been to rename FCS_TLSC_EXT.1.4 which is the SFR for TLS mutual authentication to FCS_TLSC_EXT.2.1.

In the PP’s selection based requirements FCS_RBG_EXT.2.1 has been changed to remove support for FIPS 140-2 X9.31 random bit generation. The previous version of the PP had warned that these DRNGs would be disallowed after 2015 so this change should come as no surprise to developers.

FCS_COP.1.1(1) has been changed to make 256-bit keys mandatory while 128-bit keys are optional which is the opposite of the previous PP version. This was another change that old PP had said would be made in 2015. FCS_COP.1.1(2) has also removed SHA-1 as a mandatory hashing algorithm and made it an optional selection instead. In the TLS client requirements FCS_TLSC_EXT.1.5 has been renamed FCS_TLSC_EXT.4.1 even though the wording and assurance activities have remained the same.

One new capability that has been added to PP_APP 1.2 is TLS Server. The requirement says that it depends on a selection in FTP_DIT_EXT.1 however FTP_DIT contains no selection that requires FCS_TLSS. This was presumably an oversight on the part of the PP authors and will likely soon be corrected by a NIAP technical decision.

As we’ve shown the newest version of the PP_APP contains a number of changes but most of them are administrative in nature. The updates that have been made to bring it up to current cryptography standards were all described in the previous PP version. The only new capabilities that are covered are for SSH and TLS server, and those are both optional. Developers who have created products for previous versions of the PP_APP should have little difficulty meeting the standards of the updated protection profile.