Criteria for LOA 2

NOTE: LOA 2 PKI is out of scope for this document, and is addressed in Criteria and Methodology For Cross Certification With the U.S. Federal Bridge Certification Authority (FBCA) or Citizen and Commerce Class Common Certification Authority (C4CA). For Assurance Level 2 non-PKI authentication (e.g., memorized secret token), the following applies. NOTE: When PKI certificate-based authentication is to an Identity Provider (rather than directly to the RP), assertion processing is also required and must additionally follow assertion table trust criteria.

cite #ri Registration and Issuance

1) A trusted relationship always exists between the RA and Identity Provider.
Mechanisms and policies should be in place to ensure each party and its obligations are known to the other.
2) Sensitive data collected during the registration and identity proofing stage must be protected at all times (e.g. transmission and storage) to ensure its security and privacy.
Sufficiently protect all sensitive data including PII (as defined by the Federal Government; See Appendix C) obtained during registration and identity proofing.
3) Resist token issuance disclosure threat.
Issue token in a manner that protects confidentiality of information.
4) Resist token issuance tampering threat.
Establish a procedure that allows the Subscriber to authenticate the CSP as the source of any token and credential data that he or she may receive.
5) Resist unauthorized token issuance threat.
Establish procedures to ensure that the individual who receives the token is the same individual who participated in the registration procedure.
6) To ensure that the same party acts as Applicant throughout the process, the Applicant shall identify himself/herself in any new electronic transaction (beyond the first transaction or encounter) by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s phone number, email address, or physical address of record. The Applicant shall identify himself/herself in person by either using a secret as described above, or through the use of a biometric that was recorded during a prior encounter.
Registration, identity proofing, and token and credential issuance represent different goals of the same process. In many cases, however, this process may be broken up into a number of separate physical encounters and electronic transactions. (Two electronic transactions are considered to be separate if they are not part of the same protected session.) In these cases, the following methods shall be used to ensure that the same party acts as Applicant throughout the process.
7) Resist repudiation of registration threat.
Protect against a Subscriber denying registration, claiming that they did not register that token.
8) Applicant undergoes identity proofing by a trusted Registration Authority (RA).
Requires presentation of identifying materials or information.
9) Either the RA or the Identity Provider shall maintain a record of each individual whose identity has been verified, and the steps taken to verify his or her identity, including the evidence required below.
A record of the facts of registration and proofing.
10) The Identity Provider shall be prepared to provide records of identity proofing to Relying Parties as necessary.
In the event of detected or suspected identity fraud the Identity provider may be required to provide the detailed records of registration and credential issuance as part of an investigation.
11) The identity proofing and registration process shall be performed according to a written policy or practice statement that specifies the particular steps taken to verify identities.
The practice statement should address primary objectives of registration and identity proofing.
12) If the RA and Identity Provider are remotely located, and communicate over a network, the entire registration transaction between the RA and Identity Provider shall be cryptographically authenticated using an authentication protocol that meets Level 2 requirements, and any secrets transmitted shall be encrypted using an Approved encryption method.
See Appendix C for definition of “Approved”.
13) The Identity Provider shall be able to uniquely identify each Subscriber and the associated tokens and the credentials issued to that Subscriber. The Identity Provider shall be capable of conveying this information to Verifiers and Relying Parties.
Ensure a person with the applicant’s claimed attributes exists, and those attributes are sufficient to uniquely identify a single person.
14) The name associated with the Subscriber may be pseudonymous but the RA or Identity Provider shall know the actual identity of the Subscriber. In addition, pseudonymous Level 2 credentials must be distinguishable from Level 2 credentials that contain meaningful names.
Associate a person’s pseudonym to the person’s real name. Support a mechanism to specify whether the name in the credential is real or pseudonym.
15) The results of the identity proofing step (which may include background investigations of the Applicant) have to be protected to ensure source authentication, confidentiality and integrity. Sufficiently protect all identity proofing information and ensure it comes from known, trusted sources.
16) Applicant supplies his or her full legal name, an address of record, and date of birth, and may, subject to the policy of the RA or CSP, also supply other individual identifying information.
17) For In-Person Proofing – Possession of a valid current primary Government Picture ID that contains Applicant’s picture, and either address of record or nationality (e.g. driver’s license or Passport). Inspect photo-ID, compare picture to Applicant, record ID number, address and DoB. If ID appears valid and photo matches Applicant then: (a) If ID confirms address of record, authorizes or issues credentials and sends notice to address of record, or; (b) If ID does not confirm address of record, issues credentials in a manner that confirms address of record.
If ID does not confirm address of record, then the issuance process should include a mechanism to confirm the address
18) For Remote Proofing – Possession of a valid Government ID (e.g. a driver’s license or Passport) number and a financial account number (e.g., checking account, savings account, loan or credit card) with confirmation via records of either number. Inspect both ID number and account number supplied by Applicant (e.g. for correct number of digits). Verifies information provided by Applicant including ID number OR account number through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address other personal information in records are on balance consistent with the application and sufficient to identify a unique individual. Address confirmation and notification: (a) Sends notice to an address of record confirmed in the records check or; (b) Issues credentials in a manner that confirms the address of record supplied by the Applicant; or (c) Issues credentials in a manner that confirms the ability of the Applicant to receive telephone communications or e-mail at number or e-mail address associated with the Applicant in records. Any secret sent over an unprotected channel shall be reset upon first use.
19) If the exact number of tokens to be issued is not agreed upon early in the registration process, then the tokens should be distinguishable so that Verifiers will be able to detect whether any suspicious activity occurs during the first few uses of a newly issued token.
A common reason for breaking up the registration process as described above is to allow the subscriber to register or download software tokens in two or more different computing environments. This is permissible as long as the tokens individually meet the appropriate assurance level.
20) Federally regulated financial institutions, brokerages and dealers may issue credentials to their customers via the mechanisms normally used for on-line banking or brokerage credentials, and may use on-line banking or brokerage credentials and tokens as Level 2 E-authentication credentials and tokens, provided they meet the provisions Level 2.
Federal law, including the Bank Secrecy Act and the USA Patriot Act, impose a duty on financial institutions to “know their customers” and report suspicious transactions to help prevent money laundering and terrorist financing. Many financial institutions are regulated by Federal Agencies such as the Office of the Comptroller of the Currency (OCC) or other members of the Federal Financial Institutions Examination Council (FFIEC) and the Securities and Exchanges Commission (SEC). These regulators normally require the intuitions to implement a Customer Identification Program. These provisions apply to Federally regulated financial institutions, brokerages and dealers subject to such Federal regulation, that implement such a Customer Identification Program.

