Re: CCv3.0 STs claiming conformance to CCv2.2 PPs

[Dirk-Jan Out <out@itsef.com>]

>On the other hand one has to acknowledge that it has been used in a
>large number of evaluations and people have learned how to use it and
>how to deal with the errors ans inconsistencies of part 2 of V2.2. 
>
In my experience (supplemented by reading PPs and STs) "dealing with 
errors and inconsistencies" meant ignoring them, and writing  a set of 
SFRs that seemed to satisfy everyone.

>Quite
>a number of developers have spent significant time to develop Security
>Targets for CC evaluations using version 2.x of the CC and want to save
>this effort when switching to CC V3.x (which will be mandatory in some
>schemes at a specific date in time) when re-evaluating a new version of
>their product. Showing a useful transition stategy to those vendors is
>crucial for the acceptance of the CC in the future.
>  
>
I agree in principle, but unfortunately it is not easy to produce a 
transition strategy from an ill-defined and inconsistent language to a 
better-defined and hopefully-consistent language. In addition, several 
communities have evolved local Part2-interpretation-dialects that differ 
from each other. Download a few STs, do a search on the use of 
FDP_IFF/IFC and you'll see a prime example.

There is therefore not a "common understanding" of Part 2 that is 
transtioned from, there are many imperfect interpretations, and my 
understanding of each interpretation is likely to be imperfect as well.

Finally, if a PP is well-written (and there are some out there), 
transforming it to 3.0 is not that hard nor that laborious. The 
difficulties are likely to arise in interpreting the PPs to find out 
what they actually say, but this is aproblem from 2.1 not from 3.0

>I agree that this was not well defined in part 2 of Version 2.2. I also
>agree that v3 treats the definition of subjects and objects more
>rigorously. On the other hand I disgaree that non-CC minded readers will
>understand this concept in the following example: a system sending an IP
>packet to a TOE needs to be described as a "user" that "binds" to a
>subject in the TOE by this action. This would be required to describe an
>IPsec connection. In this case the "user" is the remote system and the
>"subject" in the TOE is the process handing IP as part of the
>communication stack. Binding is per IP packet. Now TCP on top of IP is
>used to establish a session (which is an important aspect for security
>of session oriented protocols). Here we have the same "user" binding to
>a different subject (the process handing TCP as part of the IP stack).
>Now on top of TCP we have an application layer protocol binding to a
>port (a security aspect here is e. g. the use of a trusted port). This
>protocol now "binds" the external entity to an application (in many
>cases a daemon executing as a subject in the TOE). The daemon now may
>authenticate the remote "user" using e. g. a password or a digital
>certificate thus "binding" the (potentially human) user to another
>process in the TOE. Of course it is possible to describe all this as a
>set of user-subject bindings, but I fear nobody except some CC experts
>will understand this.
>  
>
I think I see your problem.  It *could* be described this way. Part 2 
*allows* you to describe all processes at multiple layers (not sure why 
you leave out the ethernet and physical layer).

A common misunderstanding is that: ALL security in the TOE must be 
modeled in the SFRs.
This should be: ALL security in the SFRs must be present in the TOE.

My solution would be to use  abstraction and describe only the top level 
(the user (through his PC) connecting to a FTP-handler on the TOE). This 
is then modfied with requirements from FCO to describe 
integrity/confidentiality/non-repudiation etc. requirements on the 
communication between PC and ftp-client.

The full description on HOW this was done IPSCE/TCP/IP, can then be left 
to the FSP.

>Don't get me wrong: this is not an exotic example! It is just the
>description of an FTP server using an IPsec protected connection. Trust
>me, using version 2.2 this can be describes in much simpler terms that
>also a non-CC expert was able to understand!
>  
>
Hopefull;y the above helps: a very similar description applies in v3.

