Policy, Trust and Technology

Mitigating Risk in the Digital World

David L. Wasley

Camp 2006

© David L. Wasley, 2006

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

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

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

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

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

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?

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)

Bridged PKIs Enables trust across

communities Each campus retains

its own trust anchor Policy is mapped

through the Bridge Bridges can/will

interconnect too

Bridged PKI trust model RP trusts its TA to

map “trust” (CP OIDs) appropriately

TA trusts Bridge tomap “trust” appropriately Trust Broker

Policy is critical!

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

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

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

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

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

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

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

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

Assurance Level 4 Requires PKI on hardware device with

enforced PIN timeout FIPS 140-2 Level 2 or higher Guard against session hijacking

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

eAuth CAF Level 1-2 CAP

eAuth CAF Level 1-2 CAP

eAuth CAF Level 1-2 CAP

eAuth CAF Level 1-2 CAP

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?

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

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

Triumverate Each has policy

Credential binds a physical person to an identifier

IdM ensure reliable informationassociated withthat identifier

Federation policydefines for a community

Together they define a basis for intra- and inter-domain trust

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.