Attribute Delivery - Level of Assurance

1. Attribute Delivery - Level of Assurance Jack Suess, VP of IT Jack@umbc.edu

2. Presentation Focus • NIST 800-63 and eAuth framework • Importance of identity proofing • Authentication • Application Authorization • Levels of Assurance • Linking this to Shibboleth

3. eAuthentication • NIST 800-63 Electronic Authentication Guidance provides good background on the topics we will discuss. • www.cio.gov/eauthenticationprovides a great set of resources for planning and implementing levels of assurance

4. Federal eAuth Site

5. Identity Proofing • How do you know jack@umbc.edu is associated with Jack Suess? In fact, Jack Suess does not exist in our database because my official name is John Joseph Suess.

6. Who is Jack Suess? • Jack Suess a.k.a. John J. Suess III • Title CIO and VP of IT • Username jack • Campus Id DS 50004 • PS EMPL ID 1000001846 • HP ID 950123850

7. Identity Proofing • How do we assure the ID’s associated with Jack Suess were assigned to the right person? • 3rd Parties - State MVA (drivers license) • Passport - US Gov’t • Notary Public? • Trusted 3rd party? • Campus Picture ID card ??

8. Self Service Accounts • How do you support self-service account generation for people and do Identity Proofing? • Key is treat unverified accounts as untrusted. In our setup we consider these to have a Level of Assurance (LOA) of 1. • We use the process of getting a campus ID to verify our credentials. From then on people can use applications that require higher LOA.

9. Dealing with Exceptions • No process is perfect, there is always an exception - (e.g online students, off-campus researchers, etc.) • For exceptions, we are willing to allow a trusted intermediary to assert they have done the identity proofing. Usually these are people responsible for paying researchers or registering students. • It is important to document the procedures that must be used in each case.

10. Providing Service • Tightly integrated IDMS with Campus ID card • Empowering people to know what ID’s are assigned to them helps to find errors. • Delegating administrative rights to people to lookup others may be necessary to move away from SSN • Example through myUMBC

11. Authentication • The goal is to establish confidence in a user identity • Authentication protocol provides a well specified exchange that verifies possession of a token with the associated claimant.

12. UMBC Authentication • We have tightly integrated Kerberos, LDAP, and our central AD. People have one username and one password across all central services. • Our WebSSO is locally developed (2000) and has similarities to CAS in that it was designed with the idea of being able to release specific attributes based on the service request (e.g. affiliation). • Plans are to migrate this over to Shibboleth

13. Authentication - Passwords • We now enforce a set of rules including last password change, password makeup, password history, and failed logins. • Our initial goal was to replace archaic audit requirement to change passwords every 30 days with a more robust approach • See http://www.umbc.edu/oit/sans/security/policy.html

14. Password Resets • Presently the helpdesk can reset a user password. Our plans are to move to a system where this won’t be allowed and no one other than the user will be able to create/reset their password. • We are tracking discussions among the eAuth leaders on the best process to do this.

15. Secondary Authentication • Our WebISO provides hooks for enforcing a secondary authentication. We can make this a second text-based password or use some non-text mechanism. • Presently we have not felt the effort to implement something else was worth the cost.

16. Application Authorization • Portals and single sign-on have moved campuses to treat all web applications as having the same level of security. • Today, if an application requires special authentication we often do application-specific solutions. • Ideally, we would like to use the portal to launch applications but have applications that need additional security use a common framework, not application specific methods.

17. Level of Assurance • Level of Assurance (LOA) is a method for classifying the security requirements of an application. • NIST has defined levels 1 through 4 for federal agencies. • Financial institutions may use level 2

18. Federal LOA • NIST 800-63 has details • LOA 3 and 4 are intended for highly secure applications. • LOA 3 and 4 use PKI and/or biometric • Level 3 may use soft token and password • LOA 2 through 4 require identity proofing with gov’t ID and record retention

19. Levels 1 and 2 • Level 1 does not require formal identity proofing • Level 1 may reveal the password to the service, passwords may be subject to offline replay attacks, and strength is less than for level 2 • Level 2 requires identity proofing and a minimum level of entropy on passwords. • Level 2 makes sense for ERP applications.

20. Campus LOA • Campus focus will be on level 1 through 3. • Level 1 and level 2 will be similar but with Level 1 the claimant has not been identity proofed. • Level 2 is used for online education and administrative applications. • Level 3 may be used by system admins, power users in your ERP, or for special applications needing higher security.

21. LOA and Shibboleth • Adopting a standard agreement on LOA allows groups to move away from bilateral agreements and accept security assertions based on a common definition of LOA. • This requires institutions to agree to implement LOA for individuals on their campus. • The federal eAuthentication guidelines are a good starting point.

22. Focus on Privacy Protection • All that we do with LOA and Shibboleth ought to be focused on protecting an individuals privacy. • I’d like to see UMBC be much more open and expand what we provide to people so they can better understand what we are doing with their private information.

23. Planning for the Future • Institutions should assume that they need to review or establish password policies and implement identity proofing. • Institutions should begin to categorize applications by LOA. Work with auditors to define appropriate LOA for campus applications. • Institutions should focus on developing processes, policies and procedures to ensure privacy and minimal release.