IAM Online Multifactor Authentication in Higher Education Tuesday, December 6, 2011 3 p.m. ET Steven Burke, Federal Student Aid, US Dept. of Education Shilen Patel, Senior IT Analyst, Duke University Miguel Soldi, Information Security Policy and Resourcing Analyst, University of Texas System Rodney Petersen, EDUCAUSE IAM Online is brought to you by InCommon, in cooperation with Internet2 and! the EDUCAUSE Identity and Access Management Working Group 1
Two-Factor Authentication An EDUCAUSE Information Security Guide Resource Miguel Soldi, HEISC Governance, Risk, and Compliance Working Group 2
Why a Resource About Two-Factor Authentication? Two-factor authentication has been around for a good while Most people are familiar with it.though some may not know it. But, we have come to realized that Staff and faculty, in their official capacity, have access to systems and databases with an increasing amount of confidential information, Confidential information highly desirable and actively sought by the curious and the criminal, Passwords safeguarding information can frequently be easily guessed or compromised through phishing or hacking, and The increased use of single sign on has also increased the value and risks of those passwords Source: http://www.ehow.com/info_8663662_onefactor-vs-twofactor-authentication.html 3
Why a Resource About Two-Factor Authentication? Two-factor authentication has been around for a good while Most people are familiar with it.though some may not know it. But, we have come to realized that it makes good business sense to consider two-factor authentication as an alternative to the use of userid / passwords by themselves, and compliance requirements are increasingly motivating us to come to that realization a bit quicker. Source: http://www.ehow.com/info_8663662_onefactor-vs-twofactor-authentication.html 4
A Word About the Resource. High-level overview document that touches on the business reasons for using an additional factor, characteristics of available technology, and a discussion of biometrics. It is intended as a starting point for those who are just starting to think about it and a springboard to further explore alternatives, characteristics, and risks. It is not a roadmap for implementation or an endorsement for any particular technology. It not perfect either. Feedback, comments, and other input are welcomed and appreciated. 5
Two-Factor Authentication Resource Next Steps Common Barriers to Implementation of Two-Factor Authentication No explicit federal or state requirement. Who owns the process? Who pays for it? What about decentralized IT? False sense of security. Have not had a breach so we must be doing things right. Trying to do too much at once. Cost and difficulty to demonstrate/articulate benefit. IT and IT help desk may not want to support it. Inconvenience. One more thing to carry and worry about. Privacy concerns regarding biometrics in particular 6
Two-Factor Authentication Resource Next Steps How Can I Approach Implementing Two-Factor Authentication? What do we need and why? Is there a specific compliance requirement? Is it only for physical access to buildings and data centers, access to data, or both? Do we need to target specific users, applications, locations, all of the above? What mix of technology and deployment architectures is needed / desired? What can we afford? What is the incremental benefit of one technology over another? Full vs Incremental implementation. What can we sustain? Integrated solution covering all requirements? Manageable help desk workload to handle user questions, training, lost devices, renewals, revocations, etc? Will users accept and utilize our solution? 7
Contact Information We appreciate your feedback and comments. Email: msoldi@utsystem.edu THANK YOU! 8
Multifactor AuthN Shilen Patel, Duke University 9
Multimode Multifactor Authentication Traditional single- mode multifactor authentication is a non- starter. Authmech = f(organization) Authmech = f(app,user) (or even f(app,user,location)) f() = Max(user(app),app(user),institution(app,user)) Prof W. can self- select a higher bar for his logins to his blog, while we can raise the bar for logins to grant mgt. 10
Low- hanging fruit strategy Start with the IDP 700+ on- campus SPs and growing already If we re careful, most SPs won t need to do anything and their users won t notice anything Infrastructure behind the IDP can be reused New apps are largely web- based; older apps continue to grow better web interfaces 11
New IDP external authmech Pluggable interface for custom credential verifiers Recognizes different strength values for different credential types Computes required strength based on claimed identity and SP making request. Auth Svc Auth Svc Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech IDP Login Page (jsp) Rules Prefs 12
New IDP external authmech IDP Login Extensions ajaxy and context sensitive Auth Svc Auth Svc authn options depend on user capabilities and preferences constrained feedback to defeat incremental attacks Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech IDP Login Page (jsp) Rules Prefs 13
New IDP external authmech Data repositories for rules and preferences Auth Svc Auth Svc IDP stores mech strength rules locally LDAP stores user, SP specific data Considering Grouper as replacement for one or both to enhance generality Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech IDP Login Page (jsp) Rules Prefs 14
Single sign- on SSO becomes an issue across disparate SPs Built- in previous session handler doesn t understand strength Auth Svc Auth Svc Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech SSO Handler IDP Login Page (jsp) Rules Prefs We disable it and supply SSO in the external authmech itself SP1 SP2 15
Single sign- on Record authn strength factor (sum) in login context (auth method) SSO implements >= semantics - - SSO succeeds iff previous session method strength >= current requirement Auth Svc Auth Svc Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech SSO Handler IDP Login Page (jsp) Rules Prefs On SSO failure, require all new creds from user SP1 SP2 16
Novel Use Cases Sometimes a password may not be required (WS) If no one specifies anything, UI can look just like before If an SP explicitly lowers its expectations, new options arise Default numeric strength requirement = 1 (equiv to password only ) Allow OpenID gateway as option for SPs requiring strength < 1 17
Other Considerations User requires a higher strength value for an SP, but forgets his second factor when going to a conference. Strength requirement for self service tool. Other authentication mechanisms. 18
19
20
21
22
23
24
25
Contact Information We appreciate your feedback and comments. Email: shilen@duke.edu 26
Two-Factor Authentication Steven Burke, Federal Student Aid, US Department of Education 27
Project Overview To comply with the White House through the United States Office of Management and Budget (OMB) mandate, Memorandum M07-16 attachment 1, and as part of our ongoing efforts to ensure the security of Federal Student Aid data systems, the U.S. Department of Education, is required to implement a security protocol through which all authorized users will enter two forms of authentication to access Federal Student Aid systems via the Internet. This process is referred to as Two-Factor Authentication (TFA). 28
Keyloggers Keyloggers, Malicious Threats What is it and how does it exploit a Web Application? What can be captured? Why is it desirable? 29
What is Two-Factor Authentication? Two Factor Authentication is a process which requires each authorized user to log into FSA systems with two types of information: Something that you know is the First Factor: User ID and Password Something that you have is the Second Factor: Token with a One Time Password The One Time Password (OTP) will be generated by a small electronic device known as the TFA Token that is in the physical possession of the user To generate the OTP, a user will press the power button on the front of the token. A different OTP will be generated each time the button is pressed. Alternative Methods of obtaining OTP without TFA Token: A) Answer 5 Challenge Questions online B) Have the OTP sent to your Smart Phone 30
How do I register my token? Once you receive your token you must register it for each system for which you have access to and utilize Each FSA System Web site will be slightly different when logging in and registering your token Next Steps: Click on the following link. https://fafsa.ed.gov/fotwwebapp/faa/faa.jsp Then click on the Register/ Maintain token URL on the top right hand side of the screen. 31
TFA Profile Information Step One Enter general identifying profile information If you ever forget your assigned password or misplace your token, you may choose to complete the cell phone information to receive this information via text message 32
TFA Register Token Serial Number Step Two Enter the Token Serial Number located on the back of the token The credential will begin with three letters and nine numbers (i.e. AVT800000000) 33
TFA Challenge Questions > Step Three Complete five separate questions and responses You may not repeat questions nor may any question have the same response 34
TFA Terms of service Step Three continued You must read the Terms of service before checking the acknowledgment statement and proceeding 35
TFA Security Code You will then be directed to the security code entry screen You must enter two consecutive security codes successfully Please note: a new code is generated once every 30 seconds and will require you to click the On Button in between attempts 36
TFA Registration Complete Registration Completion When successful you will receive confirmation and your security token will now be ready for use 37
TFA Login Process Once your token is registered you must log in using both factors of authen6ca6on: Factor one Assigned User ID and Password Factor two One- Time generated Password (OTP) 38
Token Registration Process CPS & NSLDS.. 39
Token Registration Process COD.. 40
Token Registration Process EDconnect/SAIG & SAIG.. 41
Primary Systems Impacted Across the Enterprise CPS FAA Web Access 4/20/2011 (Central Processing System) COD 10/23/2011 (Common Origination and Disbursement System) NSLDS move Behind AIMS 12/18/2011 (National Student Loan Data System) Participation Management 2/12/2012 SAIG/ EDconnect 2/12/2012 (Student Aid Internet Gateway) Ombudsman 2/12/2012 42
Token Deployment Schedule 2011-2012 Group Implementation Scope Group 1 Q4 2011 DE, MD, VA, WV Group 2 Q1 2012 NC, NJ, NY, SC Group 3 Q2 2012 KY, MI, NE, NH, OH, PA, RI, VT Group 4 Q2 2012 CA, FL Group 5 Q3 2012 AK, ID, MN, ND, OK, OR, SD Group 6 Q3 2012 AR, CO, GA, KS, MO, MS Group 7 Q3 2012 AZ, CT, IA, IL, IN, LA, TX Group 8 Q4 2012 AL, AS, FC, FM, GU, HI, MA, ME, MH, TN Group 9 Q4 2012 MT, NM, NV, PR, PW, UT, WA, WI, WY 43
TFA Token Deployment Status q Phase 1 FSA Citrix users 1,300 completed 5/1/2011 q Phase 2 Dept. of ED Staff 5,200 completed 7/1/2011 q FSA Contractors completed 10/28/11 q Phase 3 International users at Foreign Schools q Group 0 Foreign Schools q 650 confirmed users 11/28/2011 q Group 0 DeVry University q 820 confirmed users 11/28/2011 q Group 1 DC, DE, MD, VA, WV q 2,622 estimated users q Complete attestation and ship tokens by 12/31/2011 q Groups 2-9 11/16/2012 44
Two Factor Authentication Next Steps Action Items and Next Steps (Internal) Contractor /Vendor attestation of Developers, Testers and Call Center Representatives (CSRs) FSA Project Team to provide information on confirmation processes, TFA training and tokens Contractor /Vendor are to register tokens FSA to TFA Enable Systems Action Items and Next Steps (External) Primary Destination Point Administrator (PDPA) and COD Security Administrators (CSA) attestation of (FAA, Servicers and Guaranty Agencies, etc.) associated with their account and who are working on behalf of their institution FSA Project Team to provide information on confirmation processes, TFA training and tokens Institutions are to register tokens 45
Contact Information We appreciate your feedback & comments. Phone: 202-377-4683 (Steven Burke) E-mail: TFA_Communications@ed.gov 46
Evaluation Please complete the evaluation of today s IAM Online. www.surveymonkey.com/s/iamonline_oct_2011 IAM Online Announcement List Email sympa@incommon.org with the subject: subscribe iamonline Thank you to InCommon Affiliates for helping to make IAM Online possible. Brought to you by InCommon, in cooperation with Internet2 and the EDUCAUSE Identity and Access Management Working Group 47