FTA_TSE session denial conditions

[jfisherbah]

FTA_TSE.1 is an SFR for defining the conditions in which an otherwise valid authentication attempt is rejected. The application note currently says the following (emphasis ours):

“all compliant TOEs will reject authentication requests based on invalid credentials but some may impose additional limitations"

FTA_TSE.1 does not cover the 'invalid credentials' case because one would never expect invalid credentials to be accepted. The use of 'may' here suggests that FTA_TSE.1 should be optional rather than mandatory because it implies that an authentication server may not have the ability to impose such restrictions.

The restrictions in the SFR are currently just an open-ended assignment that the ST author can populate with whatever they want. To make the SFR align with the app note, one of the two approaches below must be taken; guidance is needed on which is preferred:

1. Keep the assignment open-ended and make FTA_TSE.1 an optional requirement (since we can't have the ST author fill out "none" for the assignment)
2. Define some minimum set of session denial conditions that all conformant TOEs must enforce (or a selection that must have at least one item be chosen), with the option for the ST author to claim additional ones beyond that. For example, it may be the case that all conformant TOEs must be able to enforce, at minimum, a time-of-day/day-of-week access restriction such that any authentication attempt made during a restricted time or day is automatically rejected, even if the user supplied the proper credentials.

[ajlaing]

Invalid certificate is covered in FCS_TLSS_EXT.2.2.

There are currently tests for FCS_RADIUS_EXT.1 that indicate the TSF performs authorization checks, but no specific SFR captures this (and RADIUS is obsolete, so we'll probably replace it), FTA_TSE.1 can capture "user not authorized for requested service" as a mandatory item so it becomes mandatory, if what replaces RADIUS doesn't specifically include authorization checks. Other entries can be part of the 'authorization checks' but an ST author might want to spell out specific options provided by the TSF.

[jfisherbah]

FTA_TSE.1 has been refined to include invalid certificate so there won't be a null case anymore. It's debatable as to whether this is a valid use of a refinement though since an invalid certificate should always result in an authentication failure without being a condition that may or may not deny session establishment. Keeping this open for now just to flag for review.