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 COMPLIANCEACCESS

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 2 nd 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.edudirectory-support@washington.edu Zephyr McLaughlin zephyrmc@washington.eduzephyrmc@washington.edu IDM Discussion List idm@listserv.educause.eduidm@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)