Re: I-0451: When To Use IFF/IFC ( What is fundamental characteristic of information)

[Gary Stoneburner <gary.stoneburner@nist.gov>]

The phrase "fundamental characteristic of the
information" is used in the context of security attributes. 
Message length is not usually a security consideration, yet might
be.  For example, if security policy prohibits email messages longer
than a specified amount (perhaps to prevent sending files via email),
then flow control components would be appropriate for that
situation.

Existence and correctness of a hash value could also be part of an
information flow control policy and hence appropriate for IFF/IFC. 
The relation to UIT might be that UIT results in mechanisms to attach
integrity checks to messages being transmitted as part of the
transmission process.  An information flow control mechanism would
more likely be one that looks for messages coming for transmission to see
that a valid hash or checksum has been generated as part of the message
creation process.  If the goal is transmission integrity, then UIT
is the more obvious choice.  If the goal is to ensure that messages
to a certain transmission pipe have certain controls built into the
message, then IFF/IFC could be the better choice.  I do not claim
that this is a useful distinction, but it might be.

Cheers,
Gary

At 10:08 PM 10/30/2003, YOKOTA HIROFUMI wrote:

> Overall, I agree with Nir and read
> the guidance such that it allows for
> IFF/IFC to be used for applications such as firewalls, routers,
> etc.
>
> However, as Michelle says, this might be depending of my background
> and
> interpretaion.
> It is hard to read some nuances if there are in the proposal, for those
> who
> are
> not involved in discussions at the days of TCSEC.
>
> Putting aside the nuances, I have another question.
>
> What is the meaning (or definition) of "fundamental characteristic
> of the
> information"?
>
> 1. Is a message length that is written on a part of information field
> a
> fundamental characteristic of the information?
> => I think so. The length value stays on the information and and
> is
> definitely associated to the information.
>
> 2. Is a message length that is not written on the information field
> a
> fundamental characteristic of the information?
> => I think so. The length valuse is definitely associated to the
> information even if it is not written on some part of the field of
> the
> information.
>
> In a similar way:
>
> 3. Is a hash value that is written on a part of the information field
> a
> fundamental characteristic of the information?
> => I think so. The hash value stays on the information and is
> definitely associated to the information.
>
> Then, finally:
>
> 4. Is "valid or invalid" values that is resulted in a
> caluculation by a
> particular algorithm in the TOE, based on the hash value and the
> information, a fundamental characteristic of the information?
> => I am puzzled.
>
> ***********
>
> The reason why I raised this question is because that some evaluated
> STs
> demonstrate the valid/invalid values as information security attributes,
> and
> the rules based on the attributes controls deny/permit information flows
> by
> using IFC/IFF.
>
> Is this an appropriate use of IFC/IFF?
>
> Could "valid/invalid" values resulted from the hash values and
> the
> information
> in the TOE using some algorithm be an information security
> attribute?
>
> If "yes", I would say, this is an great idea!
>
> For many months, I was pondering about how to craft IFC/IFF that is
> required
> as a dependency for FDP_UIT (Data exchange integrity).
> I was given many suggestions about this, but my worry didn't
> terminate.
>
> If valid/invalid values resulted in the TOE is used as information
> security
> attributes and this is an appropriate use in IFC/IFF, I would say this
> could
> be
> a final answer for my worry about crafting IFC/IFF that is required as
> an
> dependency
> for FDP_UIT.
>
> However, I have some doubts on this as follows.
>
> 1) It looks that IFC/IFF depends on FDP_UIT, rather than that
> FDP_UIT
> depends on
> IFC/IFF.
>
> 2) Once 'valid/invalid' status was generated by TSF in the TOE, is
> it
> truely necessary for the TSF further support the information flow
> control
> based on
> the status? What is the threat to counter? I think such chained inclusion
> of
> components would make the ST further complex unnecessary.
>
> 3) Please note that TSF generate valid/invalid status for FDP_DAU
> (Data
> authentication) and FDP_SDI (Stored data integrity), too.
> However, those components, in the CC specification,  do not depend
> on
> IFF/IFC. Yet, is it appropriate to use IFF/IFC based on the rules 
> of
> 'valid/invalid' status when some subject in the TOE read those user
> data?
> ( Which, I think it is not necessary. )
>
> Yokota
>
> ================================
> Hirofumi Yokota
> Japn Quality Assurance Organization
> E-mail yokota-hirofumi@jqa.jp

**************************************************************************
* Opinions expressed are not intended to reflect an official position
**************************************************************************
* Gary Stoneburner
* Computer Security Division, National Institute of Standards & Technology
* 100 Bureau Drive, Stop 8930, Gaithersburg, MD 20899-8930         
* Phone: 301-975-5394, FAX: 301-948-0279, Email: Stoneburner@nist.gov
* http://csrc.nist.gov/staff/stoneburner/gshome.html
**************************************************************************