Authentication

Overview

Authentication is central to the use of nearly every computing device and service, all the more so due to the growth of cloud computing and the movement of data and services into networked applications accessible from anywhere in the world. Support for mobile users requires authenticating them wherever they may be and whatever device or platform they choose to use. Attacks against authentication systems and social engineering attacks against people's interactions with authentication systems are simultaneously becoming increasingly sophisticated, leading to a huge increase in the number of compromised accounts and successful frauds perpetrated against the campus community. Old-style single-password authentication, which is what people typically think of as all that is necessary for authentication, is insufficiently robust against current attacks and isn't flexible enough to allow for limited authentication of partly trusted applications and devices. And increasingly, single-password protection is not sufficient to pass muster with auditors.

The university community makes heavy use of the existing authentication system and expects that system to work similarly on new mobile platforms, when interacting with external systems and cloud resources, and on new, more complex, and often federated applications. Safe and efficient use of cloud computing requires more sophisticated authentication mechanisms than entering a password. Ensuring appropriate authentication mechanisms are ready in advance of widespread use of cloud computing will save expensive re-engineering and fixes later.

Authentication is one of the primary ways IT Services interacts with every Stanford-affiliated user, even those who may not take advantage of other central services. The quality and ease of use of authentication systems is therefore critical to the public perception of central IT services.

Current State

Stanford's authentication system provides a highly stable, centrally administered service for use by campus systems that need to authenticate users. Kerberos is the center of the university authentication infrastructure. Stanford maintains, and will continue to maintain, two Kerberos realms with mutual trust, one using a UNIX-based Kerberos KDC (Key Distribution Center) and one using Windows' Active Directory. The two realms provide a great deal of flexibility, allowing IT Services to use whichever one is most appropriate for a given application. Required features of Stanford's authentication system include:

• It is tied into the university-established identity from the student and human resources systems as well as sponsored and guest accounts, and is able to handle the full authentication volume of all university business.
• It is built on industry-standard and vendor-supported authentication technology to ease integration and to avoid loss of flexibility by being tied to one proprietary system. This is particularly important in Stanford's diverse environment.
• It is highly secure, and able to meet audit requirements. The authentication system must never be the weak point in the security of an application and must be sufficient to comply with regulatory restrictions such as PCI (Payment Card Industry).
• It is able to integrate and cooperate with federated identity systems, both authenticating our users to systems, services, and content hosted elsewhere, as well as supporting federated authentication of users coming from academic or business partners.

The university's default Kerberos realm is a UNIX-based KDC (the stanford.edu realm), which has been supplemented with extensive local infrastructure for key management, password strength checking, and APIs for administrative commands and automated provisioning. Active Directory (the WIN.STANFORD.EDU realm) provides extensive additional functionality for Microsoft Windows systems within the domain, handles key management well for Microsoft applications, and is required for a full-featured Microsoft Windows infrastructure. User accounts are automatically synchronized between the two realms. All password changes are done in the UNIX KDC and propagated automatically into Active Directory. Key management for most services and computers is done in the stanford.edu realm, with the Active Directory realm used for Windows-based applications within the domain. The distinction is largely transparent to users.

The core authentication services include:

• Kerberos v5 for the stanford.edu realm and for Active Directory.
• SASL (Simple Authentication and Security Layer) and GSSAPI (Generic Security Service Application Program) for authentication negotiation for network services.
• Passwords over TLS (Transport Layer Security) — encrypted channels verified against Kerberos on the server for clients without native Kerberos support (such as many e-mail clients).
• WebAuth v3 for web authentication, including support for SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) over Negotiate-Auth to avoid sending the user's password over the network where possible.
• Ticket delegation via WebAuth v3 to selected services that need to act on behalf of the user.
• Commercial X.509 certificates for verification of web server identity by web browsers.
• ssh (secure shell) v2 using GSSAPI or passwords verified with Kerberos on the server for shell access to UNIX systems.
• Shibboleth (built on SAML) to carry authentication information for federated users and guest accounts.
• RADIUS backed by Active Directory using the same key store as the Active Directory Kerberos KDC, used by network devices.
• Two software packages are distributed to allow Windows and Macintosh users to authenticate to the stanford.edu realm: A custom build of Kerberos for Windows, maintained via a support contact with Secure Endpoints, and a configuration utility developed by IT Services to configure Kerberos for Macintosh for use with the stanford.edu realm.
• Lenel OnGuard for building access, with some legacy use of CBORD CS Gold.

