PD-0155: CC inconsistencies/issues with the 2600 PP

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Effective Date:	2010-01-27
Last Modified	2010-01-27

Issue

A recent evaluation has identified a number of potential issues with the Multifunction Device PP, "U.S. Government Protection Profile for Hardcopy Devices in Basic Robustness Environments (IEEE Std. 2600.1-2009) Version 1.0", pp_hcd_br_v1.0, which may be found at http://www.niap-ccevs.org/cc-scheme/pp/pp_hcd_br_v1.0/. These issues would have the potential for an evaluation to fail based on the technical requirements levied by the CEM.

Section 9.2, FPT_FDI_EXT.1: The second paragraph of the section, describing family behavior, states: "Therefore, direct forwarding of unprocessed data between different external interfaces is forbidden unless explicitly allowed by an authorized administrative role. The family FPT_FDI_EXP has been defined to specify this kind of functionality." This functionality is also described in the paragraph labeled "Component leveling."

The above statements regarding administrative control of the data (both user and TSF) flows are supported in the first two paragraphs of the Rationale section. In the first paragraph, the issue of administrator control is reiterated. In the second paragraph of the Rationale, the PP states, "However, in this Protection Profile, the authors needed to express the control of both user data and TSF data flow using administrative control instead of attribute-based control."

Additionally, in the specification of the extended component, the defined "Dependencies" are FMT_SMF.1 Specification of Management Functions, and FMT_SMR.1 Security roles. In Section 19.3 of the PP the SFR is specified as one of the security functions to be used in the SMI SFR package that to be used in an ST claiming conformance to the PP.

However, there appears to be several issues/problems with the use of this extended component both in the PP and in any ST claiming conformance with the PP. First, reading the text of the SFR within the extended component definition (given in the PP, and necessarily replicated in any ST that claims conformance to the PP) is that there is no provision for the specification of the authorized roles. This issue is exacerbated by the Application Note 114: "The ST Author can use this SFR to define the roles that are permitted to allow unmediated transmission between Interfaces. If unmediated transmission is never allowed, "Nobody" should be instantiated as the 'authorized identified roles.'" An identified role should be specified by a (required) assignment by an ST author.

The second concern is derived from the first above. As described above, the specification of the extended component specifies a flow control policy for user and TSF data based on administrative control. Therefore, in the PP section, for the SMI SFR package there should be a specification of a flow control policy based on the "selection" of administrative control(s), enforcing or denying, the flow. This issue also affects STs claiming compliance with this PP.
According to Item f-1, Section 1.4, the PP says: "Bold typeface indicates the portion of an SFR that has been completed or refined in this Protection Profile, relative to the original SFR definition in Common Criteria Part 2 or an Extended Component Definition." According to the CEM, APE_REQ.1-4 through APE_REQ.1-8 and consequently ASE_REQ.1-4 through ASE_REQ.1-8 all operations must be identified. Additionally, APE_REQ.1-4 and APE_REQ.2-4, though they request that "The evaluator … check that the statement of security requirements identifies all operations on the security requirements", clearly give the guidance for identification of the operations in Paragraphs 271 and 291: "Identification may be achieved by typographical distinctions, or by explicit identification in the surrounding text, or by any other distinctive means." This guidance/instruction clearly, by the use of the plural e.g., typographical distinctions, shows that the catch-all bold text used in the PP is not appropriate.

For example, in FMT_MSA.1.1(a), FMT_MSA.1.1(b), FMT_MSA.3.1(a), and FMT_MSA.3.1(b), there are potentially indeterminate operations performed. According to the CC Part 3, these security functions require an assignment of "applicable access control and/or flow control policies." However, in the PP there appears to be a refinement to the SFRs, where the refinement value in the SFR specified in the PP could/should be part of the assignment. What is the operation? Can it be an inappropriately identified assignment, since the assignment is still contained in the SFR within the PP? Or is it an inappropriate refinement? How is this operation to be identified in an ST that claims conformance to the PP?

