CITES Authentication Roadmap: Reduction of Passwords Whitepaper (Draft)

The following whitepaper describes the steps CITES must take to reduce the number of passwords that the campus community needs to access CITES services to a single password. The whitepaper also explains how CITES intends to provide authentication services based on the single CITES-managed password.

• Introduction
• 1. Establish a single CITES-managed strong password
• 2. Provide a flexible set of methods for services and applications to leverage this password for authentication
  • WebISO
  • Kerberos
  • LDAP
  • Active Directory
• 3. Reduce the number of times this password needs to be entered by the user (single sign-on)
• Limitations of passwords for identity assurance
  

Introduction

The first strategic direction identified in the CITES Authentication Roadmap is to "reduce the number of passwords":

"Establish a single strong password for each user, and provide flexible yet secure methods for services and applications to leverage this password while maintaining its integrity. Additionally, the number of times when a user needs to enter this password during a particular work session should be minimized, moving towards single sign-on for many services or where possible. This should be achievable over the next 18 months."

That implies three clear goals:

1. Establish a single CITES-managed strong password for each user.
2. Provide a flexible set of methods for services and applications to leverage this password for authentication.
3. Reduce the number of times this password needs to be entered by the user while in a particular work session at the computer, where possible and appropriate. (This is generally referred to as single sign-on.)

This paper will cover why CITES believes these goals are important, the path and implications to achieving the goals, and some of the steps and deliverables along the way. Note that only CITES-managed passwords are specifically addressed; users may have additional passwords managed by other units within the University. A primary goal in offering a flexible set of authentication methods is to maximize the usefulness of the CITES-managed password to campus, thus helping to minimize the need for other passwords. Additionally, inter-campus efforts are beginning to explore how to better align authentication services and passwords across the University in the future.

1. Establish a single CITES-managed strong password

One could subtitle this section as "Why reduce passwords?" The short answer to this question is summed up by CITES' stated goal for an authentication service-- to be customer friendly while maintaining sufficient security, privacy, and auditability. We believe the appropriate balance between usability and security can be obtained through a single CITES-managed strong password for each user.

Over the last several years, password management for users has become more difficult:

• password construction rules (strength-checking) became more stringent for certain passwords.
• forced password expiration (once a year) was introduced for certain passwords.
• more services deployed by CITES with separate passwords (e.g. Express Email, NetFiles/Campus Windows Active Directory (AD) domain, Oracle Calendar), in addition to the NetID password and Instructional Computing Services (ICS) password.
• introduction of an enterprise password (known as Enterprise Application Service, or EAS) for authentication with Banner and other university administrative applications.

Thus password management has become more complex for users, and "complexity is the enemy of security" (a quote from Bruce Schneier, a well-known security technologist). Is this complexity justified today; is there sufficient gain in security for the cost to users (and to the user support personnel around the campus) to manage disparate strong passwords? We want to aim for the "sweet spot" between maximum security and cost.

There is additional risk to having one password rather than several, because if that one password is compromised, the "password thief" has access to every service protected by that password. But there is also additional risk with users who are confused and don't manage multiple passwords well (for example, those who write down their passwords on sticky notes or store them in unprotected files). With a single password, user support staff can focus on enhanced user education of the importance of the password and how to manage it well, rather than spending their time helping users sort through the confusion of many passwords. The bottom line is that the gain in going to a single well-managed strong password outweighs the cost.

The question then becomes, how do we move to a single strong password? The first step will be password synchronization between the different password stores behind the various services. To be effective, that will entail:

• identifying the authorized password services/stores, ensuring that they are configured to accept/transmit passwords only across well-encrypted protocols and to store the password with strong encryption
• removing or disabling any service-specific way of changing the password, so that
• all password setting occurs within a common service (e.g., Password Home Page today)
• the common password setting service pushes the new password to all authorized password services/stores (those that meet similar security guidelines as far as the use of encrypted protocols and password storage).

We expect this to include the MIT Kerberos KDC (NetID password), NetFiles/Campus Windows AD domain, Express Email, Oracle Calendar, and ICS passwords. And note that there have also been discussions across the University, and general agreement, that establishing synchronization between the campus strong password and the enterprise strong password (known as the EnterpriseID password or EAS) would also be a good idea, following the same line of argument above concerning cost and user confusion versus risk aggregation.

Ultimately, a further step to a single password is reducing the number of password stores (different authentication services) over time, as both opportunity and resources allow. Note that with forced password changes once a year, a password synchronization deployment will within one year bring all the authorized stores into complete alignment. Once that has happened, then if all services using a particular password store can be switched to using a different one, that store can be retired without end-user impact (because their password will be the same in the alternate store). Reducing the number of password stores will save costs from the operation of those stores, and further simplify our authentication landscape.