There are additional authentication technologies used in cases where Kerberos cannot be assumed to be working (primarily for services that Kerberos itself relies on):

• Local UNIX passwords for root access.
• Client X.509 certificate authentication for Puppet for UNIX systems management.
• Client ssh public key authentication to manage the DNS servers.

And there are also some legacy authentication systems that ideally should be replaced by ones that are integrated with Kerberos:

• Database passwords stored in the database and sent over encrypted channels. Databases other than Microsoft SQL Server are the worst offenders at lacking any good support for central authentication systems, although there are hopeful signs of better Oracle support for Kerberos authentication. MySQL continues to be a challenge here.
• Client X.509 certificates issued by Administrative Systems for access to the XML document service and SonicMQ event system.
• Some lingering local UNIX password use with shared accounts because of Ntirety requirements and limitations.

Vision

The primary directions of the authentication system are towards improved support for public-key authentication through X.509, and towards deployment of multi-factor authentication. Authentication projects over the next three years will focus mainly around support for X.509 authentication, including use of X.509 as part of two-factor authentication for users. The goal is to add support for X.509, without moving away from Kerberos as the primary authentication store or building a second authentication system in parallel. IT Services is also looking to increase the flexibility and integrate new protocols into the existing authentication system. This will allow more applications, protocols, and communities to make use of the central authentication system.

Kerberos uses shared secret keys for authentication and is the leading representative of that family of authentication technologies. Public-key (asymmetric) authentication using X.509 is the primary competing authentication technology. For network protocols, apart from lingering use of LDAP (Lightweight Directory Access Protocol) as a password verification method (uninteresting for Stanford due to its lack of support for multi-factor authentication), authentication protocols are bifurcating into those two families. X.509 is the most common public-key technology due to widespread use of TLS on the web, but OpenPGP (Open Pretty Good Privacy) has a strong presence in signature and encryption systems. Both of those families are in widespread use; some applications use only one and some use only the other. Bridging the two into a single system will therefore be important to avoid maintaining two parallel authentication systems.

Multi-factor authentication is the next step beyond simple password protection. Continued increases in computing power are undermining passwords as an authentication mechanism. It is reaching a point where the average user is unable to remember and enter a password of sufficient complexity to protect against brute-force attacks. Passwords are also very vulnerable to social engineering attacks such as phishing, as has been seen in the significant increase of compromised Stanford accounts over the past two years. Two-factor authentication that doesn't rely solely on human memory is the way forward.

A two-factor authentication system requires a user to identify themselves not only by a password (what they know) but something that they have, like an ID card. In part because of Microsoft's whole-hearted adoption of Kerberos, there is increasing movement away from pure password-based systems and towards cryptography-based systems that can support both passwords and other authentication mechanisms. Biometric authentication is interesting for authentication that requires physical presence, such as building entry, but is not as useful for network authentication and has multiple flaws discussed at length in industry literature. The most promising second factor for day-to-day authentication is some form of cryptographic hardware device. Prices of such devices have been falling quickly into the range where it would be practical to provide every Stanford user with one.

There are two anticipated use cases of multi-factor authentication on campus: authentication to privileged systems or environments that require higher than normal levels of security, such as critical business or infrastructure systems (strong multi-factor), and replacing passwords for the general campus community with security technology that's harder to steal from users or their computing devices (weak multi-factor). Support for both will be required, but each have different requirements and different possible technology choices.

Among hardware encryption devices, an increasing number do not work well with Kerberos, such as SecurID. These may play a role in weak multi-factor since they may be less expensive than devices and card readers for X.509 authentication and place fewer hardware requirements on the clients. However, they may not offer the level of assurance required for the strong multi-factor use cases. They are also harder to integrate with central authentication systems. There is also increased standardization in the X.509 authentication space around the technology used for national ID card systems and, in the US, the PIV-II (Personal Identity Verification) standard used by the US government for identification of government employees.

To maintain the high levels of assurance and security expected by the University community, central authentication systems must support and encourage industry best practices:

• Use of central authentication based on university systems of record, rather than separate authentication systems maintained by individual groups or departments.
• Authentication should be mutual, allowing clients to confirm the identity of the server as well as allowing the server to confirm the identity of the client. This will assist in preventing phishing and man-in-the-middle attacks.
• Authentication should be external to applications so that authentication mechanisms can be updated or changed to reflect changing requirements without requiring significant application development or surgery.
• Ideally, the user's authenticator should never leave a system over which they have physical control, which would mean that network authentication protocols would be rely on a local identity cache, rather than sending a password or passphrase to a server for verification. However, it must be recognized that there is very little vendor support for such authentication systems at present, particularly in common desktop clients, and most software is stuck on the model of verifying a password on the server.