This issue is further convoluted in that the PP attempts to require assignments within an assignment (specified by the CC) as an additional element of the original assignment. One example of many within the PP is FDP_ACF.1.1(b) - the second assignment. Which assignment takes precedence? If the PP assignment is one of the assignment conditional values of the assignment in the CC assignment, can it be "not completed" because the original assignment was for only "positive values"? Or is it the case that the assignment within the assignment must be completed with, for example, "none" if there are no "positive" conditions?
In the PP, the functional requirements FMT_MTD.1.1(a) and FMT_MTD.1.1(b) have a convoluted collection of assignments refined to a selection that itself contains a selection that includes the original assignment. Additionally, these operations are different between the different iterations ("a" and "b"). In the case of FMT_MTD.1.1(b), the addition and/or refinement of the original assignment is removed in favor of a selection which itself contains a selection and the original assignment is eliminated. If these are refinements, they are not in accordance with C.4.4 of CC Part 1. (Note: in C.4.4 the use of the term "operations" clearly does not refer to operations associated with SFRs since the term "operations" is part of the list containing subjects, objects, security attributes, etc. all terms associated with the functionality of the TSF (e.g., FDP_ACC.1, FDP_ACF.1, and FDP_IFF.1).
The security function FMT_MTD.1 has an illegal iteration of elements - the CC allows for the iteration of components, not elements.

Resolution

Issue 1 Resolution:

The PP authors' intent of this ECD is that the TSF must prohibit unmediated forwarding of data between specified interfaces unless such forwarding is explicitly permitted by an administrative control. The ECD is refined for use in the PP to specify forwarding of data from any interface to any shared-medium interface. Furthermore, it was their intention to allow for the specification of an authorized role by specifying FMT_SMR.1 and FMT_SMF.1 as dependencies of this ECD. If unmediated forwarding of data is never allowed, either by TSF policy or by TOE architecture, then an administrative role to allow such forwarding is not needed and should not be required. In addition, if an ST allows unmediated forwarding under administrative control, then it is the responsibility of the ST author to add a flow control policy to support it.

App Note 114 is incorrectly worded. An earlier draft of FPT_FDI_EXP.1 included a requirement to specify an authorized role, and App Note 114 referred to that requirement. When that requirement was removed (deferring to dependencies on FMT_SMR.1 and FMT_SMF.1), the app note should have been reworded so that it referred to the dependencies and not to FPT_FDI_EXP.1 itself. This will be explained in the Errata section of an informative document Guide for the Development of Security Targets Conforming to the IEEE Std 2600 Series of Protection Profiles (not yet published).

Issue 2 Resolution:

The intent of the notational conventions used in this PP is that they unambiguously cover three cases:

Bold text identifies items that have been completed or refined in the PP

Italic text identifies items that must be completed by the ST author

Bold italic text identifies items that have been partially completed or refined in the PP but which also require completion by the ST author

The intent of "The TSF shall enforce the Common Access Control SFP in Table 17, [assignment: access control SFP(s), information flow control SFP(s)] to restrict the ability to…" is that the TSF shall enforce the specified access control SFP and any other access or flow control SFPs that the ST author might specify.

The intent in FDP_ACF.1.1(b), "based on the following: users and [assignment: list of TOE functions and the security attribute(s) used to determine the TOE Function Access Control SFP]", was that "users and" is a refinement that is separate from the assignment that follows it. Therefore, both "users" and "list of TOE functions…" are required.

Issue 3 Resolution:

The intent of iteration FMT_MTD.1(a) is to allow the ST author to restrict operations on specified TSF data to one of: (1) nobody, (2) the U.ADMINISTRATOR role, (3) other authorized roles that are not the U.NORMAL role, or (4) U.ADMINISTRATOR and other authorized roles that are not U.NORMAL.

The intent of iteration FMT_MTD.1(b) is to allow the ST author to restrict operations on specified TSF data that are associated with a U.NORMAL user or a U.NORMAL's documents or processing jobs to one of: (1) nobody, (2) U.ADMINISTRATOR, (3) the U.NORMAL to whom TSF data is associated, or (4) U.ADMINISTRATOR or that particular U.NORMAL.

In other words, the two iterations merely attempt to distinguish between two cases:

TSF data that only the administrator should be able to access;

TSF data that relates to a user or user process (document, job) that could be accessible by the user

Issue 4 Resolution:

The PP authors agree that it was a mistake to iterate elements of FMT_MTD.1 and not iterate the component (as was done elsewhere in this PP, e.g., FMT_MSA.1).

Philosophically, it would be best to withdraw the PP and correct this error, but it is not so easy to withdraw and republish this PP, because it is an IEEE standard and; as an IEEE standard, it would need to be amended, approved, and published by IEEE. Further, the IEEE would not correct the text in place, it would issue an addendum identifying the corrections by page and line number. This would most likely cause more confusion for developers, labs, and schemes, than allowing the PP to remain in its present state. Fortunately, this is a simple case because there is only one element in that component and there are no options to its dependencies.

Support

While the PP has some errors, its intent is discernable, and the document itself is quite useable, especially with the corrections supplied in this PD, which will be formalized in the forthcoming errata. Whereas, as detailed in the resolution to issue 4, attempting to replace the whole document with a rewritten version would be a long process and would not actually replace the PP but only add to it, which would create a situation nearly the same as will be produced by the publication of this PD.

Modification History:

2010-01-27: PD Issued. (November 2009 ODRB Meeting, Agenda Item 3.a.vi)

References:

Standard for a Protection Profile in Operational Environment A, IEEE Std 2600.1™-2009

Related NIs:

None

Related CCIMB-INTERPs:

None

Source OD: 0289