cite #tkns Tokens

1) Resist token theft threat.
Protect a token with a physical manifestation (e.g., one time password device, hardware cryptographic device) from being stolen by an Attacker.
2) Resist token duplication threat.
Protect against a Subscriber’s token being copied with or without his or her knowledge (e.g., use tokens that are hard to copy).
3) Resist social engineering threat.
Protect against an Attacker establishing a level of trust with a Subscriber in order to convince the Subscriber to reveal his or her token or token secret.
4) For memorized secret tokens, pre-registered knowledge tokens, look-up secret tokens, and out of band tokens, the probability that an Attacker can guess a valid authenticator, over the lifetime of the token, must be less than 2-14 (1 in 16,384).
The maximum probability that, over the life of the password, an Attacker with no a priori knowledge of the password will succeed in an in-band password guessing attack. See NIST SP 800-63 Appendix A for complete discussion.
5) When a multi-factor token or a multi-token authentication scheme is being used, the security properties of each factor or of each token are considered additive in nature. If one factor of a multi-factor scheme or one token of a multi-token scheme has the desired properties for a given assurance level, it is considered sufficient.
Combining multiple factors and/or multiple tokens may achieve a higher assurance level than would otherwise be attained.
6) For single token schemes that use one token to gain access to a second token, the compound solution is only as strong as the token with the lowest assurance level.
The solution is only as strong as its weakest link.
7) For memorized secret tokens, pre-registered knowledge tokens, look-up secret tokens, and out of band tokens, authenticators must have greater than 10 bits of min-entropy.
See NIST SP 800-63 Appendix A for complete discussion. Min-entropy is a measure of the difficulty that an Attacker has to guess the most commonly chosen password used in a system. When a password has n-bits of min-entropy then an Attacker requires as many trials to find a user with that password as is needed to guess an n-bit random quantity.
8) For out of band tokens, the authenticator must have a limited lifetime, on the order of minutes and can only be used once.
9) Single factor one time password devices must use Approved block cipher or hash function to combine a symmetric key stored on device with a nonce to generate a one-time password. The cryptographic module performing this operation shall be validated at FIPS 140-2 Level 1 or higher. The nonce may be a date and time, or a counter generated on the device. The one-time password must have a limited lifetime, on the order of minutes.
See Appendix C for definition of “Approved”. See Appendix B for reference to FIPS 140-2 document.
10) For single factor cryptographic devices, the cryptographic module shall be validated at FIPS 140-2 Level 1 or higher.
See Appendix B for reference to FIPS 140-2 document.

