Identity Assurance: Can You Trust Me Now? RL "Bob" Morgan University of Washington/Internet2/InCommon CSG, San Diego, January 2010

Identity Assurance:Can You Trust Me Now?

RL "Bob" MorganUniversity of Washington/Internet2/InCommon

CSG, San Diego, January 2010

CSG Identity Assurance Workshop, Jan 2010

3

Topics

Basics Assurance elements Assurance infrastructure Campus issues Various nagging questions


4

A moral tale: grade submission at UW

longtime paper process focused on ... paper course bubble sheets distributed to

departments eventually get to instructors, or someone who

fills them out, and signs them someone, usually dept staff, gets them to

dropbox in registrar's office registrar's staff processes, scans, nags about

late sheets, ...


5

Online submission process

Instructors enticed by gradebook app in LMS Users sign on to LMS with UW NetID Instructor of record inserts grades into course

page, reviews, clicks submit Registrar's office nags about late

submissions ... Many obvious improvements, but some new

risks too


6


7

Relying on new stuff

Old process relied on longtime practices, personal relationships, physical stuff

New process relies instead on: Integrity of LMS, and its connection to SIS Accuracy of authorization to course pages Reliability of UW NetID system

in all its parts: signon system, password protection, client system security, user behavior, incident handling, ...


8

Raising questions ...

Should we use two-factor authentication? extra cost, hard to use for some faculty hard to integrate into LMS (it has been working fine with

single-factor only) how do our data-protection policies apply? are other schools using two-factor for this? are there regulations that tell us what to do? is

someone developing standards? Do we know who the TAs are?

more generally, who has what rights on a course


9


10

Basics of identity assurance

Starting point is risks to apps/services apps seek to manage risks cost-effectively identity risks are only one class of risks

What is identity? from app point of view, it is anything about a requesting

party on which access decisions can be made maybe just a userid, maybe lots of other info (group,

role, usage history, location, etc) When identity is externalized service, app

seeks formal guarantees, i.e. assurance


11

One size doesn't fit all

Apps have many kinds of resources to protect, different budgets to do so can't afford "the best" identity practices always

High-assurance practices are intrusive to users showing identity docs, coming to help desk, two-factor,

etc; so even if affordable, users will revolt Hence, a range of useful identity management

practices balancing costs and risks and agreements between identity management

systems and apps on what the options are


12

Elements of IdM practice

... about which apps might want assurance Registration and identity proofing

creation of record in IdM system for a person external validation of personal information obtaining/verifying contact information

Credential assignment e.g., username and password establishment so

authentication acts can be tied to registered person also includes re-establishment as needed (aka

password reset)


13

Elements of IdM practice

Authentication services technology by which users establish authenticated

sessions with applications wide range of technologies with

cost/usability/effectiveness/risk tradeoffs User information management

information often used by apps for decisions various kinds of identifiers roles, groups, privileges, etc.


14

Elements about IdM operators

Organizational maturity documented procedures authority over population/orgs in question

Operations change-management and security practices helpdesk and user support logging and records management user privacy management


15

"Levels of Assurance"

Several sets of criteria by which apps might rate IdM systems and many options within each set, e.g. many different

authentication technologies, proofing methods IdM systems serve many apps

expensive to tailor option sets to serve each one apps are not the idM experts; they want to rely on

"acceptable practices" from IdM services Better for all if standard sets of practices can be

defined, roughly consistent cost/risk-wise


16


17

USG leads the way

OMB 04-04, December 2003 promotes e-authentication for e-government, using

external identity providers describes four levels of risk and corresponding levels of

identity assurance, directs NIST to develop tech standards

"important to match LoA against cost and burden of solution"

chartered US E-Authentication program run by GSA, to be "US government federation"


18

E-Auth and NIST 800-63

E-Auth established program to evaluate IdPs aka "credential service providers" based on the four levels

NIST developed "Electronic Authentication Guideline", SP 800-63, in 2004 technical guidance on identity proofing and

authentication technology, specifying the four levels E-Auth incorporated this into its Credential

Assessment Framework several universities evaluated under it, in 2005


19

The Four Levels

OMB 04-04 says: (1) "little or no", (2) "some", (3) "high", (4) "very high"

in more useful terms: L1: typical Internet account

no tie to real-world identity, just repeatable authentication L2: standard business practice

person identified, good password practices L3: extra-secure business practice

small number of users, two-factor authn L4: if you have to ask, you can't afford it


20


21

The USG moves on ...

E-Auth has some problems funding not stable, not serving needs of agencies ... shut down March 2009

Agencies succeed in federation on their own e.g. NIH working with InCommon Federation, using

technologies/practices consistent with CAF/800-63 GSA reorganizes, promotes this approach

new ICAM office centralizes identity work agencies OK if practices "comparable"

InCommon Federation fills the vacuum ...


22

InCommon Identity Assurance

"our version" of E-Auth CAF improved, a little HE-specific supports InCommon certifying IdPs as compliant with

assurance profiles consistent with E-Auth levels 1 and 2 motivated initially by interest in working with higher-

sensitivity apps at NIH and NSF 2 documents: framework and profiles will be supported by InC program

processes, fees, support, etc. taking applications in 2010 ...


23

InCommon Assurance documents

Identity Assurance Assessment Framework describes overall approach, processes role of IT organization, auditors

Bronze/Silver Profiles details of compliance elements much taken verbatim from E-Auth CAF also in "auditor-friendly" checklist form

