What’s New in NDcPP v2.2?

Lachlan Turner Certifications, Common Criteria

The Network Device international Technical Community recently (in December 2019) published version 2.2 of the collaborative Protection Profile for Network Devices – aka – NDcPP. The NDcPP is the most often used Common Criteria Protection Profile to achieve listing on the NIAP Product Compliant List (PCL).

NIAP are yet to formally endorse NDcPP v2.2 (UPDATE March 27, 2020: NIAP has now endorsed v2.2E which is basically the same as v2.2 but some front-matter changed) however it shouldn’t be too far off now – perhaps another month or so. With that in mind, it is useful to consider what has changed between v2.1 and v2.2 of the NDcPP. So, here are the main changes:

  • Explicit support for ‘virtual Network Devices’ (vND) is added – a vND is a software implementation of Network Device functionality that runs inside a virtual machine (VM) on either general purpose or purpose-built hardware. See section 1.2 TOE Overview for more on this.
  • The use of ‘safe-primes’ for key generation / agreement is better accommodated – see FCS_CKM.1/2.
  • Reference to NIST SP 800-56B is replaced with RSAES-PKCS1-v1_5 per RFC 3447 for RSA key establishment – see FCS_CKM.2
  • Clarifications added as to what constitutes ‘local administration’ in FMT_SMF.1.
  • Clarifications on the ‘Security Administrator’ role – this does not have to be a single role – in FMT_SMR.2
  • Scope of protection requirements clearly limited to just administrator passwords in FPT_APW_EXT.1
  • The term ‘Interactive session’ is clarified in FTA_SSL_EXT.1
  • Application Note 41 (Appendix A.1) indicates the logs regarding certificate validation errors should be detailed (i.e. if in doubt, add more detail in your certificate validation audit messages).
  • TLS test cases have been re-ordered and new tests added – this may have some impact on previously compliant TLS stacks – the only way to know for sure will be to run the new tests.
  • There’s a new “type 2” vulnerability that needs to be addressed in the section on AVA: the iTC is mandating review of “Bleichenbacher” oracle attacks when TLS_RSA_WITH_* ciphersuites are claimed by the TOE acting in a server capacity.

These are only the highlights. We’ve generated the track change versions if you want to dig deeper:

The only way to definitively know if your product complies with NDcPP v2.2 is to perform a full end-to-end test run (aka Functional Gap Assessment). Contact Lightship to find out about how we use automation to achieve this in a matter of weeks.