I-0029: Permissible Probability Of Undetected Compromise

NUMBER:               I-0029
STATUS:               Tabled
REASON:               We felt this was more a policy decision than a technical
                      issue, and that the issue was not of pressing need.

TITLE:                Permissible Probability Of Undetected Compromise

FIRST POST:            [criteria 2183]

REQUIREMENT:          Identification and Authentication
CRITERIA CLASSES:     C2, B1, B2, B3, A1
DOCUMENT(S):          Security Features Users Guide
RELATED TO:           <None>

STATEMENT:

The following interprets the sentence ``Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity.''

The probability of undetected compromise of a product's identification and authentication mechanism (or combined probability, if multiple mechanisms are employed), when used as directed by the TFM and SFUG, shall not exceed 1 in 1,000,000 for a single TCB-visible attempt to defeat the mechanism.

PROJECTED IMPACT:

This may require an additional SFUG recommendation on password choice for some products.

SUPPORT:

This interpretation places an arbitrary lower bound on the quality of the ``protected mechanism'' used for authentication. Although some environments may be satisfied with a worse bound, and others may require better, this is chosen to reflect a wide variety of operational needs. A password mechanism that supports at least 4-character alphanumeric passwords (or 5-character alphabetic) is acceptable.

The TCSEC does not place any specific requirements on the quality of an identification and authentication mechanism, which implies for example that a product that supported only single-character passwords could still meet the requirement. This is obviously inappropriate, and evaluation practice has been to place stronger requirements on the quality of mechanism, but without any quantitative guidance.

For example, a product that includes SFUG recommendations on good password choices and audits invalid login attempts would satisfy this interpretation, as long as the recommendations can be shown to describe a large set of potential passwords and the product's password storage cannot itself be compromised.

A product that depends on the Version 4 Kerberos authentication protocol (as generally employed, without further restrictions) does not satisfy this interpretation, because the Kerberos tickets are inherently available for offline attack. Because a 56-bit Kerberos key can be determined by exhaustive search in less than 10**17 trials, and computers (PC-class) that can perform 10**11 trials in reasonable time are commercially available at modest cost, the probability of compromise does not exceed 1 in 10**6. Note that this argument is valid regardless of the quality of the encryption used in Kerberos; it depends solely on the number of possible values for the key.

Similarly, a product that stores passwords in one-way hashed form in a location accessible to untrusted subjects does not satisfy this interpretation, again because of the ability to perform exhaustive search.

A product that allows user-chosen passwords, but includes no recommendations on sound password choices in the SFUG, does not satisfy this interpretation, because empirical evidence shows that people choose passwords that are easily guessable. This is true even if the product audits invalid login attempts (as is required for C2), as the probability of guessing a password chosen from that typically small set is much better than 1 in 10**6. Of course, SFUG guidance cannot guarantee that users will choose good passwords, but that problem is outside the scope of the evaluation.