Search Stanford:

Strategic Vision

• Overview
• Technology Principles

Documents by Service Area

• Authentication
• Authorization
• Backups
• Calendar
• Desktop Management
• Directory
• Email
• Identity Management
• Integration
• Networking
• Storage
• Voice
• WWW Services
• Windows Infrastructure

Related Pages

• Planning Documents
• IT Services Projects
• Project Management Office

• IT Services
• Strategic Vision
• Authentication

Authentication Strategic Vision

Written by Russ Allbery, updated 1/11/07

This document presents the strategic vision for authentication services at Stanford, focusing specifically on the centralized authentication services provided by and managed by IT Services. This includes user authentication and authentication of services to each other, but does not include authorization (Authority Manager, PTS groups, ACL controls) or identity management.

Principles

The goal of Stanford's authentication system is to provide a highly stable, centrally administered authentication service both for internal use by IT Services and for use by any and all campus systems that need to authenticate the population of users affiliated with Stanford. We must attempt to balance the following concerns:

• A set of systems capable of handling the full authentication volume of all university business, tied into university-established notions of identity from the student and HR systems as well as sponsored and guest accounts, and able to centrally handle in a timely fashion withdrawal of authentication capability to terminated employees or abusive users.
  
  
• Use of industry-standard and vendor-supported authentication technology to ease integration with vendor applications and software developed elsewhere while avoiding locking ourselves into any one vendor.
  
  
• A highly secure authentication system that will be able to meet security concerns going forward. 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 HIPAA.
  
  
• Users must be able to authenticate via hosts other than their normal desktops, including mobile devices in the future.
  
  
• 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.
  
  
• 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.
  
  

Given the prevalence of the web as a user interface to applications, a trend which is expected to continue, special attention should be paid to standardized web authentication as the place that the most users will interact with the authentication system.

When possible, we will push for the ideal of never letting a user's authenticator leave their local system under their physical control. This means using network authentication protocols based on a local identity cache rather than sending a password or passphrase to a server for verification. However, we must recognize that there is very little vendor support for such authentication systems at present, particularly in common desktop clients, and most software is still stuck on the model of verifying a password on the server. When it is necessary to send an authenticator to a server, that conversation must always be encrypted. (In other words, the network link shall not be trusted.)

All Stanford users will have to interact with the authentication system to do their daily work. In addition, all application developers and system administrators on campus, inside IT Services and out, represent a key audience for our authentication strategy. If we do not meet their needs, they will develop their own separate authentication systems, which both harms our ability to centrally manage authentication and hurts the consistency of the user experience. The goal is to get as close to universal use of the central authentication services as possible.

The authentication system will be closely tied to any campus identity management or authorization systems, and therefore will be directly affected by any projects in those areas even if those projects are not authentication projects directly.

Technologies

Stable core technologies:

• Kerberos v5 as the underlying authentication service and central repository for all password-like authentication.
  
  
• MIT Kerberos for Windows (via Network Identity Manager) and Kerberos for Macintosh as desktop authentication clients, wrapped in a distribution mechanism that allows easy client upgrades and provides any necessary Stanford-local configuration.
  
  
• SASL and GSSAPI for authentication of network services.
  
  
• Windows Active Directory to support Kerberos v5 and NTLMv2 authentication to Windows services.
  
  
• Webauth v3 for web authentication, including support for Negotiate-Auth and SPNEGO to allow authentication without sending the user's password where possible.
  
  
• SSL/TLS X.509 certificates for establishing network encryption of access to network services. The authentication aspect of TLS certificates (of the server to the client) is not considered particularly strong or useful except insofar as it presents a UI issue.
  
  
• SSH v2 as a standardized encrypted protocol for Unix account login, using Kerberos for the authentication layer.
  
  
• Username/password authentication over an encrypted channel (either via SSL/TLS or SSH), with the password verified against Kerberos.
  
  

Emerging technologies: (see Research below)

• Shibboleth for cross-realm authentication and authentication to off-campus vendor-managed services, and possibly to provide integration with WebAuth for platforms with no native WebAuth support (Apache 1.x, Microsoft IIS).
  
  

Deprecated technologies: (see Projects below)

