MAIS Home

Projects

Two-Factor Authentication in M-Pathways

Two-Factor Roadmap

Roadmap for Two-Factor Authentication at U-M

Michigan Administrative Information Services
September 29, 2005
(Draft #005)

Purpose

This document is intended to provide a high-level overview of the Two-Factor Authentication Project and the Two-Factor Authentication architecture that will be used.

This document is not intended to provide a detailed description of the technical architecture. A detailed technical architecture will be created later as one of the project deliverables.

Background

Today, virtually every University system is based on reusable passwords. Each user establishes a password with a system and can then re-use it over and over again. Although this type of authentication is easy to deploy and use, it unfortunately is susceptible to a wide range of security exploits. A computer system which is otherwise secured with sophisticated technologies, such as firewalls, intrusion detection software and integrity management software, can be easily compromised through the misuse of reusable passwords.

In June 2005, the Executive Officers at the University of Michigan approved a Two-Factor Authentication Project to help address the risks associated with reusable passwords. The approved project called for the deployment of a strong authentication mechanism for University administrative systems. The project also called for the establishment of an underlying strong authentication architecture that could eventually be used by a wide variety of University systems for which strong authentication is appropriate.

Implementation Strategy

A vision for logical and physical access at the University is defined in the document titled "A Roadmap for Consolidated Logical and Physical Access at the University of Michigan." This vision calls for the use of the Mcard as a device to store and access two-factor authentication credentials.

Ideally, the initial two-factor authentication deployment would be based solely on the use of the Mcard for authentication. Unfortunately several barriers make this untenable. These include:

• It will take several years for smart chips on Mcards to be deployed across campus.
• It will take several years for card-reader technology to become ubiquitous on campus workstations. Deployment of card readers to campus at this time would be expensive and would introduce significant platform compatibility and support issues.
• It will take several years for Public Key Infrastructure (PKI) to be widely used on campus.
• Trying to tackle all of these major initiatives as one large project is extremely difficult and would put all the efforts at risk.

Therefore, MAIS has adopted a phased approach for two-factor authentication:

• Phase I: Implement physical tokens for authentication.
• Phase II: Add integration to PKI on the physical tokens.
• Phase III: Transition to the Mcard.

Architectural decisions will be made with subsequent phases in mind to assure the smoothest transition possible. We believe this approach allows the University to gain the benefits of two-factor authentication now, and it provides a clear path to achieve the long-term vision.

The current plan and funding cover only the first phase. The exact scope and cost of the additional phases will be known near the end of Phase I. If additional funding is necessary, a business case will be developed at the end of Phase I.

Phase I: Overview

The first phase of the project will last between 12 and 24 months, and it will address the following significant tasks:

Architecture Selection & Implementation

Technical team members will select a vendor-provided and University-hosted two-factor authentication architecture. The selection will occur through the standard University Request for Proposal (RFP) process. Selection will occur in the fall of 2005, and deployment will occur in the first half of 2006. MAIS and ITCS staff will work cooperatively to assure that deployment will include the integration of Cosign with the selected product. Deployment will also include the creation of ongoing production support documentation, procedures, and support technologies (e.g. monitoring).

Process Redesign

MAIS Access Services will design and implement new access procedures for the distribution, revocation, and maintenance of physical tokens. The processes will support both the use of two-factor authentication for MAIS systems and the eventual use of two-factor by non-MAIS systems. Process redesign may include integration with other University offices such as the ITCS Accounts Office.

Communication and Support

MAIS User Services, MAIS CPUs, and the eResearch Team will develop communication plans, documentation, and production support plans for two-factor authentication. They will assist with the deployment in key units and establish the roll-out schedule.

Roll-Out

The high-level plan calls for a gradual deployment of tokens on a unit-by-unit basis. MAIS CPUs and the eResearch Team will work with units to determine the exact roll-out schedule. Roll-out will begin in the first half of 2006, and continue for 12 to 18 months. We anticipate between 5,000 and 10,000 tokens being distributed.

Long-Term Planning

Develop a plan for long-term integration with departmental systems, door access system, Mcard, and Public Key Infrastructure. Implementation of this plan will follow in Phase II and Phase III of the project.

Phase I: Scope

In addition to the tasks listed above, the scope of the first phase of the project will include the following:

Users

The exact users that will receive tokens and use two-factor authentication have not been specifically determined, but the team has formulated some basic assumptions to define the final set of users:

• Between 5,000 and 10, 0000 tokens will be distributed in Phase I. The final number will depend on cost and implementation strategy.
• Tokens will only be distributed to faculty, staff, and contractors. Students and alumni will not receive tokens unless they are also temporary or permanent staff members with access to University administrative systems.
• Users that only use self-service transactions (e.g. open enrollment, viewing pay stub), will not receive tokens.
• Faculty members whose only non-self-service usage is Web grades entry will be eligible to receive two-factor authentication.

Systems

The table below describes the plans for integration of two-factor authentication with various University systems:

Note: Technical barriers may make it impossible or impractical to integrate two-factor authentication with one or more of these systems. If that's the case, the project scope will be altered by the project steering committee.

No unit or departmental systems are included in the scope of Phase I. We recognize the importance of adding these systems in later phases, and as part of Phase I, we will design the technical architecture and the appropriate processes and procedures to support these types of systems, but deployment will wait until Phase II.

Phase I: Mandatory vs. Optional Use of Two-Factor

While the project team believes the mandatory use of two-factor by all users of University administrative systems would be an appropriate security policy, we will not actively pursue that policy as part of this project. Instead we will attempt to deploy two-factor as widely as we can within the scope listed above. We may not reach 100% usage, but every reusable password removed from the infrastructure will improve the overall security of the system. If we are successful within this framework, then in the future, University Executive Officers may want to reconsider and make two-factor mandatory.

Deployment of two-factor authentication will occur on a unit-by-unit basis. Some units may choose to be early adopters, while other units may choose to delay deployment for a year or more. Some units may choose to make two-factor authentication mandatory for the members of their unit, while others may choose to allow members of their unit to opt out of the use of two-factor.

If a unit, or an individual chooses to opt-out of two-factor authentication, MAIS may want to have them sign a form indicating that they understand the risk they are introducing to the University and their willingness to take proper measures to protect their reusable passwords.

Phase I: Two-Factor Tokens

Phase I will include the deployment of physical tokens to end-users. These tokens will be about the size of a standard door key, and will likely have four important characteristics:

• Tokens will have a liquid crystal display that can display a six- to eight-character pass code.
• Tokens will have a Universal Service Bus (USB) adapter which allows them to be plugged into computers.
• Tokens will contain processing technology (e.g. Java) which will allow them to perform various operations including the storage and processing of digital keys.
• Tokens will be branded with a custom logo unique to the University of Michigan.

Although these tokens will have a wide range of capabilities, initially the Two-Factor Authentication Project will only leverage the liquid crystal display for authentication. The USB Port and digital key capabilities will not be leveraged until later phases of the project. It is important though to deploy tokens that support these capabilities to make future transition smooth and efficient.

Phase I: Cosign Integration

Cosign is established on campus as the de facto authentication standard for Web applications. Its ubiquity at the University makes it a perfect platform on which to build much of the two-factor authentication architecture.

The final design of how Cosign and two-factor will be integrated will occur early during the Two-Factor Authentication Project. Some preliminary conversations have already occurred between ITCS and MAIS, and some of the following design characteristics are being considered:

• The Cosign login screen will be updated to allow a user to enter both his/her Kerberos password (UMich password) and his/her automatically generated two-factor authentication password. The following screen shot provides an idea of how this might work:
  Note: The final screen design has not been determined and will likely be different than the one below.
  
  
  
• A database will be included as part of the architecture to track which users have two-factor tokens, and which do not. The database will contain the necessary information to support the temporary disabling of two-factor for any particular user (for example, in the case that a user leaves his/her card at home).
  Note: The architecture will also support the use of local departmental databases on an application-by-application (or host-by-host) basis. So if unit wishes to manage two-factor authentication for their systems in some unique fashion, the technology will support it.
• The Cosign architecture will be designed in such a way that each application can choose to use or ignore the two-factor authentication token as it sees fit. For example, some applications may require two-factor for any user that has been given a token (e.g. M-Pathways); other applications will only require one factor (the Umich password) and will ignore the fact that the user successfully used a second factor for authentication (e.g. campus e-mail).
  Note: There should never be a situation where user that successfully log in using two factors are then denied access until they re-authenticate with only one factor.

Phase I: Integration With Non-Web Applications

Most University systems today are Web-based and use Cosign for authentication. Unfortunately some products are not Web-based, or are not yet integrated with Cosign. Because these systems don't integrate with Cosign, integration with two-factor authentication will be more difficult. The following list itemizes groups of products that will require special integration with two-factor authentication, and it describes how they will be handled during the project:

• Group 1: In scope for Phase I
  Products: BusinessObjects, SSH/SFTP for MAIS UNIX systems, DAC on MAIS Mainframe
  All of these systems are non-Web-based and will require special configuration and setup for them to work with two-factor authentication. These products are in scope for the first phase, so an integration approach will be researched. If technical barriers arise, some or all of these might fall out of scope.
• Group 2: Out of scope for Phase I
  Products:
  -- Departmental tools (e.g. Microsoft Exchange, Novell Groupwise)
  -- Enterprise 3rd Party Tools (e.g. Vista Plus, Dazel, CA Unicenter, Oracle).
  Eventually, it will make sense to allow two-factor for many of these types of systems, but due to cost and logistical issues, these types of products are out of scope for Phase I. When we define and fund future phases, we can consider adding them to scope.

Phase I: The User Experience

The following scenario illustrates how two-factor authentication might affect the day-to-day life of a staff member at the University.

Jane Smith is hired into the University. Her department requests access to various University systems such as M-Pathways. Jane is granted access to these systems and receives a University security token.

In doing her job, Jane regularly uses Web-based systems that are based on Cosign. Whenever she uses these systems, she enters both her Umich password and her University security token value. The University security token value is the automatically generated password which can be read on the front of her University security token.

Conveniently, Cosign is a single-signon environment, so as long as Jane doesn't exit the browser, and as long she actively maintains a session, she will not have to re-login.

Jane doesn't need to understand that some of the Web systems require that she use her University security token, and that others don't. She just logs in the same way with Cosign every day, and the systems are available to her.

One day, Jane leaves her University security token at home, and there is no practical way for her to retrieve it that day. Jane connects to a Web application that is provided MAIS, and is given a temporary method to login to systems even though she doesn't have token.

If one day, Jane accidentally logs in only with her Umich password, instead of also entering the value from her University security token, she will still be able to use many University systems, but if she tries to use a system that requires two-factor (for example M-Pathways), she will receive an error message, and will be asked to log in again using her University security token.

The main points of this illustration are:

• Cosign looks and behaves the same for all whether they just use their Umich password or they also use their University security token for authentication.
• Users that always log in with both their Umich password and the University security token don't need to know which systems require two-factor authentication.
• The system is flexible enough to allow for lost or stolen tokens. A person can be granted access quickly when these situations arise. (We may want to establish policies to limit how often a person takes advantage of this feature, but that will be determined during the project.)
• Users that do not log in with their University security token will be prevented from using some University services.

Phase II: Leveraging Public Key Infrastructure

A Public Key Infrastructure (PKI) enables users of a basically insecure public network such as the Internet to exchange data securely and privately through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority. Despite a slow adoption rate in the past, it appears now that PKI is poised to be accepted by many universities in the next several years.

Two-factor authentication tokens can provide a perfect deployment platform to support PKI. An important part of PKI is the distribution and use of "private keys." Private keys are digital credentials that a user can use to authenticate to a system or encrypt and decrypt data. One of the challenges of PKI is the distribution and management of private keys. With two-factor authentication in place, the deployment could be greatly simplified. A user's private key could be stored on their two-factor authentication token, and accessed by simply connecting it to the user's computer through a USB port.

Phase II: The User Experience

Most users will only see marginal changes in the user interface when PKI and two-factor authentication are integrated. The biggest two changes they will see are:

• Instead of entering an automatically generated password that is read from the security token, usersr may instead plug their token directly into a computer. They will still have to enter their Umich password, but they will no longer have to type a second code. (If their token is not plugged into the computer, users can continue to use the automatically generated password as they did during Phase I.)
• If users unplug their token after successfully authenticating, they will not be able to use the applications until they plug the token back in. (This is a nice feature which will essentially allow users to "lock" their workstation when they leave to perform an errand in another location.)

Phase II: Cosign Integration

During Phase II, Cosign will need to be enhanced to recognize keys that are stored on the physical token. The user interface will only change slightly. Cosign will need to address two main scenarios:

Scenario 1: Users who have not plugged in their token wiil see the standard Cosign screen, shown above.

Scenario 2: Users who have plugged in their token wiil see a slightly modified screen so they will know that the token has been recognized, and that they only has to enter thei Umich password.

The following illustration provides an idea of how this screen might look:
Note: The final design of the screen has not been determined and will likely be different than the one below.

Phase II: Integration with Departmental Systems

Whether the University implements PKI or not, the two-factor authentication infrastructure can be extended beyond central systems to support systems run by any unit in the University.

Integration will be easiest for Web applications that can use Cosign, because few technical hurdles will exist. Some programming may be necessary to allow the Cosign software to recognize department specific data, but the effort should be very small.

Integration with nonCosign-enabled applications will be more difficult. Vendor Application Programming Interfaces (APIs) or authentication modules may need to be leveraged to support two-factor authentication. The unit will probably have to work with MAIS technical staff and/or the two-factor authentication vendor to implement the necessary changes.

In addition to technical hurdles, some procedural hurdles will need to be cleared to enable two-factor authentication on a departmental system. For example, some members of the department may not yet have a token, so distribution could be a challenge. We hope to address these issues in Phase I of the project, so that clear and understandable policies and procedures exist for any interested units.

Phase III: Leveraging Mcard

Costs and logistics will likely prevent every member of the University from receiving a two-factor security token. Therefore to achieve all the benefits of two-factor authentication and PKI, the University will eventually need to transition to a more ubiquitous device. Ideally, that device would be the University's Mcard.

If in the future a smart chip is available on the Mcard, then the chip could be used to hold two-factor and PKI information, and the physical two-factor tokens could be phased out. In addition, if door access technology was incorporated on the Mcard, the Mcard would become a single device that would control both physical and computer access for members of the University.

The successful implementation of this technical direction requires that University desktop computers eventually include card reader technology. This could be accomplished through built-in card readers (available from vendors) or from devices that could sit beside the computer.

The exact strategy for deploying readers should be part of the planning for Phase III. In anticipation of these changes, some units may immediately want to use capital replacement cycles to start acquiring machines with card reader technology. That way as these integrated technologies are released, their units will be positioned to leverage them.

Phase III: The User Experience

When two-factor authentication begins to use the Mcard, end-users will experience very few differences from Phase II of this project, except that the physical device used to connect to the computer will be different. Instead of plugging into a USB port, users will insert their Mcard into a card reader that is capable of reading the smart chip.

If a card reader is unavailable for, or incompatible with, a computer, then users can be provided with a small portable device to allow them to generate an automatic password much like the token did. This type of technology would help during transition, and also help if users must use computers which do not have card reader technology (e.g. at home, or at a nonU-M site).

The use of the Mcard will enable the University to leverage two-factor authentication and PKI for a much wider audience than before. Every person with an Mcard could eventually use two-factor authentication and PKI with their various software systems.

Conclusion

Two-factor authentication is an important step forward for the University's security architecture. As the project moves forward, it is important that architectural decisions be made based not only on short-term needs, but on the long-term direction of the University. The evolution of authentication from token, to token with PKI, to smartcard is logical progress for authentication on campus. The Two-Factor Authentication Project team will work to assure that all of its work aligns with this long-term vision.

Next section: Roadmap for Consolidated Logical and Physical Access at U-M