Notable NDcPPv2.1 Changes (from v2.0e)

[March 12, 2019 Update] NDcPPv2.1 has been formally endorsed by NIAP.

NDcPPv2.1 is hot off the presses from the Network iTC.  It is yet to be officially accepted by NIAP for PCL usage however this is probably not too far off, perhaps with some minor tweaks (the new NTP SFR being something to watch).

Here are some notes from our initial review:

• NTP. A new SFR has been added for NTP which we understand refers to mechanisms that are supported by commonly available NTP clients.  Vendors still have the option of specifying manual time configuration. If v2.1 is accepted by NIAP as is, this will remove the mandated use of a trusted channel for NTP which was causing problems for some vendors in v2.0e.
• TLS. Administrators can now elect to ignore certificate validation failures. Support for 192-bit ciphersuites has been removed and a couple of new suites have been added.
• X.509. Certificate revocation checking requirements have been ‘clarified’ by an application note. This may result in changes for implementations that meet the current requirements.
• Audit Events. All generation/import/change of long-term cryptographic keys (i.e. not session keys) need to be audited, including those that are automatically generated by the TOE.

If you’re really serious about your NDcPP, we’ve also attached a track changes version of the new documents and provided a more detailed summary below.  If you need help determining exactly where your product stands in terms of compliance, you should try our Functional Gap Assessment powered by Greenlight and our team of testing experts.

NDcPP v2.1 – track changes

NDcPP Supporting Document v2.1 – track changes

NDcPPv2.1 Change Summary

Section 1 PP Introduction

• No major changes

Section 2 CC Conformance

• Accommodates PP packages and modules (currently none in the allowed list)

Section 3 Introduction to Distributed TOEs

• Some clarifications for distributed TOEs – no major changes

Section 4 Security Problem Definition

• No major changes

Section 5 Security Objectives

• No major changes

Section 6 Security Functional Requirements

• FAU_GEN.1 Application Note 1 expands the scope of auditing for generation/import/change of cryptographic keys.
• FAU_STG_EXT.1.2 – allows distributed TOEs to store local audit data on a single component.
• FMT_SMF.1 – additional management functions added for possible selection
• FPT_STM_EXT.1 – adjusted to accommodate FCS_NTP_EXT.1 (see below)

Annex A Optional Requirements

• A.1 Audit Events for Optional SFRs
  • FIA_X509_EXT.1/ITT – adds requirement to audit certificate changes in the trust store
• FIA_X509_EXT.1/ITT
  • explicitly requires all CA certificates in the certification path contain the basicConstraints extension with the CA flag set to TRUE
  • Application Note clarifies/expands certificate revocation checking requirements – this could have some impact on existing implementations (e.g. an expiration check must be performed for each certificate in the chain, up to and including the trust anchor).

Annex B Selection Based Requirements

• B.1 Audit Events for Selection-Based SFRs
  • FIA_X509_EXT.1/Rev – adds requirement to audit certificate changes in the trust store
  • FCS_NTP_EXT.1 – adds explicit requirement to audit NTP configuration changes
• FAU_GEN_EXT.1 – New SFR, requires distributed TOE components to generate audit data relevant to that component.
• FAU_STG_EXT.3 – New SFR, for distributed TOE components that store local audit data.
• FAU_STG_EXT.4 – New SFR, for distributed TOE components that send audit data to another distributed TOE component.
• FCS_TLS/DTLS*
  • Adds ciphersuites:
    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288
    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288
  • Removes ciphersuites:
    • TLS_RSA_WITH_AES_192_CBC_SHA as defined in RFC 3268
    • TLS_DHE_RSA_WITH_AES_192_CBC_SHA as defined in RFC 3268
    • TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA as defined in RFC 4492
    • TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA as defined in RFC 4492
    • TLS_RSA_WITH_AES_192_CBC_SHA256 as defined in RFC 5246
    • TLS_DHE_RSA_WITH_AES_192_CBC_ SHA256 as defined in RFC 5246
    • TLS_RSA_WITH_AES_192_GCM_SHA256 as defined in RFC 5288
    • TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA256 as defined in RFC 5289
    • TLS_ECDHE_ECDSA_WITH_AES_192_GCM_SHA256 as defined in RFC 5289
    • TLS_ECDHE_RSA_WITH_AES_192_GCM_SHA256 as defined in RFC 5289
    • TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA256 as defined in RFC 5289
  • Adds ability for an administrator to accept validation failures of certificates
• FCS_IPSEC_EXT.1.14
  • Explicitly states SAN and CN allowed field types and provides some application note clarifications.
• FCS_NTP_EXT Protocol – new SFR, adds NTP requirements:
  • TOE may use NTP v3 (RFC 1305) or NTP v4 (RFC 5905)
  • NTP must be secured with either:
    • Authentication using [selection: SHA1, SHA256, SHA384, SHA512, AES-CBC-128, AES-CBC-256] as the message digest algorithm(s) Note: It is our understanding that this refers to the key material used for the HMAC supported by commonly available NTP clients.
      OR
    • Trusted Channel – IPsec or DTLS
  • If using NTP, TOE must support at least 3 NTP sources
• FCS_SSH*
  • Adds encryption algorithms:
    • aes128-gcm@openssh.com
    • aes256-gcm@openssh.com
  • Adds authentication implementations:
    • rsa-sha2-256
    • rsa-sha2-512
    • x509v3-ssh-rsa
    • x509v3-rsa2048-sha256
  • Adds key exchange methods:
    • diffie-hellman-group15-sha512
    • diffie-hellman-group14-sha256
    • diffie-hellman-group16-sha512
• FIA_X509_EXT.1/Rev – as per FIA_X509_EXT.1/ITT
• FPT_TST_EXT.2.1 – Application note clarifies that revocation checking is not required for X.509 certificates that are used as part of start-up self-tests.