• Any and all transmission of a clear-text password over the network for any authentication purposes whatsoever. There is no longer any excuse for not using at least network encryption to protect passwords.
  
  
• Local Unix passwords for any user other than root within IT Services. Most commonly seen in combination with shared accounts, local Unix passwords pose a significant security and audit risk to the university since they cannot be centrally managed. They will continue to be used by departments which do not fully use the central authentication infrastructure, but all IT Services accounts and services should use Kerberos as the authentication service, whether that be through GSSAPI or just through validating a provided password against the Kerberos database.
  
  
• PC Leland and MacLeland. They are being replaced with new desktop software packages based around the current Kerberos and AFS software releases for Windows and Mac OS X. (MacLeland has already been a very thin wrapper around the Mac OS X Kerberos implementation for some time.)
  
  
• Webauth v2 and Kerberos v4. There are only a handful of WebAuth v2 servers remaining, and most users of KPOP to the central email servers have converted to other forms of authentication. Remaining uses of Kerberos v4 besides those are the Registry event system, a small handful of S/Ident-authenticated services, Zephyr, and Unix host login (currently both Kerberos v4 and Kerberos v5 authentication are done.
  
  
• SSH v1 and public key authentication with any version of SSH. SSH with GSSAPI authentication is mature and stable at this point and should be used instead, including for application authentication (and uses of SSH for application authentication should be considered carefully -- a more limited RPC mechanism may be appropriate instead).
  
  
• S/Ident, due to its vulnerability to an active man-in-the-middle attack.
  
  
• DES as an encryption technology. DES is now too weak and too easy to attack to provide trustworthy security. Our Kerberos v5 KDCs now support 256-bit AES and triple-DES as well as DES for user authentication, but not yet for server authentication. Also, currently AFS does not support any stronger authentication type, but there is active ongoing work on a native Kerberos v5 authentication and encryption layer for AFS that can use the full set of encryption algorithms that Kerberos supports.
  
  

Other technologies in use: (These technologies are currently deployed and useful in specific circumstances, but either are not attractive for broader use or have a limited scope of applicability -- we are neither recommending expanding them nor recommending eliminating them at this time.)

• Database passwords. Currently, database authentication is done via the traditional means of storing a password for the database account in the database for lack of a better supported authentication mechanism. Such authentication should at least be protected by SSL/TLS.
  
  
• Client-side X.509 certificate authentication. In use for some applications of the registry XML document service. It is a useful and robust authentication system for system-to-system authentication, but poses enough UI, revocation, and distribution problems that it's unattractive for user applications. It is, however, moderately well supported, so we should not rule it out entirely.
  
  
• Local Unix passwords for root. This is useful for console access when the network is unavailable and in other circumstances as a final fallback authentication mechanism. There is no reason to change this, but also no reason to expand use of Unix passwords beyond this one purpose.
  
  
• RADIUS both as a mechanism for getting devices that aren't Kerberos-aware to validate passwords against Kerberos and for wireless guest access. RADIUS is useful for network equipment authentication since it is widely implemented and can be used to check passwords against Kerberos, but it has the drawback that to integrate with Kerberos, it must be run in a mode that sends the password over the network (encrypted). For wireless guest access, RADIUS is not using Kerberos, but instead is using its own separate password database.
  
  

Projects

First:

• Release new desktop Kerberos packages based on Network Identity Manager for Windows and the integral Kerberos support in Mac OS X that do not use Kerberos v4. Work with campus users to upgrade all campus desktops.
  
  
• Deploy a Kerberos v5-based replacement for leland_srvtab and our existing srvtab/keytab download process (which is based on Kerberos 4). Use NetDB roles, among other systems, for authorization.
  
  
• Support stronger encryption types than DES in Kerberos v5 for system and service keytabs. his will be done as part of the new key distribution system as mentioned above.
  
  
• Implement bidirectional cross-realm trust between Windows AD and the MIT Kerberos realm.
  
  
• Implement a PEAP-MSCHAPv2 authentication system that uses Kerberos (specifically Windows AD) as the backend authentication store, for use with the wireless access project.
  
  
• Finish the documentation, packaging, and production stabilization of our new campus Shibboleth service.
  
  

Next:

• Upgrade the remaining WebAuth v2 systems to WebAuthv3, Shibboleth, or some other authentication mechanism or turn them off entirely.
  
  
• Phase out all remaining uses of S/Ident in favor of direct GSSAPI authentication or other authentication schemes.
  
  
• Support automated tracking and enforcement of locked accounts for security reasons rather than the current manually-checked ad hoc procedure.
  
  
• Replace the Registry event system with a new event system that does not rely on Kerberos v4.
  
  
• Rekey all IT Services-managed systems and services with Kerberos v5 keys with stronger encryption types than DES. At least triple DES or RC4 and preferably 256-bit AES should be used.
  
  
• 
  
  

Later:

• Eliminate all local Unix passwords for non-root application accounts on servers run by IT Services in favor of using Kerberos-based authentication (either SSH with GSSAPI authentication or SSH with username/password verified against Kerberos and .klogin/.k5login) or sudo from individual-owned accounts.
  
  
• Switch completely over to Kerberos v5 and retire the Kerberos v4 realm. This will probably require retiring Zephyr (currently used for synchronous mail notification and some instant messaging) unless someone has ported it to Kerberos v5 by this point.
  
  
• Implement real Kerberos v5 password aging for at least selected populations, including support for changing expired passwords in the desktop software and in Stanford.You.
  
  
• Set up a separate authentication realm for guests of Stanford with a weaker identity binding and simpler password change mechanism than we require of full SUNet IDs. Set up an authentication infrastructure using Shibboleth and automation around creating new accounts and assigning entitlements to accounts to enable university departments to use this system for guests, external weakly-authenticated users, transient accounts, and similar populations.
  
  
• Set up an end-to-end test environment, in conjunction with account service provisioning, Windows AD, and other infrastructure services, to provide a more complete testing infrastructure.
  
  

Research

The following areas should be explored with an eye to their long-term inclusion in our authentication strategy. Without more information, it is premature to specifically identify any of these areas for projects, but if the research pans out, they may move from this section into the project section for a full production implementation. Each research project is associated with an initial application that we can use to test the results of the research.

• A Stanford University PKI, most likely in the form of a Stanford root certificate that can be used to sign X.509 certificates. Initial application: Use of Stanford-signed certificates for any SSL/TLS web service that does not need to be accessible to the general public (initially, dev, test, and UAT web servers, but possibly including any Stanford-only service where we control the population that will be using SSL/TLS and can tell them to install a root certificate in their browser). This could possibly result in thousands of dollars of savings in purchases of traditional certificates, and/or gains in security through fewer uses of a *.stanford.edu certificate.
  
  
• Integration of WebAuth and Cosign. Cosign provides a better logout mechanism, but WebAuth has much more penetration and production experience at Stanford. A WebAuth system that could also speak Cosign so that a Cosign login server and Cosign-enabled web servers could be mixed into our existing web infrastructure would allow us to start making use of Cosign's site-wide logout and Cosign's support for IIS and Apache 1.x
  
  
• Growth of Digital Rights Management issues with the Stanford Libraries and particularly the Digital Library Project will raise additional authentication issues, both for library patrons and for authentication of university systems to rights management systems external to the university. It's not as yet clear what those issues will be.