Appropriate Access

1. Appropriate Access InCommon Identity Assurance Profiles David L. Wasley Campus Architecture and Middleware Planning workshop February 2008

2. Outline • Access and Identity • Identity Assurance • InCommon Identity Assurance Profiles

3. Access and Identity • Modern distributed IT environments separate identity and access management • “single sign on” binds an identifier to a physical person • Necessary information about that person is given to resource access management systems that need it • autheNtication vs authoriZation • Why identity is important to security • Security is not just about building moats & walls • You’d like to locate the person who does a bad thing • Strong identity assurance also should help protect people against ID theft

4. Access and Identity • Modern distributed IT environments separate identity and access management • “single sign on” binds an identifier to a physical person • Necessary information about that person is given to resource access management systems that need it • autheNtication vs authoriZation • Why identity is important to security • Security is not just about building moats & walls • You’d like to locate the person who does a bad thing • Strong identity assurance also should help protect people against ID theft

5. Access Models • Authorization determines access to resources • Policy + process + mechanism + enforcement ... • Access Control List of specific persons • Requires specific identifier for each user • Access rules, based on group attributes • E.g., any “member of the campus community” • Access may also be based on parameters, e.g., resource availability, time of day, location of user, etc... • Access decision is made by resource manager

6. Identity Model • Identity is the set of information about a person • Unique attributes, e.g., biometric, U.S. President, ... • Group attributes, e.g., student, male, Joe Smith, ... • Pseudonymous attributes, e.g., the same person as before • Three parties involved • Identity Subject is a person who wants to assert an ID • Relying Party, e.g. Service Provider, trusts identity information received from an Identity Provider • Identity Provider agrees to support identity Subjects by maintaining a database or directory of reliable ID data • Each party must trust the others

7. Identity Model (cont.) • Digital credential is bound to a physical person • May, but need not, contain some identity information • Different credential technologies for different purposes • Binding achieved through a registration process • RA process must find existing record or create a new one • Credential S/N is index to Identity Mgmt DB • Credential S/N need not be same as Subject identifier • Relying Party uses IdM DB information as part of decision about access to services or resources • How good is a Provider’s assertion of an identity?

8. Identity Assurance • How reliable does an identity need to be? • Depends on what’s at stake, consequences & mitigations • Relying Party needs to do the risk analysis • How much can a RP trust an identity assertion? • What identity? • Does the RP trust the IdP as an organization? • How well was identity established and maintained? • How (and when) did the Subject authenticate to the IdP? • If something goes wrong, can the Subject be found? • Nothing is absolute; it’s all degrees of certainty

9. Identity Assurance Projects • NIST 800-63 • Federal eAuthentication • See also HSPD-12 and NIST FIPS 201 • Liberty Alliance Identity Assurance Framework • RealID “Final Rule” • FBI National Biometrics Database • InCommon Verified Identity Profiles ‡ • “Bronze”, “Silver”, … profiles ‡ Temporary name

10. InCommon Identity Assurance Profiles • Now in DRAFT and may change … • Structured sets of requirements intended to satisfy management of access to general classes of resources • Not necessarily hierarchical • Hopefully limited in number(!) • First two defined to be equivalent to eAuth • “Bronze” == eAuth levels 1 • “Silver” == eAuth level 2

11. Identity Assurance Assessment Framework • Business, Policy and Operational Factors • Registration and Identity Proofing • Digital Electronic Credential Technology • Digital Electronic Credential Issuance and Management • Security and Management of Authentication Events • Identity Information Management • Identity Assertion and Content • Technical Environment

12. InCommon “Silver” Profile • Business, Policy and Operational Factors • Established legal entity • • Designated authority for IdMS & IdP • • General Disclosures to identity Subjects • • Documentation of policies & practices • Appropriate staffing • Subcontracts • Helpdesk • Audit of IdMS operations • Risk Management plan • Logging of operation events

13. InCommon “Silver” (cont.) • Registration and Identity Proofing • Identity Verification Process disclosure • Retain records of Id documents And one or more of: • Confirmed relationship with the organization • In-person proofing • Remote proofing • Digital Electronic Credential Technology • Unique credential identifier • • Subject modifiable shared secret • • Strong resistance to guessing shared secret *

14. InCommon “Silver” (cont.) • Credential Issuance and Management • Unique Subject identifier • • Credential status • • Confirmation of delivery • Credential verification • Suspected credential compromise(†) • Credential revocation † indicates an InCommon variant from the NIST recommendations

15. InCommon “Silver” (cont.) • Security and Management of Authentication Events • End-to-end secure communications * • Proof of control • • Session authentication • • Stored secrets • • Protected secrets • Mitigate risk of sharing credentials • Threat protection * • Authentication protocols *

16. InCommon “Silver” (cont.) • Identity Information Management • Identity status management • Identity Assertion and Content • eduPerson attributes • (†) • Identity Assertion Qualifier • (†) • Cryptographic security • • Technical Environment • Configuration Management • Network Security • Physical Security • Continuity of Operations (†)

17. Implementation • Notify InCommon of intention to qualify • Assessment by independent (internal) auditor • Auditor writes summary letter for InCommon • Execute Addendum to Participation Agreement • InCommon adds Identity Assurance Qualifier(s) to IdP metadata • IdP then may include IAQ(s) in assertions • Is responsible to ensure they are appropriate • Technical implementation yet to be determined

18. Use of InCommon IAQs • IAQ represents a profile, not a level • A given IdP can support multiple profiles • IdP may assert InCommon IAQ(s) only if assigned to it by InCommon • Identity assertion may contain multiple IAQs • E.g., “Bronze” or both “Silver” and “Bronze” • Avoids implying hierarchy and allows for additions with minimal disruption • Relying Party looks for an IAQ it will accept

19. Further Information • InCommon Identity Assurance Profiles David Wasley <dlwasley@earthlink.net> • NIST 800-63 http://csrc.nist.gov/publications/PubsSPs.html • Liberty Alliance Identity Assurance Framework http://www.projectliberty.org/liberty/strategic_initiatives/identity_assurance • RealID http://www.dhs.gov/xprevprot/programs/gc_1200062053842.sht • FBI biometrics database http://www.washingtonpost.com/wp-dyn/content/article/2007/12/21/AR2007122102544.html