Federal Requirements for Credential Assessments

1. Federal Requirements for Credential Assessments Renee Shuey ITS – Penn State February 6, 2007

2. Higher Ed - eAuthentication Pilot • Organized around Levels of Assurance (LOA) • LOA 1 and 2 accept assertion-based credentials • Local authentication followed by identity message to agency application • Business and Legal rules imposed on applications and Credential Providers alike • LOA 3 and 4 imply cryptography-based • PKI dominates • Serviced by Federal PKI Policy Authority and Federal PKI Operational Authority • Major growth area for Federal Apps in first round

3. Higher Ed - eAuthentication PilotWho • Cornell University • Penn State • University of Maryland at Baltimore County • University of Washington • General Services Admin-istration

4. Higher Ed - eAuthentication PilotWhat • Institutional Credential Assessments, Jan '05 • Identified issues for meeting LOA1 requirements • Password guessing, strength, expiration • Authorization to Operate Statement • Stored secret (password resets) • Documentation • Align policies and practices • Proposed solution for cultural differences • Password guessing/Denial of Service Attacks

5. The Low Hanging Fruit

6. Higher Ed - eAuthentication PilotThe Low Hanging Fruit • NSF FastLane • An interactive, real-time system used to conduct NSF business over the Internet • Used by faculty to submit grant proposals, check proposal status, participate in panels, perform financial transactions and reports • Credential Service Provider assessed as LOA1 • Application assessed by GSA as LOA1

7. Higher Ed - eAuthentication PilotFindings • CAP GAP Analysis • 48% requirements met by all 3 schools • 25% requirements met by at least 1 school • 25% requirements not met by any • 2% not applicable • EAF Business & Operating Rules not obtainable/practical for HE • Institutional credential assessments would be difficult to scale for all of higher education

8. The Next Step - Interfed • It was determined that a more scalable and user friendly approach would be to establish trust between the federations • An initiative established to identify issues & propose solutions for linking federations

9. InCommon Participation Requirements • Common descriptive information • Software Guidelines • http://www.incommonfederation.org/ops/softguide.html • Transparency of Policy and Practices • POP (Participant Operational Practices) • Participation Agreement • Minimal “bar” to enter • Limited Liability; No Indemnification • General Liability Insurance • Modest application and annual fee

10. “The” Demo • Internet2 Fall Member Meeting • Demo - POC of interoperability of InCommon and eAuthentication Federations • Chest bumps were attempted, goose bumps were achieved

11. Credential Assessment Profile Summary of Assessment Factors

12. eAuthentication Credential Assessment Profile Summary of Assessment Factors

13. eAuthentication Credential Assessment Profile Summary of Assessment Factors

14. Credential Assessment Profile Level 1

15. Organizational Maturity Authorization to Operate • 1. The CS shall have completed appropriate authorization to operate (ATO) as required by the CSP policies. • 2. The CSP shall demonstrate it understands and complies with any legal requirements incumbent on it in connection to the CS.

16. Organizational Maturity General Disclosure • 1. The CSP shall make the Terms, Conditions, and Privacy Policy for the CS available to the intended user community. • 2. In addition, the CSP shall notify subscribers in a timely and reliable fashion of any changes to the Terms, Conditions, and Privacy Policy.

17. Authentication Protocol Secure Channel • Secrets transmitted across an open network shall be encrypted.

18. Authentication Protocol Stored Secrets • Secrets such as passwords shall not be stored as plaintext and access to them shall be protected by discretionary access controls that limit access to administrators and applications that require access.

19. Token Strength Resistance to Guessing • At this assurance level, the PIN (numeric-only) or Password, and the controls used to limit on-line guessing attacks shall ensure that an attack targeted against a selected user’s PIN or Password shall have a probability of success of less than 2-14 (1 chance in 16,384) over the life of the PIN or Password. • The PIN (numeric-only) or Password shall have at least 10 bits of min-entropy (a measure of the difficulty that an attacker has to guess the most commonly chosen password used in a system) to protect against untargeted attack.

20. Token Strength Uniqueness • 1. Each subscriber shall self-select at registration time a unique token (e.g., UserID + Password). • 2. A user can have more than one token, but a token can only map to one user. • 3. Unique tokens cannot be recycled after a subscriber leaves the CS.

21. Credential Assessment Profile Level 2

22. Organizational Maturity Documentation • 1. The CSP shall have all security related policies and procedures documented that are required to demonstrate compliance. • 2. Undocumented practices will not be considered evidence.

23. Organizational Maturity Audit • The CSP shall be audited by an independent auditor every 24 months to ensure the organization’s practices are consistent with the policies and procedures for the CS. At the time of the assessment, the most recent audit shall have been performed within the last 12 months.

24. Organizational Maturity Risk Mgt • The CSP shall demonstrate a risk management methodology that adequately identifies and mitigates risks related to the CS.

25. Organizational Maturity COOP • 1. The CSP shall have a Continuity of Operations Plan (COOP) that covers disaster recovery and the resilience of the CS. • 2. Service level agreements are not assessment criteria; they are covered in the licensing arrangements. • 3. The CS shall employ failure techniques to ensure system failures do not result in false positive authentication errors.

26. Organizational Maturity Network Security • The CSP shall protect their internal communications and systems with measures commensurate with Assurance Level 3 when those communications involve open networks.

27. Registration and Identity Proofing In Person Proofing • The Registration Authority (RA) shall establish the applicant’s identity based on 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) • RA inspects photo-ID, compares picture to applicant, records ID number, address and date of birth. If ID appears 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, issue credentials in a manner that confirms address of record.

28. Registration and Identity Proofing Remote Proofing • The RA shall establish the applicant’s identity based on 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. • RA inspects both ID number and account number supplied by applicant. 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, date of birth, address other personal information in records are on balance consistent with the application and sufficient to identify a unique individual.

29. Confirming Delivery Confirming Delivery The CSP shall issue or renew credentials and tokens in a manner that confirms any one of the applicant’s: • 1. Postal address of record; OR • 2. Fixed-line telephone number of record.

30. References • [FIPS-140-2] “Security Requirements For Cryptographic Modules”, Federal Information Processing Standard Publication 140-2, 1999. • [M-04-04] The OMB E-Authentication Guidance • [SP 800-63] NIST Special Publication 800-63 version 1.0.1