1. Policy, Trust and Technology Mitigating Risk in the Digital World David L. Wasley Camp 2006 © David L. Wasley, 2006

2. Outline Policy is not an IT issue Why “trust” can be an IT issue The PKI trust model The federation trust model Other notable trust models Lots of Q & A

3. Why do we need policy? Trust is about mitigating risk Think about credit cards FDIC ruling re on-line banking Policy defines how the organization views risks and requires mitigation Establishes a basis for trust

4. Policy is not an IT issue Policy is a business issue, defined and developed by executive management Needs organizational weight behind it Policy reflects institutional goals and choices Sets the framework for practices

5. Policy (cont.) Not prescriptive but descriptive Specifics change Principles don’t (as often) IT supports policy using technology Must take into account external “policy” too Auditors evaluate conformance Reassures management & others

6. Why trust can be an IT issue IT provides tools and services, e.g. Managing secure infrastructure Supporting strong credentials Detecting and containing problems The big picture is a “trust fabric” Ensuring security and authenticity The weak link is usually people...

7. Implementing trust across boundaries Contracts Less formal agreements, e.g. MOA Stated policies Referrals from others you trust Community Standards (BCP) How is any of this instantiated?

8. The PKI trust model Root of the hierarchy defines “policy” This is the Trust Anchor Relying parties choose which policy(s) to trust Certs must contain one of the trusted policies Few applications do this (yet)

9. Bridged PKIs Enables trust across communities Each campus retains its own trust anchor Policy is mapped through the Bridge Bridges can/will interconnect too

10. Bridged PKI trust model RP trusts its TA to map “trust” (CP OIDs) appropriately TA trusts Bridge to map “trust” appropriately Trust Broker Policy is critical!

11. Identity Federations Otherwise independent entities that give up some degree of autonomy to achieve a common goal Essence of federation includes: Common semantics (identity attributes, etc.) Common syntax (protocols for exchange) Common basis for trust

12. Federation trust model Federation operator defines standards for the community May define various “levels of assurance” Operator evaluates Participants... Participants agree to abide by the policy Operator can request audits to verify this Metadata about Participants is distributed Relying Parties decide what they accept

13. Assurance Levels (OMB M-04-04) 1.Little or no confidence exists in the asserted identity; essentially a persistent identifier 2.Confidence exists that the asserted identity is accurate; appropriate for a wide range of business with the public; application verifies identity 3.High confidence in the asserted identity’s accuracy; Use to access restricted web services without the need for additional identity assertion controls 4.Very high confidence in the asserted identity’s accuracy. Use to assert identity and gain access to highly restricted web resources

14. NIST Authentication Guidelines Basis for eAuth federation credential assessment framework Builds on OMB four levels of identity assurance Focuses on identity credential primarily Levels 3 & 4 require PKI Go to http://csrc.nist.gov/publications/nistpubs/ See Special Publication 800-63

15. NIST 800-63 (cont.) Four areas discussed: Identity proofing, registration and the delivery of credentials which bind an identity to a token Tokens (typically a cryptographic key or password) for proving identity Remote authentication mechanisms, that is the combination of credentials, tokens and authentication protocols used to establish that a claimant is the subscriber s/he claims to be Assertion mechanisms used to communicate the results of a remote authentication to other parties

16. Assurance Level 1 Minimal ID proofing at registration Prove subject has possession of token No clear text passwords on networks Protect password files Guard against password guessing Sometimes called account lockout Password strength > 2 -10

17. Assurance Level 2 Use of government issued IDs to register Crypto to prevent capture and replay Credential revocation within 72 hrs Stronger protection of password file Password strength > 2 -14

18. Assurance Level 3 Requires PKI or “one-time password device” holding a symmetric crypto key Cert and private key can be in cache Require password or biometric to unlock Crypto must be FIPS 140-2 Level 1 Must use realtime proof of possession Guard against man-in-the-middle attack Credential revocation within 24 hours

19. Assurance Level 4 Requires PKI on hardware device with enforced PIN timeout FIPS 140-2 Level 2 or higher Guard against session hijacking

20. eAuth Credential Assessment Implementation of NIST 800-63 Framework (CAF) describes process for evaluating credential service providers Profiles identify issues for each LOA Password CAP for Levels 1 & 2 PKI CAP for levels 3 & 4 GSA does assessment for eAuth credential service providers

21. eAuth CAF Level 1-2 CAP

25. About Identity Management Where in the organization is this function? Who is in the IdM repository? What do you need to know about them? Where’s the authoritative source? How is the repository managed? Who/what gets access to it? How is privacy protected?

26. Other communities of trust PGP - in person exchange of keys OpenID - self asserted identity vouched for by referrals (i.e. reputation) See http://openid.net/ eBay - buyer feedback ratings USHER U.S. Higher Education (PKI) Root

27. USHER Intentionally minimal “policy” See pki-lite http://middleware.internet2.edu/hepki-tag/pki-lite/pki-lite- policy-practices-current.html Basically “Do what you do for student IDs” Trust is based on community Focus is on using the technology Stronger “policy” can come later

28. Triumverate Each has policy Credential binds a physical person to an identifier IdM ensure reliable information associated with that identifier Federation policy defines for a community Together they define a basis for intra- and inter-domain trust

29. Q & A dlwasley@earthlink.net © David L. Wasley, 2006. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.