1. Strong Authentication Project Update for NPTF 4/21/2008

2. Agenda Review Project –Background and Goals –Methodology Implementation Requirements Review the Options Recommendations Challenges and Risks Resources and Schedule for Development Strong Authentication

3. Background Key Concerns with Authentication Increase in password theft Increased likelihood of password cracking Mobile computing Increased demand for credentials Levels of assurance Positioning Penn for the future Strong Authentication

4. Project Goal Publish a specific set of recommendations for improvements to PennKey and for strengthening Penn web authentication to protect University assets and individuals’ private data. Strong Authentication

5. Methodology Divide Into Five Related Sub Projects: –Establish Central Authentication Log –Strengthen PennKey Passwords –Update Web Authentication Infrastructure –Supplement Re-usable Passwords –Enable Multiple Levels of Assurance Strong Authentication

6. Requirements Establish Central Authentication Log Centrally collect information about login attempts –Service Name –Access Time –Originating IP Address –Success or Failure Phase 1 – Identify participants and collect the data Phase 2 – Create and deploy tools to query the data Phase 3 – Integrate fraud monitoring software Strong Authentication

7. Requirements Strengthen PennKey Passwords Increase the minimum complexity required for Penn Key passwords Establish communications plan to inform: –End users –Application owners –Local support providers –System administrators Strong Authentication

8. Requirements Update Web Authentication Infrastructure Provide a replacement for websec that: –Addresses current security vulnerabilities –Supports web-based Kerberos authentication –Supports multiple authentication factors –Supports Kerberized single sign-on –Supports integration with Shibboleth Strong Authentication

9. Requirements Supplement Re-usable Passwords Develop a process that: –Identifies which applications must require a second authentication factor –Defines the procedures an application which provides sensitive data must follow Recommend a two-factor solution that: –Integrates with the websec replacement –Can be deployed on a per application basis –Can be replaced without recreating accounts Strong Authentication

10. Requirements Enable Multiple Levels of Assurance Position the University to support multiple levels of assurance for both authentication and I.D. proofing Outline a policy that application developers can use to identify the level of assurance required for that application Specify the technical security requirements for each level of assurance Strong Authentication

11. Options: –Real time data upload –Periodic batch upload Recommendation: –Support both real time and periodic uploads of log data –Real time will be preferred but not required Option: –Require all Level of Assurance 3 applications to contribute to the logs, regardless of their participation in central authentication? Recommendation: –Systems using common user identifiers such as Penn ID or Penn Name should be enabled but not required to contribute Strong Authentication Options and Recommendations Establish Central Authentication Logging

12. Option: –In addition to authentication data, should application usage data (i.e. SSN access) be logged in this repository as well? Recommendation: –This possibility should be enabled but not required. Application participation should be based on a project by project cost-benefit analysis. Strong Authentication Options and Recommendations Establish Central Authentication Logging

13. Options: –Increase the complexity of passwords, but allow them to remain shorter. –Transition from a password model to a passphrase model. Considerations –Passwords do not expire or lock, so they must be able to withstand a long period of brute force guessing –Password complexity increases exponentially with length, but only cubically with alphabet A 15 character password with only lowercase letters will take 23 years to break A 10 character password with 1 upper, 1 number, and 1 special character will take only 81 days to break. –Difficult to remember passwords will be written down (and stolen) or forgotten jnrUf5@&pM versus theredandtheblue Strong Authentication Options and Recommendations Strengthen PennKey Passwords

14. Recommendation: –Promote a minimum password length of 15 characters, with pass phrases encouraged The phrase may contain dictionary words, but not ascending/repeating sequences (i.e. ‘aaa’ or ‘123’) No other onerous complexity restrictions on phrases of this length, so they are easy to remember without being written down –Users desiring a shorter 10 character password can add numbers, upper case letters, and special characters to achieve a higher complexity. Challenges / Risks –Communication and coordination with support providers will be essential –It is burdensome to ask users to learn new password rules and change their passwords, so it cannot be done frequently –Some automated systems, such as those creating Guest PennKeys will have to be modified to generate legal passwords Strong Authentication Options and Recommendations Strengthen PennKey Passwords