published November 2008 accepted by USG for use with agencies? well ...


24

Gov 2.0

Obama administration seeks to transform government transparency, delivery via web new federal CIO is big fan of Web 2.0, social

networking, encourages agencies to adopt new techniques

social networking depends on identity, is closely associated with OpenID

OpenID now supported by major consumer services: Google, Live, Yahoo, Facebook, Paypal, etc, with hundreds of millions of users

mandate from CIO to support OpenID


25


26

A big tent for protocols, trust providers

ICAM creates more modular structures not just SAML and PKI, but process for blessing other

identity protocols, aka "Identity Scheme Adoption" not just GSA evaluating IdPs, but a process for blessing

other entities to create trust criteria and do certifications, aka "Trust Framework Provider Adoption", mostly copied from CAF/800-63

"comparability" is the principle documents published summer 2009

profiles for OpenID (Level 1 only), Information Card protocols some organizations rev up to be TFPs ...


27


28

Who ya gonna trust?

Kantara Initiative successor to Liberty Alliance, working in many identity

areas has had industry-oriented group working on its own

Assurance Framework, also parallel to CAF, for several years; docs published mid-2009

setting up operational Assurance Certification process quite similar to InCommon, taking applications now

has applied to GSA to be Trust Framework Provider may be useful resource for InCommon going forward


29

Who ya gonna trust? (2)

OpenID Foundation and Information Card Foundation industry groups promoting protocol adoption newly empowered by government interest developed "Open Identity Framework" model,

promoting it in various venues; used InCommon docs as starting point

channeling interests of many commercial providers: Google, Yahoo, Equifax, others

vision to "add the trust to OpenID" applying to GSA to be TFP


30

Who ya gonna trust? (3)

InCommon applying to be TFP ... at some point Formal approval necessary ... at some point

some uncertainty re SAML protocol a little privacy issue ...


31

Assurance and privacy

TFP document is mostly traditional assurance material, but adds new privacy criteria motivated by privacy concerns of, e.g., people using

Google accounts to access government services New requirements on IdPs:

Adequate notice: users must be notified about use of federated authn

Opt-in: users must opt in before info is sent Minimalism: only required info is sent not clear how these apply to business-to-gov situations


32

Dealing with ICAM privacy reqs

InCommon developing privacy addendum to its assurance program notion is that universities (a) have privacy policies that

say only minimal info is sent, (b) do inform users about use of federated signon with third parties, and (c) participation in business/academic processes constitutes opt-in

university IdPs would assert they do these things seeking comments on this soon ... likely a useful part of federation program going forward,

even with non-USG apps


33

Assurance on the wire: NIH and InC

working with NIH on federation since ... researchers from ~25 universities accessing CTSA

since 2008, several other apps level what? agreement to consider all InCommon

members to be Level 1, for now working on pilot for eRA research-admin app, requires

Level 2, working out tech details now will converge with some campuses being approved for

Silver in ... 2010? will converge with InCommon being approved by ICAM

as TFP in ... 2010?


34

Assurance standards in action

New FERPA rules 2009 suggest that student data protection requires "good"

authentication practice, but how good is good? working to get InCommon Silver blessed for this

National Student Clearinghouse new student-self-service access, raises authentication

quality issues, they want to impose standards on campuses

working to get Silver blessed for this also for access to Meteor student loan system


35


36

What's a campus to do?

Work to comply with standard (e.g. InC Silver)? maybe; some campuses are doing this, such as CIC is "achieving compliance" the same as "making a better

campus IAM system"? up to a point ... useful for engaging communities: CISO, audit, medical,

research, finance, etc, about IAM importance/reqs define its own levels/profiles?

do the four levels really meet your (our) needs? some think there may be use in a 1.5, or some non-

numeric label: "useful for applying to university" e.g.


37


38

What means compliance?

To meet Silver do all users have to be Silver? no: it is fine for one IdM system to have user entries at

many different levels one user might be at different levels at different times

depending on how they signed on (e.g. two-factor, or location)

but system as a whole must meet Silver system criteria lifecycle considerations of moving between levels;

need to label entries with assurance-related data? e.g. "process used to identity-proof"?

but still: lots of people all at once, or one at a time?


39

Can we rely on existing processes?

If we can't ... can this work at scale? IAF permits orgs to use "existing relationships" Employees

federal I-9 should be universal, and good enough, for id proofing, but account setup?

Students student lifecycle starting very early now, does this

compromise, or imply explicit L1->L2 transition? Alum/Affiliates/Armies of Gray

many looking at aligning sponsorship with formal levels Remote proofing an issue across all populations


40


41

Who does the audit?

InCommon permits university internal audit if sufficiently independent from IT organization and if auditor meets qualifications: knowledgeable

about IdM issues and InC framework, etc. need for training/engagement with university audit

community Could be that industry auditors fill the need

e.g. those approved by Kantara program Can audits we already do serve the purpose?


42

Password issues

Interpreting password-protection requirements is hardest technical part of compliance model assumes service set up just for federation, with

only one store and one service interface, but this is unrealistic in any organization of any size

e.g., if passwords are synced with Google or Windows Live, is that a non-compliant exposure?

how about LDAP authentication used with many campus/external applications?

how about password reset??? who will make these judgment calls?


43

Documents

Identity Assurance: Can You Trust Me Now? RL "Bob" Morgan University of Washington/Internet2/InCommon CSG, San Diego, January 2010