2. Provide a flexible set of methods for services and applications to leverage this password for authentication

A single password is of limited use unless it can be leveraged through one or more authentication services to provide user identity to applications. The authentication services necessary depend on the applications and the user interface to those applications. A goal of CITES is to support a flexible set of methods for leveraging the CITES-managed password that accommodate as many services and applications, whether run by CITES or by campus units, as can be done without significant increased risk of compromise of the password.

Three key technologies today for password authentication services are Web Initial Sign-On (WebISO) services, Kerberos, and LDAP. Web Initial Sign-On (WebISO) services provide support for a user, using a web browser, to authenticate to a web application by authenticating to a central ID service, which in turn transmits the user identity to the web application. Bluestem, developed at UIUC and deployed since 1996, is an example of a WebISO service. Shibboleth, being developed by Internet2, is an example of an enhanced WebISO. Kerberos is an authentication protocol created at MIT, and a Kerberos service has been deployed by CITES since the mid-1990's. Kerberos was adopted by Microsoft as the key authentication protocol used by Windows starting with Windows 2000. And finally, LDAP is a protocol for exchanging directory data that came out of work at the University of Michigan, and includes an authentication component. Many vendors deliver applications with LDAP authentication as an option.

WebISO

Bluestem has allowed CITES and campus unit web applications to leverage a central strong password for authentication in a secure manner since it was created. It requires the use of encrypted (SSL) channels of communication. And it has supported federated authentication from the start, allowing for UIC and UIS to share an authentication framework with UIUC, and for applications to take advantage of that if needed. To date, Bluestem has itself used the MIT Kerberos service as the password store. Bluestem offers a range of ways to integrate its use into various web server and web application environments. It is considered the strongly preferred method on campus to integrate authentication into web applications today. And if some small to moderate additions to Bluestem are identified that can enhance the ease of integrating its use into web applications, then providing those additions will be strongly considered.

CITES sees an encrypted WebISO-approach continuing to be strongly preferred for web browser-based authentication in the future. From the security standpoint it is ideal, in that the only service (and servers) that ever see a user's password is the central ID service. And it also provides a central point at which to support additional authentication methods, such as some form of two-factor authentication (discussed in the stronger levels of assurance whitepaper). But there is a need for a WebISO service to support more capabilities in the future. Shibboleth, being developed by Internet2, is an example of an enhanced WebISO that can support providing applications with a rich set of user attribute information in addition to-- or in lieu of-- the user's identity, and also provides support for federated authentication (see the Federated authentication whitepaper). CITES will explore whether Shibboleth might be a better alternative to enhancing Bluestem to match these same capabilities. AITS has also created a WebISO system called EAS (actually EAS offers a set of services, with authentication as just one of them) for use with Banner and other enterprise applications. Working with AITS to adopt or create a common WebISO framework (which might itself include Shibboleth) for the University that serves as the next generation of both Bluestem and EAS is another possibility that will be explored. Shibboleth and other approaches to providing a richer set of authorization information will be discussed further in a subsequent authorization roadmap.

One limitation to date with WebISO systems is that they can be used only when the user client interface is a web browser. There is some work being done which offers some hope that services such as Shibboleth, which rely on conveying user identity and attribute information to applications via what are called assertions using the Security Assertion Markup Language (SAML), might be able to be leveraged for a broader set of uses than web browser authentication in the future.

Kerberos

Kerberos, already a key authentication protocol at UIUC, became even more critical once Windows 2000 and a Campus AD service were deployed. Services and applications which interact with user clients using the Kerberos protocol in the standard way have the strong security advantage that the user's password is never transmitted across the network as part of a login, and is never available to application servers. The user's password instead functions as a shared secret between the user and a Kerberos KDC (Key Distribution Center), and is used only to symmetrically encrypt data between the user and the Kerberos KDC at initial login. So, theoretically at least, any service or application deployed within UIUC, whether by CITES or a campus unit, could satisfy security constraints by standard use of Kerberos authentication. And many modern Windows services and applications support standard use of Kerberos.

There is one caveat, however, to the security of Kerberos authentication that needs to be explored further. There is a known weakness to the current Kerberos protocol as implemented by MIT and by Microsoft. If one can sniff the network traffic between a user (Kerberos client) and the Kerberos KDC, one can capture the encrypted login request and carry out an offline password cracking attack. This threat will have to be analyzed further to determine how serious it is, and how it can be mitigated as necessary. Full channel encryption would clearly be one method of removing this threat.

LDAP

LDAP authentication refers to using what's called a "bind operation" within the LDAP protocol. The password is passed from the user's client to the application that supports LDAP authentication, and then that application attempts to bind to an LDAP server as that user. If the bind succeeds, the password is verified. Note that even if the password is transmitted from the user's client to the application, and then transmitted from the application to the LDAP server, over encrypted channels, the password is still available to the application in cleartext between coming from the client and being passed on to the LDAP server.