cite #tcm Token and Credential Management

1) Files of shared secrets used by Identity Providers at Level 2 shall be protected by discretionary access controls that limit access to administrators and only to those applications that require access. Such shared secret files shall not contain the plaintext passwords or secrets; two alternative methods may be used to protect the shared secret: (a) Passwords may be concatenated to a variable salt (variable across a group of passwords that are stored together) and then hashed with an Approved algorithm so that the computations used to conduct a dictionary or exhaustion attack on a stolen password file are not useful to attack other similar password files. The hashed passwords are then stored in the password file. The variable salt may be composed using a global salt (common to a group of passwords) and the username (unique per password) or some other technique to ensure uniqueness of the salt within the group of passwords. (b) Shared secrets may be stored in encrypted form using Approved encryption algorithms and modes, and the needed secret decrypted only when immediately required for authentication. In addition, any method allowed to protect shared secrets at Level 3 or 4 may be used at Level 2.
Sufficiently protect shared secrets such as passwords. See Appendix C for definition of “Approved”.
2) Long term shared authentication secrets, if used, shall never be revealed to any party except the Subscriber and Identity Provider (including Verifiers operated as a part of the Identity Provider); however, session (temporary) shared secrets may be provided by the Identity Provider to independent Verifiers. Cryptographic protections are required for all messages between the Identity Provider and Verifier which contain private credentials or assert the validity of weakly bound or potentially revoked credentials. Private credentials shall only be sent through a protected channel to an authenticated party to ensure confidentiality and tamper protection. The Identity Provider may send the Verifier a message, which either asserts that a weakly bound credential is valid, or that a strongly bound credential has not been subsequently revoked. In this case, the message shall be logically bound to the credential, and the message, the logical binding, and the credential shall all be transmitted within a single integrity protected session between the Verifier and the authenticated Identity Provider. If revocation is an issue, the integrity protected messages shall either be time stamped, or the session keys shall expire with an expiration time no longer than that of the revocation list. Alternatively, the time stamped message, binding, and credential may all be signed by the Identity Provider, although, in this case, the three in combination would comprise a strongly bound credential with no need for revocation.
Sufficiently protect long term shared authentication secrets.
3) The Identity Provider shall establish suitable policies for renewal and re-issuance of tokens and credentials. Proof-of-possession of the unexpired current token shall be demonstrated by the Claimant prior to the Identity Provider allowing renewal and re-issuance. Passwords shall not be renewed; they shall be re-issued. After expiry of current token, renewal and re-issuance shall not be allowed. All interactions shall occur over a protected channel such as SSL/TLS. Secondary credentials must never be renewed or re-issued.
4) Identity Providers shall revoke or destroy credentials and tokens within 72 hours after being notified that a credential is no longer valid or a token is compromised to ensure that a Claimant using the token cannot successfully be authenticated. If the Identity Provider issues credentials that expire automatically within 72 hours (e.g. issues fresh certificates with a 24 hour validity period each day) then the Identity Provider is not required to provide an explicit mechanism to revoke the credentials. Identity Providers that register passwords shall ensure that the revocation or de-registration of the password can be accomplished in no more than 72 hours. CAs cross-certified with the Federal Bridge CA at the Citizen and Commerce Class Basic, Medium and High or Common Certificate Policy levels are considered to meet credential status and revocation provisions of this level. Secondary credentials must have a lifetime less than 12 hours.
For PKI credentials, Federal ICAM relies on the proven criteria and methodology of the FPKIPA.
5) A record of the registration, history, and status of each token and credential (including revocation) shall be maintained by the Identity Provider or its representative. The record retention period of data for Level 2 credentials is seven years and six months beyond the expiration or revocation (whichever is later) of the credential. Identity Providers operated by or on behalf of executive branch agencies shall also follow either the General Records Schedule established by the National Archives and Records Administration or an agency-specific schedule as applicable. All other entities shall comply with their respective records retention policies in accordance with whatever laws apply to those entities.
6) Tokens can be renewed using out of band delivery mechanisms. If the Subscriber uses an out of band token delivery approach, re-registration of the delivery mechanism can be equated to token renewal or re-issuance. In such a case, the subscriber must use an alternate, yet already registered delivery mechanism to deliver the token and then gain access to the Identity Provider such that the registration data can be updated by the Subscriber or, if no alternate out of band channel was registered with the original out of band channel the subscriber must re-establish their identity with the Identity Provider in order to update their registration data.
7) The Identity Provider should establish policies for token collection to avoid the possibility of unauthorized use of the token after it is considered out of use.
The Identity Provider may destroy such collected tokens, or zeroize them to ensure that there are no remnants of information that can be used by an Attacker to derive the token value.

