PD-0132: Terminating Sessions in lieu of Locking Sessions

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

Both the Firewall Protection Profile for MR Environments (PP_FW_MR2.0_V1.0) and the Traffic-Filter Firewall Protection Profile for MR Environments (PP_FW_TF_MR_V1.0) include the FTA_SSL.1 and FTA_SSL.2 functional requirements. FTA_SSL.1 requires the TSF to lock a local interactive session after a Security Administrator-specified period of inactivity. FTA_SSL.2 requires that a user (in this case an administrative user) be able to initiate session locking of the local interactive session.

Consider a product that wants to claim compliance with these profiles, yet does not provide the ability to lock a session because the nature of a session is such that there are no "windows" or persistent information (i.e., a serial connection). This product terminates the session instead of locking it. This approach appears to meet the intent of FTA_SSL.1 because it:

• Clears or overwrites display devices making the current contents unreadable.
• Disables any activity of the user's data access/display device.
• Requires re-identification and re-authentication.

The product also provides administrator guidance that instructs administrators to terminate their Local Console interactive session when leaving the Local Console unattended. If an administrator does not follow this guidance, the unattended session will be terminated by the TOE after a Security Administrator-specified period of inactivity. This is argued to meet the intent of FTA_SSL.2.

To address this issue, it is proposed that the following be considered an acceptable refinement of FTA_SSL.2 that is still in compliance with the profile:

FTA_SSL.2 User-initiated locking

FTA_SSL.2.1 - Refinement: The TSF shall allow user-initiated session termination of the user's own Local Console interactive session.

FTA_SSL.2.2 - Refinement: The TSF shall require the user to reidentify and reauthenticate re-establishing a Local Console interactive session.

Resolution

It is acceptable to use session termination rather than session locking for a TOE claiming compliance to these PPs. The application note after FPT_SSL.2 (which also applies to FPT_SSL.1) explicitly states that these two components apply only to local administrators.

Because only the administrator accounts are affected, and because the administrator would need to unlock affected accounts, the proposed refinement will result in the administrator still having to re-establish the connection, re-identify, and re-authenticate, all of which meet the intent of FTA_SSL.2 as stated in the PPs.

Support

The purpose for locking a session is to ensure that a user must re-authenticate before getting access to information in that session. Terminating a session has the same effect, for it requires a re-authentication before access to the system is granted.

Modification History:

2007-02-22

PD Created. [February 2007 ODRB Agenda Item 3.a.ii]

References:

• Firewall Protection Profile (FW PP MR) for Medium Robustness
• Traffic-Filter Firewall Protection Profile (TFFW PP MR) for Medium Robustness Environments

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0256