Edit 20-March-2019: NIAP published a v1.1 of the Functional Package which addresses many of the item discussed in this blog. The title of the blog is updated and ambiguities previously found are corrected where they’ve been addressed.
NIAP recently released their first, and widely anticipated, modular protection profile package targeting the TLS communication protocol. This package is not meant to stand on its own and is designed to be included within new versions of NIAP protection profiles. While it is unlikely to be explicitly referenced by collaborative Protection Profiles (cPP), the requirements will almost certainly be highly similar.
Some highlights about the new package:
- Largely the same as existing TLS requirements
- TLS clients are no longer restricted to only the set of claimed ciphersuites
- An admin can accept an X.509 certificate that fails validation if permitted by explicit override
- DHE parameters of up to 8192 bits are now allowed
- NIAP gives a hat tip to automated testing by explicitly stating that testing may be performed manually or with an automated framework that provides empirical evidence
Package Structure
Formally, the TLS package is designed as a single mandatory umbrella Security Functional Requirement (SFR) which directs the package user (eg. PP or ST author) to select whether the TOE will claim TLS in a server capacity (TLSS) and/or whether it will claim TLS in a client capacity (TLSC). Further granular requirements are all designed as selection-based SFRs from Appendix B which pull in functionality such as mutual authentication and support for specific extensions.
The layout of the document is familiar to those who have read other NIAP protection profiles: they are self-contained documents offering both the SFR as well as the evaluator assurance activities (AAs) in-situ. Note that the package construct is a “Functional Package” which is different from an “Extended Package”. From their document,
“A package is either a functional package containing only SFRs, or an assurance package containing only SARs. Packages can be used in the construction of larger packages, PPs, and STs.”
Considering that TLS is widely applicable across many NIAP PPs and cPPs, trying to relate requirements against a myriad of pre-existing functions and tests that the industry is already familiar with is a bit of a difficult task. We try to relate SFR elements, tests and other AAs against the well-known NDcPP, AppOnOS PP and OSPP as a frame of reference to readers. It is possible, for example, that the next iteration of the AppOnOS PP v1.3 — as of this writing in phase 3 of NIAP’s development lifecycle — will include a reference or iteration of the TLS Functional Package [n.b. 20-March-2019: This happened. The AppOnOS 1.3 directly uses the TLS Functional Package]. It is also possible that the Network Device international Technical Community (ND iTC) will look to adopt similar TLS requirements where it makes sense to do so.
This is a long analysis, so if you are interested in reviewing only specific functionality, click on the appropriate link to take you to the content:
There are several areas within this analysis where we consider that NIAP may want to clarify language or requirements. Lightship has submitted requests to NIAP for their consideration.
TLS Client
FCS_TLSC_EXT.1 is very similar to previous NIAP TLS requirements and the NDcPP, in particular. The number of available ciphersuites have been reduced (primarily, it seems, it remove SHA1-based variants). However, the most interesting aspect of FCS_TLSC_EXT.1.1 is in its Application Note. Previously, ciphersuite selection, curves, parameters, etc. that could be configured in the TOE were restrictive: no additional ciphers, curves, parameters, etc. could be selected beyond those stated. However, the Application Note contains an explicit concession:
“…this requirement does not restrict the TOE’s ability to propose additional cipher suites beyond the ones listed in this requirement in its Client Hello message.”
This is important, both functionally and from an operational environment perspective. The rationale appears to be based on which endpoint is considered the perceived owner of the data. Since the data is being offloaded from the TOE, the external peer would be responsible for storing the data and therefore should have the final say in how it is transported (since it is the TLS server which has final authority over ciphersuite selection within the TLS handshake). This is somewhat interesting from a data custodial perspective and it might be interesting to see if this evolves within NIAP or how international cPPs adopt this stance. There are no requirements that explicitly direct the administrative guidance documentation to contain any statement about needing to properly configure the server, though this seems like an inadvertent oversight.
From a test case analysis, test cases 1-4 are similar to other test cases seen. Generally speaking, test case language has softened on how the TLS handshake terminates when abnormal conditions occur. Of particular note, test case 5-2 is new when compared to other NIAP PPs and the NDcPP. To date, it has not been required to perform any explicit testing for valid but unsupported client-side protocol version checks. In addition, test case 5-7 has more clearly defined the test methodology compared to, say, NDcPP FCS_TLSC_EXT.x.1 test 5(f).
FCS_TLSC_EXT.1.2 contains a wildcard matching test which explicitly does not permit wildcarding a top-level domain part (eg. *.com is not permitted to match foo.com). This test is not contained in, for example, the NDcPP, but it can be found in the AppOnOS v1.2 and the OSPP v4.2. Vendors who had to author specific wildcard matching logic based on NDcPP test requirements may need to verify that they are not being overly permissive. Test case 5.4 is also new, and possibly evolved from the fact that wildcard-matching was meant to be optional. If a vendor relied on this requirement being optional to avoid validating buggy or incomplete wildcard-matching logic, then test case 5.4 is designed to provide some small assurance that *no* wildcard matching logic is in place at all. So, while wildcard matching is still considered optional, it is only optional that it be implemented, rather than optional to be claimed. This nuance is material.
FCS_TLSC_EXT.1.3 is a new SFR element compared with previous NDcPP and NIAP PP instantiations. This SFR permits an operator to continue to accept an X.509 certificate that fails validation if permitted by explicit override. The test cases continue to be related to FIA_X509_EXT.1 test cases with the exception of Test 4 which is possibly ambiguous, or, at the very least a duplication of effort. What constitutes an “invalid identifier” when compared with the tests performed in FCS_TLSC_EXT.1.2? The other test cases (Tests 1-3) are all duplicates of other test cases performed in other contexts, so it is possible a lab could simply point back to other FCS_TLSC_EXT.1 test cases or FIA_X509_EXT.1 test case and claim the various test cases are met.
[n.b. 20-Mar-2019: This entire section has been clarified in v1.1 of the Functional Package.]FCS_TLSC_EXT.2 explicitly tests that a TOE client can negotiate mutual authentication. The SFR states that the TOE must be capable of presenting a certificate, which is decidedly NOT the same as requiring the TOE to present a certificate during mutual authentication. This opens the possibilities for a TOE client that can dynamically react to a server configured for mutual authentication or not. When carefully reviewing the test cases, test case 1 doesn’t actually require the TLS handshake being negotiated to be successful if a Certificate Request is NOT sent to the TOE. It only requires that the TLS handshake is attempted to be negotiated and that the evaluator does NOT see an attempt by the TOE to send back an unsolicited client-side Certificate. This permits both optional mutual authentication and mandatory mutual authentication implementations to be tested within the stated requirements. It might be prudent for NIAP to issue a technical decision to clarify the distinction. [n.b. 20-Mar-2019: NIAP clarified this in v1.1 without changing the fact that mutual authentication is optional.]
FCS_TLSC_EXT.3 is an Objective requirement in Appendix C which means it is not required to be implemented at this time.
FCS_TLSC_EXT.4 is new within the NIAP PPs and NDcPP and related to support for channel renegotiation. Here we find a bit of ambiguity. FCS_TLSC_EXT.4.2 requires an ST author to explicitly select only one of the renegotiation_info extension or the canary ciphersuite, though FCS_TLSC_EXT.4.1 requires the extension. However, in the Application Note that follows, the reader is encouraged to support both. Based on the fact that the wording looks word-for-word like FCS_TLSS_EXT.4 in this same package, it would appear that perhaps the “choose only one of” directive in the SFR element might be a typo or that the canary ciphersuite was added as an afterthought after copying from FCS_TLSS_EXT.4. A NIAP clarification will almost certainly be necessary here. [n.b. 20-Mar-2019: NIAP, indeed, clarified this section and removed FCS_TLSC_EXT.4.2, while augmenting the Application Note to provide information about support for the renegotiation_info extension and the canary SCSV.]
FCS_TLSC_EXT.5 is related to, for example, NDcPP FCS_TLSC_EXT.1.3/2.4. In addition to ECDHE named curves, DHE parameters can be negotiated rather than being explicitly rendered by whatever the server decides to use. This can make testing for DHE parameters more explicit. Similar to FCS_TLSC_EXT.1, there is specific wording indicating that TLS clients can propose curves outside of the claimable set. This is new and more pragmatic than the requirements seen in the NDcPP which previously restricted the curve set.
Of particular note, FCS_TLSC_EXT.5 appears to now explicitly require that TLS_DHE_… ciphersuites be negotiated using only named parameters in the supported_groups extension. FCS_TLSC_EXT.5.1 claims in the Application Note that:
If an elliptic curve or Diffie-Hellman ciphersuite is selected in FCS_TLSC_EXT.1.1 or FCS_DTLSC_EXT.1.1, then FCS_TLSC_EXT.5 shall be included in the ST.
This means that TLS clients that claims TLS_DHE_… ciphersuites and not supporting the ffdhe… named groups will fail testing. Check your configurations!
In addition, DHE parameters 2048-, 3072, 4096, 6144 and 8192-bits long can be proposed and used. This will likely have knock-on effects for FCS_CKM.2 and subsequent CAVP testing if support is desired.
The sole test case for FCS_TLSC_EXT.5 is new and is very similar to FCS_TLSS_EXT.1.3 (which itself is similar to, say, FCS_TLSS_EXT.1.3 in the NDcPP). However, this test case appears to omit explicit testing for DHE parameters. Historically, the NDcPP had accidentally omitted explicit DHE testing which resulted in a technical decision to enforce testing of those parameters. It is possible that such testing will be mandated, so vendors would be wise to ensure that any DHE parameter claims and subsequent support of the supported_groups extension are confirmed.
[n.b. This omission has been corrected in v1.1 and, in fact, makes explicit testing of DHE supported_groups required.]
TLS Server
FCS_TLSS_EXT.1 is relatively unchanged from other NIAP and cPPs though the number of available ciphersuites may differ (again, primarily removing SHA1-based variants). Unlike FCS_TLSC_EXT.1 in this TLS package, the ciphersuites for the TLS Server are explicitly restricted to the claimed set which is consistent with the apparent rationale surrounding data ownership.
Regarding test cases, test case 3 now explicitly targets only RSA-based ciphersuites. (This specific test iterated many times internally in the international NDcPP TLS Working Group (WG). The language we see in the TLS package mirrors a previous TLS WG iteration ensuring that behaviour specific to TLS handling of a garbled RSA PreMasterSecret doesn’t provide an opportunity for certain oracle attacks.)
FCS_TLSC_EXT.1.1 Test 4 condenses test cases we’re already familiar with. Test 4.1 which tests unsupported TLS server version handling is found in the AppOnOS PP, but is not found in the latest NDcPP.
FCS_TLSS_EXT.1.2 mirrors the requirement and AAs from other NIAP and cPPs.
FCS_TLSS_EXT.1.3 has test cases similar to those seen in NDcPP and AppOnOS, with an interesting note:
“The testing can be carried out manually … or with an automated framework that similarly captures such empirical evidence.”
In addition to the traditional server-defined DHE parameter sizes, specific DHE finite field groups can be claimed and explicitly tested. These permit clear client/server negotiation of the DHE parameters as per RFC7919 (https://tools.ietf.org/html/rfc7919).
FCS_TLSS_EXT.2.2 test cases mirror those found in the NDcPP for FCS_TLSS_EXT.2.4/2.5. Of interest, however:
- Test 1 requires that TOE server mutual authentication is NOT merely capable of being used, but that it MUST be used if claimed. This is a different implication than FCS_TLSC_EXT.2 in this package.
- Test 2 appears to be new, but is likely the result of an ambiguity from previous NDcPP evaluations. Now, test 1 and 2 cover the cases whereby a proper (but empty) Certificate message is received, vs. a Certificate message is not sent at all by the non-TOE client.
- Test 5 provides much more detail as to the intent as its similar NDcPP cousin. Publishing the intent of a test case is always helpful as it can help frame equivalency arguments when dealing with Certification Bodies.
FCS_TLSS_EXT.2.3 matches the NDcPP FCS_TLSS_EXT.2.6 pretty closely.
FCS_TLSS_EXT.3 is an Objective requirement in Appendix C which means it is not required to be implemented at this time.
FCS_TLSS_EXT.4 matches the requirements described for the TLS client in FCS_TLSC_EXT.4 with the exception — of course — of any language around the renegotiation canary ciphersuite.
DTLS Client
FCS_DTLSC_EXT.1 leverages pre-existing TLS assurance activities and elements 1.1-1.3 are analogues of FCS_TLSC_EXT.1 with appropriate notes to account for slight DTLS differences. FCS_DTLSC_EXT.1.4 is similar to, for example, NDcPP FCS_DTLSC_EXT.2.6, which is applicable to both single- and mutually-authenticating sessions. Note however, that DTLSC in this package no longer mandates replay detection and discard functionality be tested.
FCS_DTLSC_EXT.2.X are precisely the same set of requirements and tests as in the FCS_TLSC_EXT.2.X SFR elements in this TLS package.
DTLS Server
FCS_DTLSS_EXT.1, like the client side, leverages pre-existing assurance activities from the TLS Server requirements. However, note that for FCS_DTLSS_EXT.1.2, the test AA might cause problems depending on a vendor, lab or certifier philosophy. If the view of the AA is absolutely immutable, rather than assuming some pragmatism, then the test case makes no sense for DTLS due to the non-DTLS protocol versions that form the AA. However, the pragmatic view of the AA test case is to verify that the denial claims hold up as appropriate for the TLS/DTLS versioning scheme. It is possible that NIAP could issue a TD to rewrite the AA to avoid any potential conflicts. [n.b. This has been updated in v1.1 to explicitly perform test cases for DTLS.]
FCS_DTLSS_EXT.1.3 is singularly concerned with attackers forging source IP addresses of ClientHello messages in order to coerce the DTLS server to act as a denial of service amplifier. The attack is described in detail in the mentioned RFCs and should not be confused with identifier verification in an X.509 certificate or similar.
[n.b. This entire ambiguity has been resolved in v1.1.]FCS_DTLSS_EXT.1.5 is functionally unchanged from the NDcPP wording. Again, replay detection and discard functionality is no longer required to be claimed or tested.
FCS_DTLSS_EXT.2.X are precisely the same set of requirements and tests as in the FCS_TLSS_EXT.2.X SFR elements in this TLS package with some slight wording changes.
Lightship is committed to making certifications faster and easier for vendors. Talk to us about how your TLS implementation might be future-proofed against the new TLS Functional Package so we can help you achieve your certifications at the speed of development.
Greg McLearn is Lightship’s Technical Director. He has been doing Common Criteria and security certifications for 10+ years and enjoys getting his hands on some of the latest technology. He has authored several tools to help facilitate security testing.