As we described in a previous blog entry, NIAP is attempting to standardize the requirements for SSH by creating an SSH EP that can be added to many different PP types. This should keep the requirements for SSH consistent across more evaluations and make it easier to incorporate updates to the standard into CC requirements. Unfortunately, the international nature of the NDcPP means that it cannot use a NIAP EP. We will take a look at some of the similarities and differences between these two sets of SSH requirements and hopefully provide some useful guidance to vendors who may be certifying multiple products with a common SSH implementation in the future.
Many of the differences between the SSH EP and the NDcPP are purely semantic. The EP contains a single FCS_SSH_EXT requirement and then a number of SSHC or SSHS requirements whose use is selection based. NDcPP on the other hand doesn’t have any FCS_SSH_EXT SFRs and puts everything into the server and client SFRs. In some other areas the SSH EP and the NDcPP currently differ, but the requirements will become more consistent in the next planned update of the NDcPP. One such requirement is FCS_SSHC/SSHS_EXT.1.2 in the cPP and FCS_SSHC/SSHS_EXT.1 in the EP. Right now the EP requires a TOE to use public-key based authentication but makes password-based authentication optional. The current version of the NDcPP requires both forms of authentication to be supported, but the most recent draft of NDcPP v1.1 will make password-based authentication optional.
Another area where the NDcPP and SSH EP currently differ is in the rekeying requirements in FCS_SSHC/SSHS_EXT.1.7 in the EP and FCS_SSHC/SSHS_EXT.1.8 in the cPP. The SSH EP allows vendors to select between packet limits, data limits and time limits when enforcing rekeying requirements while the current NDcPP requires TOEs to rekey after a certain number of packets have been transmitted. The updated NDcPP is planning to do away with the packet limit but will require TOEs to enforce limits based on both time and amount of data transmitted. This means that TOEs which conform to either version of the NDcPP will meet the SSH EP’s requirements in this area, but EP compliance will not guarantee compliance with the cPP.
The encryption algorithms required by the different PPs are different and will not be aligned after NDcPP v1.1 is released, however they will be similar and make compliance easier. The current NDcPP requires the use of AES in CBC mode while GCM is an optional selection. The SSH EP makes CTR mandatory (as our previous blog entry discussed this was intended to bring CC in line with FIPS an DoD UC APL standards) while CBC and GCM are optional. The current draft of NDcPP v1.1 will mandate AES but will allow a choice between CBC, CTR and GCM. The result of this will be that a product which meets SSH EP standards for this SFR will also meet NDcPP standards, but the reverse will not necessarily be true. All three CC standards require TOEs to reject SSH connections that are protected by non-AES encryption.
In most areas the requirements or SSH in the NDcPP and SSH EP are the same. This is good news for vendors who may be using a common SSH implementation in different products that they plan to certify against different PPs. There are a few differences though that could add challenges to a certification effort if they aren’t planned for in a shared SSH module. We hope that this will provide a useful summary of those differences for vendors who are considering how to implement SSH in future CC compliant products.