15. Options: –Expire existing PennKey passwords when the complexity rules change –Grandfather all existing PennKey passwords until the user chooses to change them –Have a phased rollout period to encourage the community to change passwords over time Strong Authentication Options and Recommendations Strengthen PennKey Passwords

16. Recommendation: –Have a phased rollout period to encourage the community to change passwords over time as part of the Cosign authentication process For users who have not changed their password the success screen should contain links to either update their password or continue to their destination. After 4 months, the success screen would be replaced with the password change screen for these users. A link would be provided to skip this step and continue to their destination. After an additional 4 months, the link to skip the password change step would be removed. –Users changing their password should get real time validation of their choice (i.e. Microsoft Live, Google) –Passwords that aren’t changed should not expire automatically at any point Challenges / Risks –Users who do not use web applications would not be prompted to change their passwords –All PennKey holders would have to make this change, including alumni Strong Authentication Options and Recommendations Strengthen PennKey Passwords

17. Options: –Stanford WebAuth Self Service Provisioning Logout via timeout only Shibboleth Interoperability as an Identity Provider Only supports Apache, no IIS support No native support for multiple factors Single Sign On with Shared Secret –Cosign (University of Michigan) Provisioning by ISC Global logout supported Shibboleth Interoperability must be developed Supports IIS and Apache Native Multifactor Support Single Sign On with Shared Secret Strong Authentication Options and Recommendations Update Web Authentication Infrastructure

18. Recommendation: –Replace Websec with Cosign Provides very modular multi-factor support Supports both IIS and Apache web servers Supports a global logout Has an integration library for java web applications –Integrate Cosign with Shibboleth Migration costs –Service certificates require a self-provisioning interface –Depending on the technology, 1-3 hours migration time per application –Custom login pages no longer supported –SSL Costs for web servers not currently supporting SSL traffic Strong Authentication Options and Recommendations Update Web Authentication Infrastructure

19. Options: –Hardware tokens –Software tokens –Virtual two factor –Biometrics Recommendation: –Use Hardware tokens as Penn’s second authentication factor Software tokens can be compromised if the desktop/device they are running on are compromised Virtual two factor does not protect against replay attacks and commonly involve secrets easily stolen Biometric solutions are very expensive to deploy, and cannot easily be replaced if compromised –Tokens should be easy to use and carry with no input required from users –Vendor solutions should integrate with Active Directory Strong Authentication Options and Recommendations Supplement Re-usable Passwords

20. Integrate with Kerberos, always use both factors Pros: –Strengthen PennKey –No user confusion Cons: –Onerous usability demands for users –All applications behave at the same level of assurance, regardless of sensitivity Notes: –May also work with Active Directory where PennKey is used –Moderate cost to roll out and maintain, but lower cost for modifying existing infrastructure Strong Authentication Options and Recommendations Supplement Re-usable Passwords: Two Factor Architecture Options

21. Integrate with Kerberos, users are given two credentials (one with and one without 2-factor enabled) Pros: –Strengthen PennKey –Variable levels of assurance based on data sensitivity Cons: –User confusion on when to use which credential –Significant technical issues for authorization and single sign-on Notes: –Does not work with Active Directory –May require additional KDCs Strong Authentication Options and Recommendations Supplement Re-usable Passwords: Two Factor Architecture Options

22. Decouple from Kerberos, enable on a per-application basis Pros: –Variable levels of assurance based on data sensitivity –Works directly with Cosign Cons: –Doesn’t strengthen PennKey –Requires additional infrastructure to be bought –Less secure, since credentials can be attacked separately Notes: –Works with Active Directory –Applications not using Cosign or not supported natively by the vendor would require rework to use –Could be used with systems not using PennKey Strong Authentication Options and Recommendations Supplement Re-usable Passwords: Two Factor Architecture Options

23. Recommendations: –Deploy a decoupled solution today Easiest for end-users to adopt Easiest to pilot by application without impact on other applications Makes Penn a more a hardened, unattractive target –Re-evaluate with an eye towards an integrated solution in 4-5 years. MIT Kerberos may evolve to make LOA-based two-factor possible Users may be better positioned to accept two-factor for everyday use It may be necessary as phishing and password cracking becomes more sophisticated Strong Authentication Options and Recommendations Supplement Re-usable Passwords: Two Factor Architecture Options

