The Changing Landscape: External Drivers, Risks, and Rewards for Inter-boundary Authentication

1. The Changing Landscape:External Drivers, Risks, and Rewards for Inter-boundary Authentication Jack Suess 2/8/06

2. Introduction • UMBC - 12,000 students, R1 classification, more centralized than most research campuses. UMBC has been involved in I2 middleware initiative since 2000. • Myself - active in I2 early adopters since 2000. Co-Chair of Educause security task force since 2003.

3. Today’s Agenda • External drivers for IdM • Security drivers associated with IdM • eAuthentication framework as a model • Case study on how UMBC is approaching this • Challenges and rewards going forward

4. Who Are Your Constituents • Of course we have students, faculty, staff. • We also have grad students that teach, research faculty that don’t, contractors, alumni, parents, adjunct faculty, research collaborators, prospective students, non-credit students, and minors.

5. What Do Your Users Want? • Ease of use is key • Integration with campus portals • Reduced number of accounts and password pairs, moving towards one. • WebISO deployment to integrate campus portals with application authentication and enter their password just once as they seamlessly go between applications • They don’t want to change a password they finally remember!

6. What Are Your Services • Internal services • Account management - Portal, email, calendar, course management, ERP. • Library access, 1-card, door access management, payment • ERP self service for finance, hr, student • External Services • Bill payment, alumni, federal grants, inter-institutional courses, library services, etc.

7. Matching Constituents to Services? • How do you manage who is eligible to access a service? • Does every one who is eligible for services get the same level of service or have the same level of privilege. • Does ever service represent the same level of risk to the institution?

8. Compliance Issues • Regulatory compliance is pushing IdM. • HIPPA is driving secure email, encryption of records, and audit trails • SOX is driving authorization and role-based access. • Data notification on NPI is causing encryption of documents. • Calea?????

9. Integrating Security With IdM • Start with a risk assessment • Look at Educause security site, www.educause.edu/security • For each service, think of the worst-case situation. What is the likelihood of this happening? • For many services, authentication and authorization issues around passwords are critically important.

10. Text-based Password Security • Increasing being seen as insecure due to the following: • Weak encryption of password files • Availability of tools to perform automated dictionary attacks on passwords • Rainbow tables with pre-defined hash tables available for purchase www.rainbowtables.net • Passwords being sent in cleartext for some services over insecure networks.

11. Auditing - Password Requirements • As text-based passwords become less secure we see auditors increasing the requirements for password security: • Longer minimum length • Limit the time password is valid • Limit reuse of prior passwords • Require password complexity • One they often don’t look for! • No cleartext transmission of passwords to other services - such as webmail, telnet, ftp, portal, blackboard, etc.

12. Current Situation • We are continually increasing the number of web-based applications while users are demanding we lessen the passwords they have to remember. • As we move to reduced sign-on we often find auditors require restrictive policies on passwords for some applications. • The result is user frustration, increased demand for password resets, and often bad security practices as users write down their passwords to remember them. • Finding a way out …………

13. eAuthentication • Review eAuthentication documents, • http://cio.gov/eAuthentication • Identify assurance levels for your different applications and services. • Use the authentication spreadsheet to review policy choices • Look at two-factor or multi-level authentication systems for certain services • Your CD contains an OMB memo on eAuthentication that lays out the process

14. eAuthentication Approach • Much more than underlying technology. • Policy and procedures are more important than the underlying authentication technology. • Requires periodic outside review that policy and procedures are being followed. • Starts with identity proofing using a picture ID of the people you give credentials. • Requires some way of dealing with brute force guessing attacks.

15. Two Factor Authentication • Level 3 authentication requires two factors for authentication. One factor can be a text password and the other must be a non-text password (pki, biometric, secure-id, other). • Examine how your proposed WebISO supports two-factor • Shibboleth 2.0 will support two-factor. • Remember, Level 3 may only be needed by a small subset of the people to be effective.

16. Unsure how to Proceed ? • Two factor often requires new technology that can require some integration work • Implement what I call Level 2B - two text-based passwords. Establish a second text password with different password requirements from the first. • It won’t suffice for level 3 in a federated system but it might make allow you to focus stricter password requirements on a subset of the population till you can implement true two factor.

17. Federation Considerations • Federations are trust relationships. I accept your assertion that an identity is who you claim it to be. • Trust may be built upon shared beliefs, common policies, or legal contracts. • InCommon is one such federation. Other federations may be more affinity based or related to shared services. • Shibboleth is a tool for federations or multiple parties to come together.

18. UMBC Plans • Present situation • WebISO has been in place for 5 years. • 2004 we piloted a two-factor component into our WebISO called passfaces. • We have been “lurking” on eAuthentication calls with others but have not gone through a certification review. • State auditors are now focusing on password policies such as 60-day lifetime.