Thus LDAP authentication has the weakness that any application using that form of authentication has access to the cleartext password of any user attempting to access the application. A compromise of the application or the server upon which it runs could expose users’ passwords. LDAP authentication therefore presents an additional set of security challenges that have yet to be worked out. This provides a good argument for choosing either WebISO or Kerberos where feasible, with the WebISO approach in particular strongly preferred for web browser-based authentication.

Active Directory

The CITES-managed Active Directory (AD) domain contains a password that can be leveraged for authentication today through either the Kerberos or LDAP protocols. This AD password is included in the single strong password goal, and the strategies and policies for leveraging the strong password through Kerberos and LDAP, or even WebISO, will include and apply to AD. Additionally, CITES is beginning the process of collecting AD stakeholder input (within CITES and across the campus), from which an AD Service roadmap will be developed.

3. Reduce the number of times this password needs to be entered by the user (single sign-on)

The long form of the third area of focus is "reducing the number of times this password needs to be entered by the user while in a particular work session at the computer, where possible and appropriate. This is generally referred to as single sign-on". In single sign-on, you supply your password at the start of your work session, or when you access the first application requiring authentication. Subsequently, every application or service that is willing to accept that "prior authentication" will not require you to login again. This provides significant user convenience, but opens up additional risks if a user leaves the computer while their current work session is still active. The key here is that we want to move into single sign-on in a controlled fashion, making sure there is time to sufficiently inform users of safe practices in a single sign-on environment, and that our single sign-on environment supports all the features necessary to help ensure security.

Such a single sign-on service should allow for applications to determine if they are willing to accept the prior authentication event and how "recently" that authentication needs to have occurred to be still considered valid. The single sign-on service itself should enforce an upper bound on the allowed timeframe for continuing to honor a previous login. Plus the application needs to still be able to manage its own idle and session time timeouts.

There are commercial single sign-on products, some of which support only web browser (web access management products) single sign-on, and some of which support a broader set of applications. Windows-based clients can gain single sign-on with Windows integrated applications. But this whitepaper will limit itself to discussing single sign-on with a WebISO-based approach.

When a WebISO provides single sign-on, it is often then referred to as a WebSSO (for web single sign-on). The only problem with calling such a system a WebSSO is that some might take that to imply that single sign-on is required. And as stated above, we believe it is necessary for applications utilizing such a WebSSO environment to be able to opt-out -- or better yet, to have to explicitly opt-in -- to the use of single sign-on. So we will continue in this section to call this a WebISO.

Bluestem already supports a Bluestem-enabled application opting in to single sign-on, including specifying the acceptable timeframe in which the login event must have occurred. Bluestem documentation has referred to this as "prior authentication" support (if it has mentioned it at all). However, that is only supported explicitly if the application is using the Perl CGI API.

Bluestem will be enhanced to provide broader Bluestem interface support for use of this prior authentication, enabling applications to opt-in to single sign-on. The Bluestem enhancements will include a way to logout from the Bluestem ID servers, and applications opting-in to single sign-on will likely be required to provide a link (a way for the user to invoke) not only logout from the application, but also from the ID servers. The Bluestem service will also likely control which Bluestem application servers are allowed to opt-in to single sign-on, requiring that applications be explicitly approved to utilize this feature. That is one way of helping to ensure that applications provide a way to invoke the ID server logout in addition to an application logout. (And perhaps strongly encouraging the user to exit their browser before leaving their computer unattended.)

The AITS EAS system also supports single sign-on, as do many other Higher Ed developed WebISO systems. Shibboleth supports single sign-on, although this is currently more a feature of how Shibboleth is generally deployed on top of a campus WebISO service today.

There is also a plan to explore trusted authentication between the AITS EAS service and Bluestem service as part of a proposed University-wide technical integration pilot project involving uPortal. That exploration will involve determining if there are secure ways to enable single sign-on when moving from an EAS-authenticated application to a Bluestem-authenticated application, and vice-versa.

Finally, as we determine what is necessary in an enhanced WebISO, single sign-on with at least the above control features will be one necessary requirement.

Limitations of passwords for identity assurance

Password authentication has served as the primary method of authentication for years. But this requires users to provide only one thing – something they know (the password ) – in order to “prove” their identity. Authentication methods are often divided into three categories: something you know (e.g., a password), something you have (e.g., a smartcard), or something you are (e.g., biometrics such as a fingerprint). Combining more than one of these methods is called “multifactor” authentication.

The CITES Authentication Roadmap includes multifactor authentication as a future area of focus. A subsequent whitepaper will discuss this method of providing higher levels of identity assurance.