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 Pilot Who
Cornell University
Penn State
University of Maryland at Baltimore County
University of Washington
General Services Admin-istration

4. Higher Ed - eAuthentication Pilot What
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 Pilot The 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 Pilot Findings
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
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. Summary of Assessment Factors
eAuthentication Credential Assessment Profile
Summary of Assessment Factors

13. Summary of Assessment Factors
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 ] NIST Special Publication version 1.0.1