>>- v2 Part 2 assumes a user vs admin model. A user does things, an
>>admin does management, user access to objects is regulated by ACC,
>>manager access to functions is regulated by MOF/MTD. A multi-level
>>admin structure (e.g. PKI) is not easy to model. The difference
>>between user and admin was removed (related to the user vs subject model)
>>    
>>
>
>I disagree with the general statement. The "management" aspects have not
>been well defined in part 2 of version 2.2, but I think the problems
>could have been fixed easily.
>  
>
It has.

In v2 you needed to define :"management functions" through SMF and 
regulate them through MOF. There were suggested "management functions" 
listed in Part 2
In v3 you need to define operations (in ASE_REQ) (often with the TOE as 
object) and regulate them through ACC. There are "suggested operations" 
listed in Part 2

And presto, you can easily model many different levels of admins now.

>>- v2 Part 2 makes a difference whether the TOE communicates with a
>>human, with a machine or with a "trusted IT product" while the TOE
>>will not be able to tell the difference. The distinction was removed.
>>    
>>
>
>See my comment above. Removing this distinction makes part 2 simpler,
>but not its application when writing STs or PPs.
>  
>
A TOE has an interface with something else. This could be an 
IP-interface to a "trusted machine" or a "keyboard interface" to a human.

However, because it doesn't know who is actually interacting with this 
interface (e.g. a robot could be interacting with the keyboard, or an 
untrusted machine could be plugged in to the IP-interface) it makes no 
sense to use different SFRs.

You know whether someone on your interface is "trusted" because he/it 
authenticates himself. And you define what "trusted" means by defining 
how his subjects get attribute values and what the subject can do with 
these values.
This is a lot better than a vague statement on "the TSP of the trusted 
IT product has been correlated with the TSP of the TOE"

>>Once you solve these five, you find that many SFRs collapse into just
>>a few and something very close to the v3 Part 2 emerges. In my opinion
>>none of these is avoidable: they are problems and should be solved.
>>
>>The final addition (or rather: substraction) was that Part 2 was on
>>three levels of abstraction:
>>- a level where interactions between users, objects and subjects are
>>modeled
>>- a more abstract level where global properties of the TOE were described
>>- a more detailed level where implementation details were specified
>>(mainly the crypto requirements)
>>These levels were merged where possible into the first level to create
>>a more consistent specification.
>>
>>And then some cleaning up was done and v3 was there.
>>    
>>
>
>My problem with the new part 2 is that is (in my view) too abstract now.
>Yes, there is now a more clearly described underlying model, but I
>disagree that the application of this model will be easy and result in
>more readable Security Targets and Protection Profiles.
>  
>
That is where refinements come in to make it readable. And using more 
abstract models instead of all detail. And maybe the readability of the 
SFRs to the general public is not that important as they have 
SPD/OBJ/INT/TSS. And maybe exactness is more important for the TSP than 
readability.

>I think more practical experience using the new part 2 is required.
>Writing guidance without sufficient practical experience is in my view
>not a good idea. Before doing this a number of existing STs and PPs
>should be rewritten using part 2 of V3.0 and the results of this
>experience should be discussed openly. Otherwise we are in danger of
>developing stuff that is not very useful in practice.
>  
>
Of course. That is why I'm writing just a guide which is utterly 
informal instead of stuffing it all in the standard. To get people 
started with how the author thought that it should be used. It 
willdescribe *a* way. No doubt (there are a LOT of clever people out 
there) this will evolve. And a new guide may be written / updated in the 
future. But we have to start somewhere.

Leaving Part 2 the way it was was not an option, as it was known to be 
incorrect and incomprehensible. Several people have advocated its 
removal as in the current state it was useful to nobody and "it worked 
fine in ITSEC". Minor surgery turned out not to work (I can't prove 
this....I can only suggest that someone else tries to make Part 2 
consistent).

Thanks for the input,

DJ

-- 
-------------------------------------------
TNO ITSEF bv
Delftechpark 1          tel +31 15 269 2525
2628 XJ Delft           fax +31 15 269 2555
The Netherlands         www.itsef.com