1. PKI and LOA Establishing a Basis for Trust David L. Wasley PKI Deployment Forum April 2008

2. Outline Level of Assurance generally PKI LoA InCommon Identity Assurance Profiles PKI and Federated Identity

3. Level of Assurance generally Intent is to give Relying Party confidence in information it receives about a Subject Trust is based on many factors –No trust is perfect –Relying Parties must do risk analysis Build on existing conventions Mechanism must be practical –Excessive complexity won’t be acceptable

4. PKI LoA Based on Federal PKI model –One CP –4 levels of trust (plus “test”) –CP OIDs used to convey level –Allowed for mapping between PKI domains Copied by other PKIs –Pharma, aerospace, HEBCA, … “Meets or exceeds” implies asymmetry

5. PKI LoA factors include… Identity proofing process –In-person or remote, one or more primary documents, degree of verification Key generation and length Software vs. hardware key protection Key usage, multiple keys Validity period and re-key requirements

6. PKI LoA factors (cont.) Certificate delivery Whether private keys are escrowed Revocation requirements Operation and management of CA –Personnel controls –Physical and logical controls System software and hardware controls –Change management, disaster recovery, …

7. Implementation Trust within a PKI derives from root (TA) Each CA is audited against CP/CPS Relying Parties know which TA(s) to trust A Bridge CA might be able to map trust –May be asymmetrical! What’s in the cert is all RP learns about Subject –May be more than it should know –Note however the X.509 subjectInfoAccess field !

8. PKI strength & weakness Supports more than “identity” –Signing, data integrity, etc… –Hardware tokens are very strong credentials Certificates are awkward to update Software storage might be compromised –Esp. if cert can be exported w/private key Re-authentication may be impossible –A pitfall of SSO generally …

9. Identity Federation and LoA Federated IT environments separate identity and access management –AuthN binds an identifier to a physical person –Necessary information about that person is given to access management systems separately IdP issues credentials & stores attributes –Id proofing attempts to ensure uniqueness –Id attributes come from authoritative sources Assurance doesn’t have to be hierarchical –Different “profiles” for different use cases

10. 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, e.g., the same person as before Three parties involved –Identity Subject is who wants to claim an ID –Relying Party, e.g. Service Provider, trusts identity information received from an Identity Provider –Identity Provider supports identity Subjects by maintaining a database of reliable ID data Each party must trust the others

11. Identity Model (cont.) Digital credential is bound to a physical person –May, but need not, contain some identity information –Several credential technologies may be used –Binding achieved through a registration process –RA process finds existing record or creates 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 ID information as part of decision about access to services or resources Is Provider’s assertion of identity good enough?

12. Identity Assurance projects NIST 800-63-1 –Federal eAuthentication –See also M0404, HSPD-12 and NIST FIPS 201 Liberty Alliance Identity Assurance Framework RealID “Final Rule” FBI Biometrics Database InCommon Identity Assurance Profiles –“Bronze”, “Silver”,...

13. 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 comparable to eAuth –“Bronze” >= eAuth level 1 –“Silver” >= eAuth level 2 (~= FPKI Basic?)

14. Identity Assurance 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

15. 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

16. InCommon “Silver” (cont.) Registration and Identity Proofing –Identity Verification Process disclosure –Retain records of Id documents And one or more of: –Existing 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 *

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

18. InCommon “Silver” (cont.) Security and Management of Authentication Events –End-to-end secure communications * –Proof that Subject has control of credential –Session token authentication –Secure stored secrets –Restricted use of secrets –Mitigate risk of sharing credentials –Threat protection * –Authentication protocols *

19. 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 (†)

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

21. 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 IAQ(s) it will accept

22. PKI & Federation Similar trust models –Trusted authority vets adherence to profiles –Registration authority vets Subject identity –Assurance included in cert or assertion –Credential compromise is dealt with Threats are mitigated –Linking federations is like PKI bridging

23. PKI plus Federation The best of both worlds! PKI provides strong local authentication Federation provides rich, flexible identity –Also solves the TA problem PKI also supports S/MIME, signature, etc.

24. LoA is new & evolving How many profiles are needed? Should attributes have separate LoA? Must all attributes have the same LoA? How can we inter-federate and map LoA? Can anyone use SAML authNContext? Etc. etc. etc…

25. Further Information InCommon Identity Assurance Profiles –David Wasley 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