RE: PP Problems: External Standards

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

I apologize for any implied insult. My intention was only to clarify that CC
evaluations are about analyzing evidence against requirements and are not
intended to be a challenge to an evaluation team as to whether they can
demonstrate a flaw in a TOE.

Previously I did not attempt to answer your question about strong
cryptography. However, I believe that the CC specifically defines strength
of cryptography as being out of scope. Hence, some other entity would need
to determine that. The CC is about specifying security functional
requirements - using FCS one can require that a cryptographic algorithm
meeting a particular standard (presumably implying strength) must be used
for specified operations. While I think it appropriate for the evaluation
team to determine whether a cryptographic function performs the identified
operations when required, I have a problem when the objective grows to
determining that the cryptographic function actually fulfills the identified
standard. I'm not sure how to accomplish that using the CC, CEM, and some
arbitrary cryptographic standard. 

As for the FPT_ITC.1 example. Whether security functions are cryptographic
or not, the design of the TOE must provide all necessary details (effects,
errors, subsystems, modules, etc.). Normally probabilistic functions need to
be addressed by strength of function, but the CC specifically excludes
cryptographic functions from this requirement. So, from that perspective it
wouldn't really matter whether the function were perfect or not. Since
FPT_ITC doesn't identify a standard and since cryptography is outside of
scope of strength of function analysis, it seems the CC was intentionally
designed NOT to handle this case. 

Getting back to your most recent response...

Regarding my "tautological" :-) statement. I was trying to say that the CC
is designed around relatively simple concepts and includes requirements
(APE_SRE/ASE_SRE) to ensure new requirements follow the same model. These
simple concepts are necessary to ensure that evaluations are as objective
and consistent as possible (e.g., to facilitate international mutual
recognition). The introduction of arbitrary requirements (by reference)
defies the intent of the CC and promotes moving away from objectivity,
consistency, etc.

Yes, I am suggesting that all external standards should be converted to the
CC - if they are important enough that they must be included (in a PP) in
the first place. While I agree this would be cumbersome, if it is true that
the results would be irrelevant or there is some question as to whether this
can happen, then how are CC evaluation teams to address this problem on the
fly during evaluation? This is central to my problem.

As implied above, I think the CC doesn't provide any mechanism to evaluate
the strength of cryptographic mechanisms. I believe that FIPS and the CC
schemes have their respective, complimentary jobs. However, while they may
be related through the products being evaluation, I don't think they need to
be interdependent. I am concerned that there is a growing expectation that
CC evaluations will verify or even perform aspects of FIPS (and other)
evaluations. I think that redundancy should not be a part of a solution.

>From a technical perspective, I simply disagree with evaluating things to
which the CC assurance requirements do not apply (e.g., whether a
cryptographic device has a certificate). I also disagree with requiring
evaluation teams to evaluate products using requirements that are not
defined in a manner that allows direct application of the current evaluation
methodology. Either convert the requirements or expand the methodology.

Do I want good or strong cryptography? Not necessarily. As a CC evaluator I
simply want claims to be accurate. As for FIPS, I don't want to be
responsible to check for the existence of a FIPS certificate and I don't
want to verify through CC evaluation that the FIPS requirements have been
met (unless recast as CC requirements). My alternative is that if a TOE
contains identifiable cryptographic functions, the evaluation team should
evaluate whether they are appropriately invoked, protected, etc. (per
applicable CC requirements) and ensure that they are properly identified in
the Security Target. Subsequently, I expect users to require that (or
determine whether) the cryptographic functions have been appropriately
evaluated (by FIPS, NSA, DSD, or whatever authority is applicable) just like
they determine whether the applicable CC evaluation has been performed.

Note that I'm not especially concerned about FIPS 140 since these
evaluations are currently being performed. I'm much more concerned about the
presence of a large number of ANSI standards, PKSC standards, organizational
roadmaps, organizational policies, etc. that are finding their way into the
next wave of U.S. PPs. Especially, those for which there is no existing
evaluation process. These are things that CC was not intended to address.


