PD 0150: FTA_SSL.1 and 2 SFRs in the Firewall, Traffic Filter Firewall, VPN, and IDS MR PPs

["Observation Decisions Review Board" <faigin@aero.org>]

The following PD (PD-0150) was developed by the ODRB during its April/
May meeting.  Comments on this PD are welcome and will be considered at
the next ODRB meeting.

TITLE

FTA_SSL.1 and 2 SFRs in the Firewall, Traffic Filter Firewall, VPN, and
IDS MR PPs 


ISSUE

In the Firewall, Traffic Filter Firewall, VPN, and IDS MR PPs, the
FTA_SSL.1 and FTA_SSL.2 requirements call for a TSF-initiated and
User-initiated session locking ability.  The session locking shall
provide display clearing/overwriting and disable all activity of the
user's access/display other than unlocking the session once the user is
reauthenticated. 

TSF-initiated session locking and User-initiated locking

	_(This wording is taken from the Traffic Filter Firewall Medium
	Robustness PPs, although the wording in the others is the same)_ 

	FTA_SSL.1 TSF-initiated session locking 

	FTA_SSL.1.1 - Refinement: The TSF shall lock a local interactive
	session after [a Security Administrator-specified time period of
	inactivity] by: 

	*	clearing or overwriting display devices, making the
                 current contents unreadable;  

	*	disabling any activity of the user's data access/display
                 devices other than unlocking the session.  

	FTA_SSL.1.2 - Refinement: The TSF shall require the user to
	re-authenticate prior to unlocking the session.  

	FTA_SSL.2 User-initiated locking 

	FTA_SSL.2.1 - Refinement: The TSF shall allow user-initiated
	locking of the user's own local interactive session by:  

	*	clearing or overwriting display devices, making the
                 current contents unreadable;  

	*	disabling any activity of the user's data access/display
                 devices other than unlocking the session.  

	FTA_SSL.2.2 - Refinement: The TSF shall require the user to
	re-authenticate prior to unlocking the session.  

	Application Note: The interactive sessions in FTA_SSL.1 and
	FTA_SSL.2 are those of the local administrator.
	Non-administrators only have remote access to the TOE and the
	requirements for session locking levied on them are specified in
	FTA_SSL.3.

An issue arises when interactive sessions are provided through a console
port on the device. This port may require a terminal emulator that is
run through a peripheral computer or terminal server in order to reach
the command line. The requirements of FTA_SSL.1 and FTA_SSL.2 can be met
by the TOE with the exception of the requirement for "clearing or
overwriting display devices, making the current contents unreadable", as
that would have to be enforced by the terminal emulator in the
environment. How should situations like this be handed, as it is out of
the control of the TOE? 

RESOLUTION

In environments where FTA_SSL.1 and FTA_SSL.2 must be enforced but the
actual terminal device is in the environment (such as might be the case
with terminal emulators or remote graphics terminal through an X window
server) the TSF must demonstrably make a best effort at clearing or
overwriting the screen. Examples of this would include sending
standardized clear screen sequences (typically Control-L) or using the
appropriate GUI commands to clear the screen. There must also be
administrative guidance that makes clear how the emulator or equivalent
must be configured so as to not retain information. 

RATIONALE

It is understood that there may be mechanisms within the IT environment
that can capture/retain portions of data through: terminal emulators,
screen shots, and remote graphics terminals that are outside the control
of the TOE.  Therefore, the TSF can only make a best effort to use a
clear command or overwrite the screen.  If the IT environment does not
have the ability to provide a clear or overwrite of the screen, a
notation should be made in the Administrative Guide of this inability. 



--
Daniel Faigin, CISSP, Coordinator for the CCEVS ODRB
Please send any comments or questions on this post to faigin@aero.org, and 
indicate it is an ODRB issue.