Other technological trends which factor into the strategy for future authentication services:

• Mobile devices: A significant portion of users are on mobile devices, and they expect to have access to the same services with the same convenient authentication mechanisms. However, the devices pose some unique challenges due to limited availability of common authentication technologies on the devices and the increased risk of theft. Industry best practices here are converging on provisioning authentication keys to mobile devices and applications running on mobile devices, rather than having a user enter their primary authentication credentials into those devices.
• Weak authentication: On the other end of the authentication spectrum, there is increased use of weak authentication systems for low-value data, frequently with a federated component. OpenID is probably the most widely-deployed technology in this area. Here, the effect on Stanford will probably be more in the area of accepting such authentication mechanisms where appropriate, rather than providing such forms of weak authentication and potentially creating confusion with the strong authentication preferred for university business.
• The two-port Internet: Applications are increasingly being deployed exclusively on the web. The trend for the past five years has been for an increasing share of authentication events to happen over HTTP and HTTPS. That trend is expected to continue.
• Claims-based systems: The general industry trend towards cloud computing and provisioning of services by loosely-affiliated third parties will place increased pressure on federated authentication and communication of authentication information to potentially partly-untrusted third parties. Industry best practice is to hold authentication systems close, bringing users back to the authentication service of their local organization to be authenticated, and then communicate that information to third parties via standard protocols such as SAML.

Goals

To make Kerberos and X.509 authentication interchangeable and convertible, allowing applications and users to choose the mechanism most appropriate for each situation, and provide a foundation for strong multi-factor authentication:

• Implement PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) as a two-factor authentication system for privileged users, with an eye towards providing it for all users in the future. This will also allow applications to obtain Kerberos credentials from X.509 certificates.
• Add support for generation of short-lived X.509 certificates based on Kerberos tickets (generally called KCA or KX509), and provide external utilities to do this and populate a local certificate store. This will allow applications that only speak X.509 to rely on their Kerberos identities and principals for authentication without needing to know anything about Kerberos.

To implement weak multi-factor authentication:

• Choose and deploy a weak multi-factor authentication technology that's inexpensive enough to distribute to everyone on campus, but provides additional security against deception and system compromise over passwords. Possible technologies include one-time password systems, possibly through hardware tokens (such as RSA SecurID tokens), or software agents that duplicate hardware tokens. Some combination of these approaches is likely.
• Evaluate mechanisms for authenticating mobile devices and applications running on those devices other than storing a password in the application, choose an appropriate technology, and work with campus partners to add support for that technology to university services.

Operational improvements that need to be done over the next three years to maintain the current level of service:

• Provide a web services interface to WebLogin for applications that need access to WebAuth-protected or Shibboleth-protected web sites. This, in combination with KX509 support, will allow full access to the authentication system by applications and automated processes. This is particularly important for mobile app development, such as the iPhone.
• Implement enforced password aging for selected populations (mainly HIPAA (Health Insurance Portability and Accountability Act)-covered entities and PCI (Payment Card Industry)-affected users).
• Improve integration of the university web authentication infrastructure with other technologies and platforms: provide integration of Microsoft IIS with WebAuth, either through deployment of ADFSv2 and Shibboleth integration, or via a native WebAuth implementation, or both; provide integration with Java web applications through a CAS implementation that interoperates with WebAuth.
• Retire use of DES (Data Encryption Standard) in campus authentication systems. DES is no longer sufficiently strong to provide reliable security, and support for DES keys is already deprecated in current implementations of Kerberos both in UNIX and in Windows.
• Determine whether support for password lockout is required for PCI compliance and, if so, implement it. Password lockout has some serious problems, among them the increased vulnerability to denial of service attacks, so it's preferable to use other defenses against brute force attacks such as password-strength checking, FAST (a protocol improvement to Kerberos making brute-force attacks more difficult), and proactive throttling of repeated authentication attempts from a single source (which catches more attacks than password lockout). However, password lockout is specifically mentioned in some audit checklists.
• Support OpenID authentication for guest accounts for those users who already have an account with an OpenID provider.

Roadmap

To implement PKINIT and two-factor authentication for privileged users:

