RE: I-0451: When To Use IFF/IFC And AFF/AFC

[Nir Naaman <nir.naaman@metasec.com>]

On Tuesday, October 28, Diann Carpenter wrote:

> >When you are controlling the flow of IP packets based on 
> attributes in the
> >packet header, I would interpret that to be information flow 
> control. The
> >controls are based on the information in the object itself, 
> rather than on
> >its container. Examples of access control in the context of
> >controlling/mediating data flow through network devices 
> might be a switch
> >that performs port-address correlation, or an MPLS PE router 
> that controls
> >access to the appropriate IP-VPN. Of course, routing INSIDE 
> the MPLS cloud
> >would be based on the MPLS labels and would therefore be 
> associated with
> >information flow control.
> 
> >Or have I got it all backwards?
> 
> You haven't got it backwards however the interp is stating 
> that your argument in meeting IFF/IFC would require that the 
> "quality" or "label" remain with the data throughout the 
> information flow.  Therefore according to the interp, your 
> example would not be able to claim IFF/IFC because the header 
> does not remain with the data once it reaches its 
> destination.  Even if the destination forwards the data, the 
> packet header is a new one created by the destination to a 
> new destination and therefore IFF/IFC would not be met 
> according to the proposed interp. 
> 

I guess this depends on the type of network device. If it is a transparent
proxy, filtering router, or "stateful inspection" packet filter, then the
header will not necessarily change when the packet flows through the TOE.
Even if it does, ignoring NAT, the SOURCE address will probably not change.
The reference guidance states:
"The key characteristic is that the
   controls are based on a characteristic of the information, such as a
   sensitivity label, the quality of the data, or the source of the data.
   More importantly, the characteristic stays with the data as it moves
   through the TSF, and serves to provide the basis for the controls.
   Subjects need not be involved in this flow, as might happen in a
   network device that services to connect two ports."

I read the guidance to be specifically concurring with Michelle's argument
that IFF/IFC is appropriate for this kind of scenario.
The fact that the label is not physically the same as it moves through the
TSF doesn't seem relevant to me. Does an MLS operating system never
duplicate an object, creating a new copy of its sensitivity label attribute?
This is what is happening here, I think.

> Michelle's argument is that within the CC history use of the 
> IFF/IFC.1 requirement should be allowed for the type of flow 
> control you stated in your argument.  However, the referenced 
> interpretation wants to preclude such information flows being 
> described as IFF/IFC and instead is requiring that they be 
> classified under the ACC/ACF family of requirements. In the 
> specific case of firewall, rulesets are being argued as 
> "discretionary policies" not information flow policies.  
> 

What the guidance is saying is that FDP_IFF.1 is much more flexible than
what we had in the TCSEC days, and CAN be used for discretionary models
(e.g. a firewall access list). I believe that FDP_IFF.1.4 is intended for
scenarios in which the TSF modifies the object security attributes (e.g.
label downgrade).

> I concur with Michelle's comments and do not understand why 
> we would restrict a legitimate use of a Part II requirement 
> in such a way.  As Michelle states it becomes clearer in the 
> IFF/IFC.2 requirements that there is some "label" that 
> travels with the information that helps to ascertain how to 
> control the flow of that information.  However, this is not 
> present in IFF/IFC.1.  In the case of network devices that 
> control information flow based on a policy it is more closely 
> aligned with IFF/IFC than it is with ACC/ACF which discusses 
> controls on the container of information. 
> 

The difference between FDP_IFC.1 and FDP_IFC.2 is that the former specifies
the controlled operations, whereas the latter requires all operations on the
specified subjects and information to be controlled. FDP_IFC does not define
the attributes used to control the information flow. This is done in
FDP_IFF.1.1.

The only difference I can find between FDP_IFF.1 and FDP_IFF.2 is that for
the latter there is supposed to be an ordering relationship between the
security attributes used for information flow control. FDP_IFF.1 makes it
clear that there is some "label" that travels with the information - the
information security attributes:

FDP_IFF.1.1 The TSF shall enforce the [assignment: information flow control
SFP] based on the following types of subject and information security
attributes: [assignment: list of subjects and information controlled under
the indicated SFP, and, for each, the security attributes].

I think it is clear in FDP_IFF.1 that the security attributes in question
are attributes of the controlled information, rather than TSF data such as a
firewall access-list.

> I hesitate to get into a discussion of what parts of the 
> network information flow would require discretionary access 
> control as that is a nightmare from my TCSEC/TNI days that I 
> would rather not relive. We argued at that time that 
> discretionary access controls were not appropriate for 
> network constructs and here we are looking at guidance that 
> gets us back there.  
> 

I'm sorry to say that I was not a part of those terrible nightmarish days,
and so I find it hard to follow the argument. Are you saying that
discretionary access control (source=x, destination=y, port=HTTP, allow) is
inappropriate for network boundary protection? Are you bothered by the fact
that the proposed guidance allows such constructs using FDP_IFF.1? Or are
you bothered by it supposedly NOT supporting such constructs?

> This proposed interpretation creates confusion and does not 
> clearly solve any existing problems. I disagree with the 
> proposed interpreted guidance unless there is a companion 
> interp to discuss how to handle network information flows, 
> and a further explanation/rationale as to why IFF/IFC.1 
> cannot be used in these instances. 
> 

I have to say for myself that I have been confused in the past by whether
network information flows should be controlled via access control or
information flow control constructs, and have found the proposed guidance to
be sorely needed.

> Cheers,
> 
> Diann Carpenter
> Technical Director
> C&W CCTL
> 

Regards,
     Nir Naaman