Criteria for LOA 3

LOA 3 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 3 non-PKI authentication (e.g., One Time Password device), the following applies. 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) The 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 each new electronic transaction by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s 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. Temporary secrets shall not be reused.
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.
A Subscriber denies registration, claiming that they did not register that token.
8) Applicant undergoes identity proofing by a trusted Registration Authority (RA).
Requires presentation and verification 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 in the sections 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
The record of the facts of registration and proofing.
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 3 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 shall be meaningful.
Verified real names, not pseudonyms.
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 verified current primary Government Picture ID that contains Applicant’s picture and either address of record or nationality (e.g. driver’s license or passport). Inspects Photo-ID and verify via the issuing government agency or through credit bureaus or similar databases. Confirms that: name, DoB, address and other personal information in record are consistent with the application. Compares picture to Applicant, record ID number, address and DoB. If ID is valid and photo matches Applicant then: (a) If ID confirms address of record, authorize or issue credentials and send 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.
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 both numbers. Verify information provided by Applicant including ID number AND 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 and other personal information in records are consistent with the application and sufficient to identify a unique individual. Address confirmation: (a) Issues credentials in a manner that confirms the address of record supplied by the Applicant; or (b) Issues credentials in a manner that confirms the ability of the Applicant to receive telephone communications at a number associated with the Applicant in records, while recording the Applicant’s voice or using equivalent alternative means to establish non-repudiation.
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 3 E-Authentication credentials and tokens, provided: (a) The customers have been customers in good standing for a period of at least 1 year prior to the issuance of E-auth credentials, and (b) The customers have appeared in-person before a representative of the financial institution, and the representative has inspected a Government issued primary Photo-ID and compared the picture to the customer. (c) The credentials and tokens meet all additional provisions of Level 3 as appropriate.
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.
21) PKI credentials shall be issued by a CA cross-certified with the FBCA under FBCA CP, Common CP, or C4 CP, or a policy mapped to one of those policies.
For PKI credentials, Federal ICAM relies on the proven criteria and methodology of the FPKIPA.

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) 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.
5) 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.

cite #tcm Token and Credential Management

1) Files of long-term shared secrets used by Identity Providers or Verifiers at Level 3 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 be encrypted so that: (a) The encryption key for the shared secret file is encrypted under a key held in a FIPS 140-2 Level 2 or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 cryptographic module and decrypted only as immediately required for an authentication operation. (b) Shared secrets are protected as a key within the boundary of a FIPS 140-2 Level 2 or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 cryptographic module and is not exported in plaintext from the module.
See Appendix B for reference to FIPS 140-2 document.
2) Identity Providers shall provide a secure mechanism to allow Verifiers or Relying Parties to ensure that the credentials are valid. Such mechanisms may include on-line validation servers or the involvement of Identity Provider servers that have access to status records in authentication transactions. Temporary session authentication keys may be generated from long-term shared secret keys by Identity Providers and distributed to third party Verifiers, as a part of the verification services offered by the Identity Provider, but long-term shared secrets shall not be shared with any third parties, including third party Verifiers. Approved cryptographic algorithms are used for all operations.
See Appendix C for definition of “Approved”.
3) Renewal and re-issuance shall only occur prior to expiration of the current credential. Claimants shall authenticate to the Identity Provider using the existing token and credential in order to renew or re-issue the credential. All interactions shall occur over a protected channel such as SSL/TLS.
4) Identity Providers shall have a procedure to revoke credentials and tokens within 24 hours. Verifiers shall ensure that the tokens they rely upon are either freshly issued (within 24 hours) or still valid. Shared secret based authentication systems may simply remove revoked Subscribers from the verification database. Secondary credentials must have a lifetime less than 2 hours.
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 3 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.
8) Token and credential verification services categorized as FIPS 199 “Moderate” or “High” for availability shall be protected in accordance with the Contingency Planning (CP) controls specified in NIST SP 800-53 to provide an adequate level of availability needed for the service.
See Appendix B for reference to FIPS 199 and NIST SP 800-53 documents.

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) Authentication is based on proof of possession of the allowed types of tokens through a cryptographic protocol. Authentication requires that the Claimant 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.
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) Approved cryptographic techniques shall be used for all operations including the transfer of session data.
Protect data exchanged between the end user and the Relying Party. See Appendix C for definition of “Approved”.
10) Resist phishing/pharming threat.
Protect against a phishing attack in which the Subscriber is lured (usually through an email) to interact with a counterfeit Verifier, and tricked into revealing information that can be used to masquerade as that Subscriber to the real Verifier; and against a pharming attach where an Attacker corrupts an infrastructure service such as DNS (Domain Name Service) causing the Subscriber to be misdirected to a forged Verifier/Relying Party, and revealing sensitive information, downloading harmful software or contributing to a fraudulent act.

cite #asrtn Assertions

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