• Upgrade the Microsoft Windows Active Directory infrastructure to Windows Server 2008 R2.
• Implement PKINIT in the central authentication servers using contact chips and cards that can be provisioned by the same vendor used for Campus Card Services. A contact chip compatible with the US government PIV standard is preferable, since many of those cards exist and are widely supported by software and operating systems. Pilot work has already been done in Active Directory. Support in the stanford.edu realm will require software upgrades and testing.
• Replicate the certificate verification information used for PKINIT between the stanford.edu realm and Active Directory.
• Implement Forefront Identity Manager with Active Directory as a provisioning system for the long-lived X.509 certificates that will be used for hardware tokens with PKINIT.
• Require multi-factor authentication using hardware X.509 cards for authentication to high-value systems. Multi-factor authentication will be rolled-out in four phases, with progress dependent on the testing results at earlier phases and the price of the required hardware:
  1. Identities with administrative access to the KDCs for initial testing.
  2. All privileged system accounts (root- or administrator-equivalent Kerberos principals) inside IT Services and Stanford's major university partners.
  3. Authentication to high-value applications such as financial approvals and applications dealing with restricted data. (Requires WebAuth support as mentioned below.)
  4. General availability of multi-factor authentication to campus.
• Determine desired levels of assurance and define issuance policies for digital certificates for broader deployment.
• Improve support in WebAuth for role-based authentication and hardware authentication so that the same higher-security requirements can be applied to web-accessible systems.
• Evaluate whether to fund additional development of Network Indentity Manager on Windows, and a possible port to Mac OS X, to support other authentication credentials such as X.509 certificates.
• KCA/KX509 will then be the next step. Exact deployment details will depend on the choice of MIT Kerberos or Heimdal for the stanford.edu realm. Microsoft does not have a similar product, but Secure Endpoints does have a KCA service for Active Directory that Computing Services will explore.

For weak multi-factor and mobile device authentication:

• Explore technologies for weak multi-factor authentication, preferring options with a very low hardware cost or with software agents that can run on devices already in widespread use, such as iPhones.
• Add WebLogin support for weak multi-factor authentication via a chosen technology and provide a way to require that authentication instead of a password for specific accounts.
• Explore application authentication technologies such as OAuth keys for authenticating mobile device applications to specific services without disclosing the user's full credentials.
• Add support for mobile device authentication using such a technology to at least one core service, such as email or calendaring.

For password aging:

• Modify WebLogin to support password change of expired passwords.
• Test and document the behavior of desktop Kerberos implementations with expired passwords.
• Identify the affected populations for which password aging should be mandatory. If this is not the entire university, implement an automated way of setting appropriate password policies for those users.
• Enable enforced password aging, which will require extensive community communication and campus readiness.

For DES (Data Encryption Standard) retirement:

• Rekey all systems in the stanford.edu realm that have not been rekeyed since the addition of 3DES and AES encryption key support. This should be done as part of setting up automated processes to rekey as many systems as is practical on a regular basis without requiring sysadmin attention.
• Change the cross-realm trust with the Windows Active Directory realms to use AES and RC4 encryption types instead of DES. (RC4 is required to support Windows XP.)
• Add RC4 to the default set of encryption types generated on principal creation or key change to allow Windows XP systems to use a stronger encryption type than DES.
• Encourage users who have not changed their password since the addition of stronger encryption types to do so. Many of these users will be forced to do so by password aging, so this should start after password aging is implemented. For instance, a warning could be displayed on the WebLogin screen if the user has only DES keys in the KDC.

And separately:

• Add OpenID authentication support to the Guest Accounts system rather than requiring the user configure a separate password for those guest users who don't need a local password for other reasons (no OpenID account, for example, or needing access to Windows systems protected by Guest Accounts).
• Continue to work with Secure Endpoints to ensure Kerberos for Windows remains functional and compatible with the latest OS releases from Microsoft.

Measures of success

• All Computing Services staff can, and are required to, use two-factor authentication for access to privileged roles and restricted data.
• IT Services can successfully deploy applications that only understand X.509 authentication while using Kerberos as the application identity management system and without maintaining a separate X.509 authentication system unrelated to Kerberos.
• All passwords of HIPAA- or PCI-covered staff members have either been changed within the past six months or are disabled except for password changes.
• Users can access central services from mobile devices without having to enter their passwords into those devices.
• Reduction in the number of compromised SUNet IDs due to successful deployment of multi-factor authentication.
• Increase the number of Kerberos-authenticated services that support use of encryption keys that are stronger than DES and the number of users who have stored keys stronger than DES, aiming for 100 percent coverage so that DES support can be disabled.