Technical Issues with Establishing Levels of Assurance

1. Technical Issues with Establishing Levels of Assurance Zephyr McLaughlin Lead, Security Middleware Computing & Communications University of Washington

2. Today’s Talk in one Slide • Overview of the University of Washington (UW) • Drivers for Levels of Assurance (LoA) • Application Perspective • User Perspective • Exploring the Solution Space

3. UW’s Environment • Central IT makes up about 1/4 of the IT staff • Central IT has very little control over what departmental applications do • Many diverse populations: • 80,000 + Faculty, Staff and Students (18,000 Med Ctr Employees) • 500,000 + Alumni and Affiliates • 1,000,000 + Patients • Other diverse populations (Cascadia Community College, WA State K-12 students, Library Patrons, etc.)

4. UW’s Enterprise Credential (UW NetID) • A large amount of effort has gone into making the UW NetID UW’s single enterprise credential. • More than 360,000 active UW NetIDs • 300,000+ more potential users (1,300,000 + if we include patients) • Our credentials are stored in both Kerberos and Windows AD • We have 5 different UW NetID Types (not to be confused with LoAs!)

5. What LoAs does the UW NetID Support? One size fits all… well almost! • ~ 7,400 people have 2-factor authn (SecurID) • We support a group of EAuth level 1 credentials (very small test group)

6. A Tale of Two Populations • Two populations one old one new • 200K + K-12 Students and Educators (WA State Digital Learning Commons) • 18K + UW Medicine Employees • Some Commonalities • Both need to authn • Both are critical to UW’s mission • Some Directly Competing Requirements • Stronger password requirements vs. weaker password requirements

7. A Tale of Two Populations (cont) Discussion starters: How do we support both populations and uses with the same credential? What are the advantages and disadvantages to using the same credential vs separate credentials?

8. Drivers for LoA • Compliance Perspective - Supporting federal, state and university policy requirements • Access Perspective – Providing support for our diverse populations COMPLIANCE ACCESS

9. Compliance Drivers for LoA • Regulatory – Government requirements • HIPAA • FERPA • WA State ISB Standards • WA State Security Breach Notification Law (6043) – 37 other states now have something like this • Contractual – Liability protection issues • Payment Card Industries/ Data Security Standards (PCI/DSS) • Professional and International Standards – Represent due care • E-Authentication • ISO, NIST, COBIT etc. • University Policy

10. Compliance Requirements for LoA • Password Requirements • Expiration (120 days? 90 days? 30 days?) • Lockout (3 attempts? 100K attempts?) • Strength checking (minimum char length, dictionary checking, known info checking, etc) • Protections ( Encrypted Authn, Strong Password Management ) • Authn Requirements (Multi-factor) • Logging/ Audit Requirements • Identity Proofing Requirements

11. Access Drivers for LoA • A subset of applications require a higher assurance level that’s costly to provide • A subset of apps require low bar for entrance • Globally distributed users create ID proofing challenges • Provide service to individuals with little or no known personal data • Password restrictions can be potentially unfriendly to certain classes of users

12. Access Requirements for LoA • Support requirements of each individual application (Wireless network access vs. access to PHI) • Support many different types and levels of identity proofing • Allow users to access to certain applications when less ID proofing has been done • Allow different password requirements based on what the user needs access to.

13. The Application Perspective • How can existing apps be converted to use LoA? • Why don’t you have population X in your system? • Aren’t all your credentials people? • Aren’t all your credentials highly secure? • Why can’t you make it easier for people to get IDs?

14. The User Perspective • It’s hard to choose a usable password! • Why do I have to keep changing my password? • Why do I have to give my personal information? • What do you mean I have to come show my picture id? • What do I need to do to access application ____?

15. Exploring the Solution Space • A well defined set of assurance levels • A collection of NetID and Authn characteristics are used to determine LoA • An application that allows users to view their current LoA • Clearly defined standards for what LoA each app type requires • Support for LoA in authn services (Web Signon, Kerberos, Windows AD)

16. Characteristics that Defines LoA • NetID Characteristics • Type of Identity Proofing • # of failed authns • Password age • Is Compromised? • Shared, recycled or system credentials? • Authn Time Characteristics • Type of authn (single factor password authn? 2 factor? ) • Time of authn

17. Types of Identity Proofing • High Assurance ID Proofing • Photo ID in person • Notarized Photo ID via mail/ fax • Phone verified ( 5 or more pieces of info ) • One-time password by mail • Low Assurance • Phone verified ( 2 pieces of info minimum ) • Email verified • Verified by trusted member

18. How are LoAs Assigned? • A collection of characteristics that define level of assurance • As characteristics change, LoA may increase or decrease • The assurance level may change when ID proofing is done accompanied by a password creation/ change • The assurance level may be downgraded after a maximum password age or maximum number of failed attempts has been reached • Depending on the characteristics of authn, LoA may change • An additional factor or different mechanism

19. UW NetID Levels of Assurance (Conceptual) NOTE: This does not reflect the current state of the UW NetID. The UW does not yet have plans to implement this or any other LoA scheme. • Level A – High assurance Personal IDs that authn with 2nd factor (securid for now). Compliant with EAuth Level 3 • Level B – Higher assurance Personal IDs… compliant with EAuth Level 2 • Level C – Lower assurance but meeting EAuth Level 1 standards • Level D – Low assurance personal UW NetIDs that have minimal id proofing • Level E – Shared and temporary IDs that have little or no assurance • Level F – Compromised IDs and other IDs that are not allowed to authn

20. Credential LoAs are Just the Beginning… • How do we assert the level of assurance we have that any attribute associated with the id really belongs to the specific person authenticating? • How do we address back door system accounts? • How is the user assured that the app they are assigning on is really what it says it is?

21. More Questions, Comments, Feedback? Directory Support directory-support@washington.edu Zephyr McLaughlin zephyrmc@washington.edu IDM Discussion List idm@listserv.educause.edu

22. UW NetID Types • Personal UW NetID – A UW affiliated individual’s key to online resources at the UW and beyond • Shared UW NetID – Used to share centrally maintained UW computing services such as departmental websites • Temporary UW NetID – Used to provide temporary access to services via the UW NetID system • Applications UW NetID – Applications/ services that need to authn and can’t use x509 certs • Reserved UW NetID – UW NetIDs that can’t authn (eg. root, mailing lists, etc)