19. UMBC Password Risk Assessment • We identified these risks in order or concern. • Cleartext password transmission with ftp and in some email connections. • Helpdesk staff would enter new password for user on approved password change requests. • No automated process to capture brute force attack and disable account.

20. UMBC Risks (con’t) • We have not done a systematic password change for campus users in years. • Kerberos V4 has some potential exposure to offline attacks. • Certain staff with specific PeopleSoft access should be required to use two-factor.

21. Managing Risk Through Levels of Assurance • We’ve identified four levels of services, what we call level 0 through level 3 • We are mapping services to each level and looking at what we level of authentication we require. • Goals - maintain ease of use for as many people as we can. Focus new security procedures on those that require it.

22. UMBC Level 0 • Level 0 • How: text password • Who • Admitted students, alumni (via shibboleth), guests, people who had to have their password reset by helpdesk. • What can they do • Portal, email, Blackboard

23. UMBC Level 1 • Level 1 • How: Identity proofed + text password, lower password entropy • Who • Active students, staff and faculty without PeopleSoft approval access. • What • Level 0 + VPN, student and staff self service in administrative system

24. UMBC Level 2 • Level 2 • How: Identity proofed + text password, higher password entropy (Yearly password change, password history of 2, password failures will drop level of assurance) • Who • Staff and faculty with PeopleSoft approval access. • What • Level 1 + PS access.

25. UMBC Level 3 • Level 3 • How: Level 2 + two-factor • Who • IT staff, key HR and finance back office staff, ultimately all with PS approval access, campus security staff. • What • Level 2 + Specific portal channels that require high levels of authentication.

26. UMBC Implementation Plan • Eliminating cleartext password transmission by requiring encryption for all services requesting your password. • Revamp password management procedures to track failures, change date, and history. • Revamp our helpdesk password change process to use registered secondary email accounts. • Require everyone to change their password. • Select a second factor for authentication and deploy pilot service using two-factor. • Eliminate remaining Kerberos 4 services

27. Identity Proofing • Level 1 assurance requires identity verification. We issue admitted students an account without verifying a picture ID. • We will grant new students a level 0 assurance. This will give them access to the portal and email but will limit many other services till we verify a picture ID • We are revamping our ID card and access system to verify identity when they get their UMBC ID card. • A similar process will occur with new faculty and staff

28. UMBC Federation Plans • We will implement Shibboleth service and join InCommon this spring. • Three potential external drivers for Shibboleth. • Launching an external alumni portal and have contract language they must implement Shibboleth. • USM is looking at a system-wide music service for campuses. • Encouraging Sallie Mae to adopt Shib for eBilling.

29. Alumni Portal • We will integrate the external alumni portal into our campus portal. • The vendor looked at this and felt it was a very clean solution. • The challenge that we are still working our is the trust relationship from the alumni portal back to campus. We are working with our alumni development group and academic services to determine if the level of identity proofing is sufficient to grant them an unofficial transcript.

30. USM Federations • We are looking at this as a test case for a federation across the University System of Maryland campuses to validate eligibility to the music service. • Long-term we want to support shared library services using shibboleth.

31. UMBC eAuthentication Plans • The federal requirements are well thought out. Our State auditors are willing to consider using these requirements instead of their own. • We are currently focusing on documenting our procedures and creating campus guidelines and polices to meet their requirements. • We are waiting for a business reason to go through with certification.

32. UMBC Two-Factor Plans • We estimate we would ultimately have 600 users needing two factor. • Passfaces showed us the importance of user acceptance. • Our hope is to use PKI tokens as a second factor. We are evaluating the alladdin USB tokens. • We are at the very early stages of deciding how we want to do PKI and whether we will build our own CA service or buy into a commercial CA. • Much of this is driven by other goals.

33. Plans for Parents and Affiliates • Via Shibboleth from alumni portal, OR via myUMBC • Students grant delegated access by specifying email address and checking access level boxes. • Email is sent with link instructing them how to get access. Parents don’t get “account” but will get portal access. Link count for parent is incremented • LDAP attributes specify access. Parents get email whenever access rights change. • We are looking at simple services right now, mostly view access and access to bill paying • Parent loses access when link count goes to 0.

34. Role of Management • Management support is critical. Unless you have an executive sponsor behind this the politics of change will undermine it. • Recognize this project will impact many groups outside IT and build consensus early. • Expect delays, policy development is time consuming on campuses. • Build this in phases and celebrate each successful step along the way!

35. Resources • Shibboleth - shibboleth.internet2.edu • eAuthentication cio.gov/eAuthentication • InCommon incommonfederation.org • Security www.educause.edu/security Questions? Contact: jack@umbc.edu