cite #ap Authentication Process

1) Resist online guessing threat.
Protect against an Attacker performing repeated logon trials by guessing possible values of the token authenticator.
2) Resist replay threat.
Protect against an Attacker being able to replay previously captured messages (between a legitimate Claimant and a Verifier) to authenticate as that Claimant to the Verifier.
3) Successful authentication requires that the Claimant shall prove, through a secure authentication protocol, that he or she controls the token.
Ensure that the Claimant (person being authenticated) actually possesses the token.
4) Plaintext passwords or secrets shall not be transmitted across a network.
A network is an open communications medium, typically the Internet, used to transport messages between the Claimant and other parties.
5) Resist session hijacking threat.
Protect against an Attacker being able to take over an already authenticated session by eavesdropping on or predicting the value of authentication cookies used to mark HTTP requests sent by the Subscriber.
6) Resist eavesdropping threat. Approved cryptography is required to resist eavesdropping.
Protect against an attack in which an Attacker listens passively to the authentication protocol to capture information which can be used in a subsequent active attack to masquerade as the Claimant. See Appendix C for definition of “Approved”.
7) Weakly resist man-in-the-middle threat.
Protect against an attack on the authentication protocol run in which the Attacker positions himself in between the Claimant and Verifier so that he can intercept and alter data traveling between them. A protocol is said to be weakly resistant to man-in-the-middle attacks if it provides a mechanism for the Claimant to determine whether he or she is interacting with the real Verifier, but still leaves the opportunity for the non-vigilant Claimant to reveal a token authenticator (to an unauthorized party) that can be used to masquerade as the Claimant to the real Verifier.
8) The authentication process shall provide sufficient information to the Verifier to uniquely identify the appropriate registration information that was (i) provided by the Subscriber at the time of registration, and (ii) verified by the RA in the issuance of the token and credential.
Ensure the authentication process can uniquely identify each Subscriber and the associated tokens and credentials issued to that Subscriber.
9) Session data transmitted between the Claimant and the Relying Party following a successful Level 2 authentication must be protected as described in the NIST FISMA guidelines. Specifically, all session data exchanged between information systems that are categorized as FIPS 199 “Moderate” or “High” for confidentiality and integrity, shall be protected in accordance with NIST SP 800-53 Control SC-8 (which requires transmission confidentiality) and SC-9 (which requires transmission integrity).
Protect data exchanged between the end user and the Relying Party. See Appendix B for reference to FIPS 199 and NIST SP 800-53 documents.

cite #asrtn Assertions

1) Use an ICAM adopted authentication scheme.
Use of any ICAM adopted authentication scheme defined for this assurance level is acceptable.