Several weeks ago a new EP that adds SSH capabilities to the Application Software, General Purpose OS and Mobile Device Management PPs was released. Most of the SFRs and assurance activities in this EP should be familiar to anyone who has worked with previous PPs that had SSH requirements. What’s significant about this new EP is that it is a step toward making PPs more modular. In the future capabilities such as SSH will be presented in separate EPs rather than as optional components of baseline PPs. This should streamline future changes for protocols like SSH since a single EP update can cover a wide variety of product types.

As with all new PPs and STs the SSH EP splits SSH SFRs into client or server SFRs depending on the TOE’s functionality. The client and server SFRs are quite similar and the testing methodologies for their Assurance Activities are usually the same, but this change does allow ST authors to write documents that more accurately reflect their products.

One significant change in the SSH EP’s requirements compared to those in older PPs is the requirement that the TOE support AES-CTR. In the past most PPs required the use of AES-CBC with AES-GCM being selectable as well. In this new EP AES-CBC and GCM are both selectable as additional ciphers. This change was partially the result of a conflict between Common Criteria, FIPS and the Department of Defense’s Unified Command Approved Product List (UC APL). This conflict was documented in greater detail in the previously referenced blog post, and changing CC’s requirements to AES-CTR makes it easier to get a product certified under all three of the above referenced standards.

Another addition to the SSH EP is the option of using x509 public key algorithms. This is not the first time these optional selections have been made available to ST authors (they are a choice in the NDcPP’s SSH requirements) but they are a departure from the requirements in the NDPP that are so familiar to many CC customers and evaluators. As in the NDcPP if any x509 algorithm is selected then the ST must include a list of trusted certification authorities.

The SSH EP’s requirement to periodically rekey SSH connection will also be new to those who are familiar with the NDPP. The NDcPP has also included an SSH rekey requirement but it simply requires that the connection be rekeyed after no more than 2^28 packets have been transmitted. The SSH EP gives the option of basing rekey requirements on the number of packets transmitted, the amount of data transmitted  or the age of the connection.

Most the SSH EP’s assurance activities will be familiar to those who have tested SSH as part of NDPP evaluations, but there are some new requirements. When testing for support for encryption algorithms evaluators must now also ensure that an attempt to connect using 3DES-CBC will be rejected. The testing of public key algorithms requires the rejection of SSH-DSA public key algorithms and when data integrity algorithms are tested the TOE must be shown to reject connections without a MAC algorithm or those attempting to use HMAC-MD5. These tests are all present in the NDcPP but they are a change from the days of the NDPP.

The SSH EP creates a standardized set of SSH requirements for a large variety of TOE types. As we’ve shown above most of the testing requirements are not new, but they are more rigorous than many people are used to from the NDPP. The switch to AES-CTR may be a burden on vendors in the short term, but it should make certifications across FIPS, CC and UC APL easier in the future.