> -----Original Message-----
> From: Shawn Fitzgerald [mailto:sfitzgerald@corsec.com]
> Sent: Thursday, March 06, 2003 1:06 PM
> To: Multiple recipients of list
> Subject: RE: PP Problems: External Standards
> 
> 
> 
> 
> > -----Original Message-----
> > From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of 
> > Arnold, James L. Jr.
> > Sent: Wednesday, March 05, 2003 3:37 PM
> > To: Multiple recipients of list
> > Subject: RE: PP Problems: External Standards
> > 
> > 
> > 
> > I think you may misunderstand how CC evaluations work. 
>  
> This statement seems rather presumptuous and an attempt to 
> un necessarily reduce this discussion to a series of invectives.
>  
> > It is not the case that if an evaluation team can't find 
> > anything wrong they must accept it. Rather, there must be 
> > adequate evidence (per the CC assurance requirements) to 
> > convince the evaluation team that the security functions meet 
> > the security functional requirements. To do this, the 
> > evaluation team is required only to apply the methodology 
> > provided by the scheme (e.g., the CEM).
> > 
> 
> Yes. I should have preceded my statement with a sentence 
> stating that this is "effectively" what could happen.
>  
> >  On the other hand, the NSA has issued PPs that require EAL 2 
> > and AVA_VLA.3 - meaning that there is little actual 
> > evaluation evidence, but a lot of reliance on penetration 
> > type testing (these PPs artificially might create a situation 
> > close to what you suggest).
> > 
> > I actually believe that it would be a good idea to evaluate 
> > that cryptographic products are "plugged-in" properly. 
> > Meaning that they are invoked at the right times and appear 
> > to be doing their jobs - I think this is what the FCS 
> > requirements should be used for, though they are not well 
> > designed requirements. However, I think that maintaining (and 
> > expanding, e.g., to include more algorithms) separate 
> > cryptographic entities (in each nation and also split among 
> > commercial and classified) can work perfectly fine. Let the 
> > crypto functions be evaluated and then let the CC evaluation 
> > team make sure they are used properly.
>  
> Yes I agree. The problem is this not happening at present.
>  
> > I believe that a primary problem here is that the CC paradigm 
> > expects that all security requirements to be stated in terms 
> > of well-defined and individually-relatively-simple (known as 
> > elements) statements for both security functions and security 
> > assurances. CC evaluations teams would evaluate (using 
> > applicable evaluation methodologies) the evaluation evidence 
> > (associated with assurance requirements) in order to 
> > determine whether the TOE functions appropriately (in 
> > accordance with the security functional requirements). In the 
> > case of external standards, meaning not CC standards, it is 
> > not necessarily clear whether the requirements are complete, 
> > well-defined, unambiguous, or even coherent. The CC attempted 
> > to address this problem by including requirements for the 
> > construction of explicitly stated requirements (in other 
> > words, requirements not found in the CC). By simply including 
> > external standards in a PP or ST by reference, the relevant 
> > CC requirements are being ignored. 
> 
> This seems rather tautological and is not really addressing my
> question. If you do not like my example, please use another. 
> 
> 
> > Worse, each developer and evaluation team may end up in the 
> > position of analyzing and attempting to extract relevant 
> > requirements from those standards so that they can apply the 
> > evaluation methodology they are responsible for. It may turn 
> > out that the assurance requirements don't apply. It may turn 
> > out that the requirements are a mix of security functional 
> > and assurance requirements. Regardless, the result won't be 
> > efficient (e.g., it would be much more efficient to convert a 
> > given external standard once, rather than leaving that to a 
> > indefinite number of developers, evaluators and validators) 
> > and it is unlikely that there would (or even could) be 
> > consistency in the evaluation efforts. If external standards 
> > (including cryptographic standards) are translated into the 
> > CC, I don't see any particular problem in performing CC 
> > evaluations. But if they are not, then I think that 
> > evaluation quality, etc. would suffer.
>  
> Are you arguing that all external standards referenced as 
> part of an evaluation be translated into CC? Are you saying 
> then that we should translate standards such as DES, RSA, and 
> various RFCs etc. into CC? How are you going to specify a 
> cryptographic algorithm in CC? This seems at best cumbersome 
> and at worst completely irrelevant.
> 
> 
> > In some (limited) cases there are third party (e.g., FIPS) 
> > evaluation results. Even in those cases this scenario doesn't 
> > make sense. For example, it is pointless for a CC evaluation 
> > team to simply check that a certificate exists - customers 
> > can take care of that in their RFPs. It also serves to 
> > arbitrarily make different types of evaluation/certificate 
> > interdependent. Furthermore, CC evaluation teams are 
> > certified by NIAP to perform CC evaluations and that does not
> > (currently) include the notion of accepting evaluation 
> > results from other entities.
>  
> 
> I agree that including external standards within CC is 
> problematic for some of the reasons you pointed out. But at 
> present I do not see any other way if CC evaluations are not 
> going to be completely marginalized from anything approaching reality.
> 
> I also do not think that FCS really covers anything.
>  
> Focusing on FIPS-140 for the moment:
> 
> FIPS-140 does a reasonable job in evaluating cryptographic 
> modules. I do not believe that CC does. If a PP author wants 
> to include a requirement for confidentiality (i.e. 
> cryptography), I don't see any assurance requirements which 
> insure that the cryptography is strong (and this especially 
> goes for the lower EAL levels). (And I am speaking to the 
> current crop of PPs) This is unfortunate because cryptography 
> (at least from an information theoretic perspective) is one 
> area of information security which is well understood (at 
> least comparatively). This is further exacerbated by the fact 
> that labs in general are not performing any tests on the 
> cryptography within a given TOE.
> 
> Assuming your goal is to have good/strong cryptography within 
> CC evaluated products.
> 
> And assuming you do not want FIPS included in any PPs, what 
> solution do you propose? Please proved examples if you can.
> 
> I believe NIST/CCEVS/NSA does not see a realistic short term 
> solution and this is why they are including FIPS-140.
> 
> > Note that I have recently presented a number of issues in 
> > this forum. One of those includes whether a PP author can 
> > levy requirements on other standards that are being claimed 
> > (see PP control of non-PP claims). The answer from NIB 
> > members seems to indicate that it is reasonable for PP 
> > authors to do so. Hence, I am wondering how an evaluation 
> > team might go about determining whether there are any 
> > requirement-multiplicative effects among a set of claimed 
> > standards (external or not). One (like
> > myself) might think it reasonable to assume that it is good 
> > enough to determine that each standard is fulfilled 
> > independent of the others and then to conclude that all of 
> > the standards are fulfilled collectively. But there seems to 
> > be a lot of resistance to that idea. The net result is that 
> > each standard claimed in a PP or ST would have a more 
> > (perhaps much more) than linear impact on the corresponding 
> > evaluation efforts.
>