A common security requirement is to unambiguously identify the person and/or entity performing functions in a TOE. This involves not only establishing the claimed identity of each user, but also verifying that each user is indeed who he/she claims to be. This is achieved by requiring users to provide the TSF with some information that is known by the TSF to be associated with the user in question.
Families in this class address the requirements for functions to establish and verify a claimed user identity. Identification and Authentication is required to ensure that users are associated with the proper Security Attributes (e.g. identity, groups, roles, security or integrity levels).
The unambiguous identification of authorised users and the correct association of security attributes with users and subjects is critical to the enforcement of the security policies.
The FIA_UID family addresses determining the identity of a user.
The FIA_UAU family addresses verifying the identity of a user.
The FIA_AFL family addresses defining limits on repeated unsuccessful authentication attempts.
The FIA_ATD family address the definition of user attributes that are used in the enforcement of the TSP.
The FIA_USB family addresses the correct association of security attributes for each authorised user.
The FIA_SOS family addresses the generation and verification of secrets that satisfy a defined metric.
Figure G.1 - Identification and authentication class decomposition
This family addresses requirements for defining values for authentication attempts and TSF actions in cases of authentication attempt failure. Parameters include, but are not limited to, the number of attempts and time thresholds.
The session establishment process is the interaction with the user to perform the session establishment independent of the actual implementation. If the number of unsuccessful authentication attempts exceeds the indicated threshold, either the user account or the terminal (or both) will be locked. If the user account is disabled, the user cannot log-on to the system. If the terminal is disabled, the terminal (or the address that the terminal has) cannot be used for any log-on. Both of these situations continue until the condition for re-establishment is satisfied.
FIA_AFL.1 Authentication failure handling
User application notes
The PP/ST author may define the number of unsuccessful authentication attempts or may choose to let the TOE developer or the authorised user to define this number. The unsuccessful authentication attempts need not be consecutive, but rather related to an authentication event. Such an authentication event could be the count from the last successful session establishment at a given terminal.
The PP/ST author could specify a list of actions that the TSF shall take in the case of authentication failure. An authorised administrator could also be allowed to manage the events, if deemed opportune by the PP/ST author. These actions could be, among other things, terminal deactivation, user account deactivation, or administrator alarm. The conditions under which the situation will be restored to normal must be specified on the action.
In order to prevent denial of service, TOEs usually ensure that there is at least one user account that cannot be disabled.
Further actions for the TSF can be stated by the PP/ST author, including rules for re-enabling the user session establishment process, or sending an alarm to the administrator. Examples of these actions are: until a specified time has lapsed, until the authorised administrator re-enables the terminal/account, a time related to failed previous attempts (every time the attempt fails, the disabling time is doubled).
Operations
Assignment:
In FIA_AFL.1.1, if the PP/ST author should specify the default number of unsuccessful authentication attempts that, when met or surpassed, will trigger the events. The PP/ST author may specify that the number is: "an authorised administrator configurable number".
In FIA_AFL.1.1, the PP/ST author should specify the authentication events. Examples of these authentication events are: the unsuccessful authentication attempts since the last successful authentication for the indicated user identity, the unsuccessful authentication attempts since the last successful authentication for the current terminal, the number of unsuccessful authentication attempts in the last 10 minutes. At least one authentication event must be specified.
In FIA_AFL.1.2, the PP/ST author should specify the actions to be taken in case the threshold is met or surpassed. These actions could be disabling of an account for 5 minutes, disabling the terminal for an increasing amount of time (2 to the power of the number of unsuccessful attempts in seconds), or disabling of the account until unlocked by the administrator and simultaneously informing the administrator. The actions should specify the measures and if applicable the duration of the measure (or the conditions under which the measure will be ended).
All authorised users may have a set of security attributes, other than the user's identity, that are used to enforce the TSP. This family defines the requirements for associating user security attributes with users as needed to support the TSP.
User notes
There are dependencies on the individual security policy definitions. These individual definitions should contain the listing of attributes that are necessary for policy enforcement.
FIA_ATD.1 User attribute definition
User application notes
This component specifies the security attributes that should be maintained at the level of the user. This means that the security attributes listed are assigned to and can be changed at the level of the user. In other words, changing a security attribute in this list associated with a user should have no impact on the security attributes of any other user.
In case security attributes belong to a group of users (such as Capability List for a group), the user will need to have a reference (as security attribute) to the relevant group.
Operations
Assignment:
In FIA_ATD.1.1, the PP/ST author should specify the security attributes that are associated to an individual user. An example of such a list is {'clearance', 'group identifier', 'rights'}.
This family defines requirements for mechanisms that enforce defined quality metrics on provided secrets, and generate secrets to satisfy the defined metric. Examples of such mechanisms may include automated checking of user supplied passwords, or automated password generation.
A secret can be generated outside the TOE (e.g. selected by the user and introduced in the system). In such cases, the FIA_SOS.1 component can be used to ensure that the external generated secret adheres to certain standards, for example a minimum size, not present in a dictionary, and/or not previously used.
Secrets can also be generated by the TOE. In those cases, the FIA_SOS.2 component can be used to require the TOE to ensure that the secrets that will adhere to some specified metrics.
User notes
Secrets contain the authentication data provided by the user for an authentication mechanism that is based on knowledge the user possesses. When cryptographic keys are employed, the class FCS should be used instead of this family.
FIA_SOS.1 Verification of secrets
User application notes
Secrets can be generated by the user. This component ensures that those user generated secrets can be verified to meet a certain quality metric.
Operations
Assignment:
In FIA_SOS.1.1, the PP/ST author should provide a defined quality metric. The quality metric specification can be as simple as a description of the quality checks to be performed, or as formal as a reference to a government published standard that defines the quality metrics that secrets must meet. Examples of quality metrics could include a description of the alphanumeric structure of acceptable secrets and/or the space size that acceptable secrets must meet.
FIA_SOS.2 TSF generation of secrets
This component allows the TSF to generate secrets for specific functions such as authentication by means of passwords.
User application notes
When a pseudo-random number generator is used in a secret generation algorithm, it should accept as input random data that would provide output that has a high degree of unpredictability. This random data (seed) can be derived from a number of available parameters such as a system clock, system registers, date, time, etc. The parameters should be selected to ensure that the number of unique seeds that can be generated from these inputs should be at least equal to the minimum number of secrets that must be generated.
Operations
Assignment:
In FIA_SOS.2.1, the PP/ST author should provide a defined quality metric. The quality metric specification can be as simple as a description of the quality checks to be performed or as formal as a reference to a government published standard that defines the quality metrics that secrets must meet. Examples of quality metrics could include a description of the alphanumeric structure of acceptable secrets and/or the space size that acceptable secrets must meet.
In FIA_SOS.2.2, the PP/ST author should provide a list of TSF functions for which the TSF generated secrets must be used. An example of such a function could include a password based authentication mechanism.
This family defines the types of user authentication mechanisms supported by the TSF. This family defines the required attributes on which the user authentication mechanisms must be based.
FIA_UAU.1 Timing of authentication
User application notes
This component requires that the PP/ST author define the TSF-mediated actions that can be performed by the TSF on behalf of the user before the claimed identity of the user is authenticated. The TSF-mediated actions should have no security concerns with users incorrectly identifying themselves prior to being authenticated. For all other TSF-mediated actions not in the list, the user must be authenticated before the action can be performed by the TSF on behalf of the user.
This component cannot control whether the actions can also be performed before the identification took place. This requires the use of either FIA_UID.1 and FIA_UID.2 with the appropriate assignments.
Operations
Assignment:
In FIA_UAU.1.1, the PP/ST author should specify a list of TSF-mediated actions that can be performed by the TSF on behalf of a user before the claimed identity of the user is authenticated. This list cannot be empty. If no actions are appropriate, component FIA_UAU.2 should be used instead. An example of such an action might include the request for help on the login procedure.
FIA_UAU.2 User authentication before any action
User application notes
This component requires that users are identified before any TSF-mediated action can take place on behalf of that user.
FIA_UAU.3 Unforgeable authentication
User application notes
This component addresses requirements for mechanisms that provide protection of authentication data. Authentication data that is copied from another user, or is in some way constructed should be detected and/or rejected. These mechanisms provide confidence that users authenticated by the TSF are actually who they claim to be.
This component may be useful only with authentication mechanisms that are based on authentication data that cannot be shared (e.g. biometrics). It is impossible for a TSF to detect or prevent the sharing of passwords outside the control of the TSF.
Operations
Selection:
In FIA_UAU.3.1, the PP/ST author should specify whether the TSF will detect, prevent, or detect and prevent forging of authentication data
In FIA_UAU.3.2, the PP/ST author should specify whether the TSF will detect, prevent, or detect and prevent copying of authentication data
FIA_UAU.4 Single-use authentication mechanisms
User application notes
This component addresses requirements for authentication mechanisms based on single-use authentication data. Single-use authentication data can be something the user has or knows, but not something the user is. Examples of single-use authentication data include single-use passwords, encrypted time-stamps, and/or random numbers from a secret lookup table.
The PP/ST author can specify to which authentication mechanism(s) this requirement applies.
Operations
Assignment:
In FIA_UAU.4.1, the PP/ST author should specify the list of authentication mechanisms to which this requirement applies. This assignment can be 'all authentication mechanisms'. An example of this assignment could be "the authentication mechanism employed to authenticate people on the external network".
FIA_UAU.5 Multiple authentication mechanisms
User application notes
The use of this component allows specification of requirements for more than one authentication mechanism to be used within a TOE. For each distinct mechanism, applicable requirements must be chosen from the FIA class to be applied to each mechanism. It is possible that the same component could be selected multiple times in order to reflect different requirements for the different use of the authentication mechanism.
The management functions in the class FMT may provide maintenance capabilities for the set of authentication mechanisms, as well as the rules that determine whether the authentication was successful.
To allow anonymous users to be on the system, a `none' authentication mechanism can be incorporated. The use of such access should be clearly explained in the rules of FIA_UAU.5.2.
Operations
Assignment:
In FIA_UAU.5.1, the PP/ST author should define the available authentication mechanisms. An example of such a list could be: "none, password mechanism, biometric (retinal scan), S/key mechanism".
In FIA_UAU.5.2, the PP/ST author should specify the rules that
describe how the authentication mechanisms provide authentication
and when each is to be used. This means that for each situation the set
of mechanisms that might be used for authenticating the user must be
described. An example of a list of such rules is:
"if the user has special privileges a password mechanism and a
biometric mechanism both shall be used, with success only if both
succeed; for all other users a password mechanism shall be used."
The PP/ST author might give the boundaries within which the authorised administrator may specify specific rules. An example of a rule is: "the user shall always be authenticated by means of a token; the administrator might specify additional authentication mechanisms that also must be used." The PP/ST author also might choose not to specify any boundaries but leave the authentication mechanisms and their rules completely up to the authorised administrator.
User application notes
This component addresses potential needs to re-authenticate users at defined points in time. These may include user requests for the TSF to perform security relevant actions, as well as requests from non-TSF entities for re-authentication (e.g. a server application requesting that the TSF re-authenticate the client it is serving).
Operations
Assignment:
In FIA_UAU.6.1, the PP/ST author should specify the list of conditions requiring re-authentication. This list could include a specified user inactivity period that has elapsed, the user requesting a change in active security attributes, or the user requesting the TSF to perform some security critical function.
The PP/ST author might give the boundaries within which the reauthentication should occur and leave the specifics to the authorised administrator. An example of such a rule is: "the user shall always be re-authenticated at least once a day; the administrator might specify that the re-authentication should happen more often but not more often than once every 10 minutes."
FIA_UAU.7 Protected authentication feedback
User application notes
This component addresses the feedback on the authentication process that will be provided to the user. In some systems the feedback consists of indicating how many characters have been typed but not showing the characters themselves, in other systems even this information might not be appropriate.
This component requires that the authentication data is not provided as-is back to the user. In a workstation environment, it could display a `dummy' (e.g. star) for each password character provided, and not the original character.
Operations
Assignment:
In FIA_UAU.7.1, the PP/ST author should specify the feedback related to the authentication process that will be provided to the user. An example of a feedback assignment is "the number of characters typed", another type of feedback is "the authentication mechanism that failed the authentication".
This family defines the conditions under which users are required to identify themselves before performing any other actions that are to be mediated by the TSF and that require user identification.
FIA_UID.1 Timing of identification
User application notes
This component poses requirements for the user to be identified. The PP/ST author can indicate specific actions that can be performed before the identification takes place.
If FIA_UID.1 is used, the TSF-mediated actions mentioned in FIA_UID.1 should also appear in this FIA_UAU.1.
Operations
Assignment:
In FIA_UID.1.1, the PP/ST author should specify a list of TSF-mediated actions that can be performed by the TSF on behalf of a user before the user has to identify itself. If no actions are appropriate, component FIA_UID.2 should be used instead. An example of such an action might include the request for help on the login procedure.
FIA_UID.2 User identification before any action
User application notes
In this component users will be identified. A user is not allowed by the TSF to perform any action before being identified.
An authenticated user, in order to use the TOE, typically activates a subject. The user's security attributes are associated (totally or partially) with this subject. This family defines requirements to create and maintain the association of the user's security attributes to a subject acting on the user's behalf.
FIA_USB.1 User-subject binding
User application notes
The phrase "acting on behalf of" has proven to be a contentious issue in previous criteria. It is intended that a subject is acting on behalf of the user who caused the subject to come into being or to be activated to perform a certain task. Therefore, when a subject is created, that subject is acting on behalf of the user who initiated the creation. In case anonymity is used, the subject is still acting on behalf of a user, but the identity of the user is unknown. A special category are the subjects that serve multiple users (e.g. a server process). In such cases the user that created this subject is assumed to be the 'owner'.