RE: Do we need explicitly stated IT security requirement for FPT_ STM?

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

You're asking whether time would be User Data or TSF Data.
TSF Data is defined as "Data created by and for the TOE, that might affect
the operation of the TOE."
User Data is "Data created by and for the user, that does not affect the
operation of the TSF."

In any reasonable TOE, you will have to claim FPT_STM.1 as a dependency for
FAU_GEN.1. Thus timestamps are TSF data in any case.

The question is - are timestamps TSF data when they are exported to remote
trusted IT products, or are they user data?
The answer depends on whether the time service is considered a security
service. It boils down to the questions: What are you trying to prove? How
does the TOE fit into its operational environment?
Is the time server designed to support security services in its environment?
PKI, Kerberos, etc. are all dependent on secure timestamps being available
in their operational environment. If this is the case, you need to make sure
that the security claims you're making are relevant to this scenario.

If the TOE is providing timestamps to subjects in the TSC (the clients), and
it is claimed in the PP/ST that this counters or mitigates a threat to these
subjects (e.g. back-dating), or upholds an organizational security policy
requirements ("Ye shall have secure timestamps"), then it is appropriate to
consider the time service as a security objective and time as TSF data
exported to remote trusted IT products. 
As was discussed on this thread, you can use FPT_SEP. You don't have to use
refinement (as Daniel and Tony discussed - it is inappropriate). You can
claim FTP_ITC.1 to protect the inter-TSF transfer of the TSF data to the
remote IT product, you can add FPT_TDC, FPT_TRC, etc. Effectively, you're
breaking down the requirement into several pieces: FPT_STM: provide
timestamps as TSF data; FTP_ITC: be able to provide said data to subjects in
the TSC; and so forth.
Alternatively you COULD define an explicit requirement for providing users
with "secure" timestamps.

If, on the other hand, you consider the time service as non-security
relevant in the TOE's operational environment, then I guess it COULD be user
data. You could distribute unreliable timestamps to your users, and use
reliable ones for the TSF.

In any case, when you evaluate the security of the client of the time
server, you will have to allocate the provision of secure timestamps to the
environment. The question then becomes one of composition (or C&A): can this
allocation be satisfied by a time server that regards its timestamps as
something that is "created by and for the user, that does not affect the
operation of the TSF", and are therefore not necessarily handled in or by
the TSF? You will then have to show that the time server user data
protection mechanisms are sufficient to support the security requirements of
the time server clients. 

     Nir

> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of 
> YOKOTA HIROFUMI
> Sent: Thursday, January 08, 2004 10:40 AM
> To: Multiple recipients of list
> Subject: Re: Do we need explicitly stated IT security 
> requirement for FPT_ STM?
> 
> 
> 
> I've changed my previous thought.
> 
> There is a consideration that the meaning of the phrase "reliable time
> stump" could be only decided when we think about the security 
> of the client
> of the time server.
> I mean, the "reliable time stump" is required as a security 
> function in the
> IT environment when we evaluate the security of the client of the time
> server, not when we evaluate the security of the time server.
> So, when we think about the time server and the TOE, the 
> first one ( i.e.,
> the TOE that provide time values as user data ) might be appropriate.
> 
> How about this?
> 
> ----- Original Message ----- 
> From: "YOKOTA HIROFUMI" <yokota-hirofumi@jqa.jp>
> To: "Multiple recipients of list" <cc-cmt@nist.gov>
> Sent: Wednesday, January 07, 2004 6:29 PM
> Subject: Re: Do we need explicitly stated IT security 
> requirement for FPT_
> STM?
> 
> 
> >
> > When we have a time server ( product)  to evaluate the 
> security functions,
> I
> > see two options for defining the TOE, since the use of time 
> values are not
> > necessarily for security purposes.
> >
> > One is the TOE that includes:
> >  - an application that provides reliable time information.
> >  - I&A security function.
> >  - audit security function.
> >  - user data (time values) protection function.
> >
> > Another one could be the TOE that includes:
> > - time stamps security function that provide reliable time 
> information.
> >   ( this might be expressed by using FPT_STM or the refinement, or
> > explicitly stated IT security requirement )
> > - other ( fringe ) security functions ( I&A, audit, user 
> data protection )
> >
> > Then, which TOE could be preferable for the evaluation?
> > Does this selection purely depend on the customers strategy?
> > Or, is this an area that scheme or evaluation lab can recommend?
> >
> > I personally prefer the second one, but I am not sure if 
> this is common
> > sense and if this is preferable to the second one.
> >
> > Yokota
> >
> >
> >
> 
> 
> 
>