The establishment of a user's session typically consists of the creation of one or more subjects that perform operations in the TOE on behalf of the user. At the end of the session establishment procedure, provided the TOE access requirements are satisfied, the created subjects bear the attributes determined by the identification and authentication functions. This family specifies functional requirements for controlling the establishment of a user's session.
A user session is defined as the period starting at the time of the identification/authentication, or if more appropriate, the start of an interaction between the user and the system, up to the moment that all subjects (resources and attributes) related to that session have been deallocated.
Figure L.1 - TOE access class decomposition shows the decomposition of this class into its constituent components.
Figure L.1 - TOE access class decomposition
This family defines requirements that will limit the session security attributes a user may select, and the subjects to which a user may be bound, based on: the method of access; the location or port of access; and/or the time (e.g. time-of-day, day-of-week).
User notes
This family provides the capability for a PP/ST author to specify requirements for the TSF to place limits on the domain of an authorised user's security attributes based on an environmental condition. For example, a user may be allowed to establish a "secret session" during normal business hours but outside those hours the same user may be constrained to only establishing "unclassified sessions". The identification of relevant constraints on the domain of selectable attributes can be achieved through the use of the selection operation. These constraints can be applied on an attribute-by-attribute basis. When there exists a need to specify constraints on multiple attributes this component will have to be replicated for each attribute. Examples of attributes that could be used to limit the session security attributes are:
a) The method of access can be used to specify in which type of environment the user will be operating (e.g. file transfer protocol, terminal, vtam).
b) The location of access can be used to constrain the domain of a user's selectable attributes based on a user's location or port of access. This capability is of particular use in environments where dial-up facilities or network facilities are available.
c) The time of access can be used to constrain the domain of a user's selectable attributes. For example, ranges may be based upon time-of-day, day-of-week, or calendar dates. This constraint provides some operational protection against user actions that could occur at a time where proper monitoring or where proper procedural measures may not be in place.
FTA_LSA.1 Limitation on scope of selectable attributes
Operations
Assignment:
In FTA_LSA.1.1 the PP/ST author should specify the set of session security attributes that are to be constrained. Examples of these session security attributes are user clearance level, integrity level and roles.
In FTA_LSA.1.1 the PP/ST author should specify the set of attributes that can be use to determine the scope of the session security attributes. Examples of such attributes are user identity, originating location, time of access, and method of access.
This family defines how many sessions a user may have at the same time (concurrent sessions). This number of concurrent sessions can either be set for a group of users or for each individual user.
FTA_MCS.1 Basic limitation on multiple concurrent sessions
User application notes
This component allows the system to limit the number of sessions in order to effectively use the resources of the TOE.
Operations
Assignment:
In FTA_MCS.1.2 the PP/ST author should specify the default number of maximum concurrent sessions to be used.
FTA_MCS.2 Per user attribute limitation on multiple concurrent sessions
User application notes
This component provides additional capabilities over those of FTA_MCS.1 Basic limitation on multiple concurrent sessions, by allowing further constraints to be placed on the number of concurrent sessions that users are able to invoke. These constraints are in terms of a user's security attributes, such as a user's identity, or membership of a role.
Operations
Assignment:
For FTA_MCS.2.1 the PP/ST author should specify the rules that determine the maximum number of concurrent sessions. An example of a rule is "maximum number of concurrent sessions is one if the user has a classification level of 'secret' and five otherwise".
In FTA_MCS.2.2 the PP/ST author should specify the default number of maximum concurrent sessions to be used.
This family defines requirements for the TSF to provide the capability for locking and unlocking of interactive sessions (e.g. keyboard locking).
When a user is directly interacting with subjects in the TOE (interactive session), the user's terminal is vulnerable if left unattended. This family provides requirements for the TSF to disable (lock) the terminal or terminate the session after a specified period of inactivity, and for the user to initiate the disabling (locking) of the terminal. To reactivate the terminal, an event specified by the PP/ST author, such as the user re-authentication must occur.
A user is considered inactive, if he/she has not provided any stimulus to the TOE for a period of time.
A PP/ST author should consider whether FTP_TRP.1 Trusted path should be included. In that case, the function `session locking' should be included in the operation in FTP_TRP.1 Trusted path .
FTA_SSL.1 TSF-initiated session locking
User application notes
FTA_SSL.1 TSF-initiated session locking, provides the capability for the TSF to lock an active user session after a specified period of time. Locking a terminal would prevent any further interaction with an existing active session through the use of the locked terminal.
If display devices are overwritten, the replacement contents need not be static (i.e. 'screen savers' are permitted).
This component allows the PP/ST author to specify what events will unlock the session. These events may be related to the terminal (e.g. fixed set of keystrokes to unlock the session), the user (e.g. reauthentication), or time.
Operations
Assignment:
In FTA_SSL.1.1 the PP/ST author should specify the interval of user inactivity that will trigger the locking of an interactive session. If so desired the PP/ST author could, through the assignment, specify that the time interval is left to the authorised administrator or the user. The management functions in the FMT class can specify the capability to modify this time interval, making it the default value.
In FTA_SSL.1.2 the PP/ST author should specify the event(s) that should occur before the session is unlocked. Examples of such an event are: "user re-authentication" or "user enters unlock key-sequence".
FTA_SSL.2 User-initiated locking
User application notes
FTA_SSL.2 User-initiated locking, provides the capability for an authorised user to lock and unlock his/her own terminal. This would provide authorised users with the ability to effectively block further use of their active sessions without having to terminate the active session.
If devices are overwritten, the replacement contents need not be static (i.e. 'screen savers' are permitted).
Operations
Assignment:
In FTA_SSL.2.2 the PP/ST author should specify the event(s) that should occur before the session is unlocked. Examples of such an event are: "user re-authentication", or "user enters unlock key-sequence".
FTA_SSL.3 TSF-initiated termination
User application notes
FTA_SSL.3 TSF-initiated termination, requires that the TSF terminate an interactive user session after a period of inactivity.
The PP/ST author should be aware that a session may continue after the user terminated his/her activity, for example, background processing. This requirement would terminate this background subject after a period of inactivity of the user without regard to the status of the subject.
Operations
Assignment:
In FTA_SSL.3.1 the PP/ST author should specify the interval of user inactivity that will trigger the termination of an interactive session. If so desired, the PP/ST author could, through the assignment, specify that the interval is left to the authorised administrator or the user. The management functions in the FMT class can specify the capability to modify this time interval, making it the default value.
Prior to identification and authentication, TOE access requirements provide the ability for the TOE to display an advisory warning message to potential users pertaining to appropriate use of the TOE.
FTA_TAB.1 Default TOE access banners
This component requires that there is an advisory warning regarding the unauthorised use of the TOE. A PP/ST author could refine the requirement to include a default banner.
This family defines requirements for the TSF to display to users, upon successful session establishment to the TOE, a history of unsuccessful attempts to access the account. This history may include the date, time, means of access, and port of the last successful access to the TOE, as well as the number of unsuccessful attempts to access the TOE since the last successful access by the identified user.
This family can provide authorised users with information that may indicate the possible misuse of their user account.
This component request that the user is presented with the information. The user should be able to review the information, but is not forced to do so. If a user so desires he might, for example, create scripts that ignore this information and start other processes.
Operations
Selection:
In FTA_TAH.1.1, the PP/ST author should select the security attributes of the last successful session establishment that will be shown at the user interface. The items are: date, time, method of access (such as ftp), and/or location (e.g. terminal 50).
In FTA_TAH.1.2, the PP/ST author should select the security attributes of the last unsuccessful session establishment that will be shown at the user interface. The items are: date, time, method of access (such as ftp), and/or location (e.g. terminal 50).
This family defines requirements to deny an user permission to establish a session with the TOE based on attributes such as the location or port of access, the user's security attribute (e.g. identity, clearance level, integrity level, membership in a role), ranges of time (e.g. time-of-day, day-of-week, calendar dates) or combinations of parameters.
User notes
This family provides the capability for the PP/ST author to specify requirements for the TOE to place constraints on the ability of an authorised user to establish a session with the TOE. The identification of relevant constraints can be achieved through the use of the selection operation. Examples of attributes that could be used to specify the session establishment constraints are:
a) The location of access can be used to constrain the ability of a user to establish an active session with the TOE, based on the user's location or port of access. This capability is of particular use in environments where dial-up facilities or network facilities are available.
b) The user's security attributes can be used to place constraints on the ability of a user to establish an active session with the TOE. For example, these attributes would provide the capability to deny session establishment based on any of the following:
- a user's identity;
- a user's clearance level;
- a user's integrity level; and
- a user's membership in a role.
This capability is particularly relevant in situations where authorisation or login may take place at a different location from where TOE access checks are performed.
c) The time of access can be used to constrain the ability of a user to establish an active session with the TOE based on ranges of time. For example, ranges may be based upon time-of-day, day-of-week, or calendar dates. This constraint provides some operational protection against actions that could occur at a time where proper monitoring or where proper procedural measures may not be in place.
FTA_TSE.1 TOE session establishment
Operations
Assignment:
In FTA_TSE.1.1 the PP/ST author should specify the attributes that can be used to restrict the session establishment. Example of possible attributes are user identity, originating location (e.g. no remote terminals), time of access (e.g. outside hours), or method of access (e.g. X-windows).