24. Options: –Employ a 3 level of assurance hierarchy –Employ a 4 level of assurance hierarchy Recommendation: –Employ a 3 level of assurance hierarchy: Level 1 - Little or no confidence in the asserted identity's validity Level 2 - Some confidence in the asserted identity’s validity Level 3 - Highest confidence in the asserted identity’s validity –Required level will be based on risk assessment matrix of the likelihood and possible extent of harm to: University reputation University financial loss or liability University’s academic, research, or administrative functions Individual user Personal safety Strong Authentication Options and Recommendations Enable Multiple Levels of Assurance

25. Options: –Contract to a 3 rd party to perform remote ID proofing using credit report data –Identify a secret known only by both Penn and PennKey holders to use for remote ID proofing –Continue to use the slow U.S. Mail system employed today Recommendation: –3 rd party remote ID proofing services should not be employed Sensitivity of the data considered is unacceptable to the desired audience –The scope of this issue seems to fall under the purview of Bill Branan’s Streamlining PennKey initiative Strong Authentication Options and Recommendations Enable Multiple Levels of Assurance

26. Strong Authentication Really Five Projects –Establish Central Authentication Log ISC Networking and Telecommunications –Strengthen PennKey Passwords ISC Administrative Information Technologies & Communications –Update Web Authentication Infrastructure ISC Networking and Telecommunications –Implement Two Factor ISC Networking and Telecommunications –PennKey Authentication Policies ISC Administrative Information Technologies & Communications Strong Authentication Design and Development

27. ISC Information Security Organization

28. Establish Central Authentication Log –ISC Networking and Telecommunications –Begin Phase 1 in June 2008 –Estimated Completion Dates Phase 1 – February 2009 Phase 2 – June 2009 Phase 3 – October 2009 Receive log information from all non-Cosign applications by February 2010 –RADIUS Clients –Jabber –Kite –Library Web Proxy Strong Authentication Design and Development Establish Central Authentication Log

29. Strengthen PennKey Passwords –ISC Administrative Information Technology & Communications –Begin September 2008 –Dependencies: Cosign conversion Develop transition and password change web application –Estimated Timeframe and Completion Date Begin the password transition period January 2009 Password change no longer optional by September 2009 Strong Authentication Design and Development Strengthen PennKey Passwords

30. Implement Cosign –ISC Networking and Telecommunications –Begin May 2008 –Dependencies Penn Name to Penn Id conversion service (Central Authorization project) –Estimated Timeframe and Completion Date ISC Pilot by August 2008 Rollout and transition existing Websec applications to Cosign by September 2009 Password change tool to be available by January 2009 Strong Authentication Design and Development Update Web Authentication Infrastructure

31. Implement Two Factor –ISC Networking and Telecommunications –Begin July 2008 –Estimated Timeframe and Completion Date Identify Two Factor Token Vendor by May 2009 Launch a small scale pilot by August 2009 Broader pilot and ongoing rollouts to Level of Assurance 3 applications ongoing Strong Authentication Design and Development Supplement Reusable Passwords

32. PennKey Authentication Policies –ISC Administrative Information Technology & Data Administration –Begin May 2008 –Part of the Streamlining PennKey Initiative –Estimated Timeframe and Completion Date Have policies available for public comment period by August 2008 Strong Authentication Design and Development Enable Multiple Levels of Assurance

33. Strong Authentication Design and Development Preliminary High Level Timeline Identify Vendor / Trial TestingContractIntegrationISC PilotBroader Pilot Support Ongoing Rollouts … DevelopmentISC PilotRollout and Transition for all websec applications Develop InfrastructureGet Data / Develop Query ToolFraud Detection DevelopmentUser Password Change Grace Period First Draft of PoliciesPublic Comment and Review 06/0807/0808/0809/0810/0811/0812/0801/0902/0903/0904/0905/0906/0907/0908/0909/0910/0911/0912/09 Implement 2-factor Implement Cosign Central Authentication Logging Strengthen Passwords PennKey Authentication Policies

34. Questions? Strong Authentication