Kerberos Authentication for the Web

Shumon Huque, Jorj Bauer
University of Pennsylvania
January 2009

Introduction

It has been possible to use the Kerberos authentication protocol in Web (HTTP) applications for several years. Although various attempts to standardize Kerberos authentication in HTTP have been made, the method that has gained the most support in practical terms is one developed by Microsoft, and documented in RFC 4559 "SPNEGO-based Kerberos and NTLM HTTP Authentication in MS Windows". Besides Microsoft software (IIS and Internet Explorer), it has been widely implemented in other software, eg. Mozilla Firefox, Apple's Safari, Opera, Apache, etc.

RFC 4559 (referred to as "HTTP/SPNEGO" in the remainder of this document) has a number of technical and security problems. It offers authentication only and does not offer channel protection (protection of the data stream). It does not support more complex (although less common) multi-round-trip GSS-API mechanisms. Also in certain implementations it is difficult to support mutual authentication correctly. It is furthermore, an "Informational" RFC, and thus not an Internet standard, or standards-track document. There are efforts underway in the IETF and elsewhere to address these deficiencies, and standardize the protocol. But in the interim, it is possible to mitigate many of the problems by using it over SSL/TLS (ie. HTTPS). This document strongly recommends deploying HTTP/SPNEGO only on a webserver protected by SSL/TLS.

It is possible to use Kerberos in other ways to authenticate users of web applications. For example, Kerberos is often used as a back-end password verification service by the webserver, while the communication between the browser and server involves the transmission of a username and password over the network (in cleartext or over SSL). This method cannot correctly be described as Kerberos authentication, and is not recommended for use by the Penn community, since it exposes user passwords to an application server. To support applications using password based authentication like this, Penn's central web authentication system (WebLogin) should be used.

Some Deployment Tips

Create a Kerberos service principal

Setting up a server for HTTP/SPNEGO requires the creation of a Kerberos service principal on the Kerberos server (KDC) and making available the secret key for this service principal to the webserver. The default form of the principal is "HTTP/f.q.d.n", where f.q.d.n is the fully qualified domain name of the web server. The service principal name and key are usually stored in a file called a keytab. This file should be strongly protected from disclosure. If stolen or compromised, then it could be used by an attacker to impersonate the service.

Configure SSL/TLS on the webserver

No description is provided for this step, since it's generally well known how to do this.

Ensure the Kerberos GSS-API mechanism is being used

GSSAPI (RFC 2743) is a generic AuthN mechanism. It may perform authN through methods other than Kerberos. In particular, it should be noted that Internet Explorer (versions 6 and 7, at the time of writing this document) makes the assumption that it's talking to an IIS web server, capable of performing NTLM-hashed password validation. If, for example, an Apache server employes mod_kerberos (either as required or as available), an IE client that does not have the appropriate Kerberos ticket will pop up a dialog for the user to enter their Windows NTLM password to the Apache server. This obviously serves no good purpose to the Apache server, and potentially lessens the security of the user's hashed password.

Example Webserver configuration (Apache)

The modauthkerb module and instructions for configuring it for the Apache webserver can be found at http://modauthkerb.sourceforge.net/ An example .htaccess file that uses HTTP/SPNEGO authentication, and only allows it over SSL follows: 
		SSLRequireSSL
		AuthType Kerberos
		AuthName "Kerberos Login"
		KrbAuthRealms UPENN.EDU
		KrbMethodNegotiate on
		KrbMethodK5Passwd off
		KrbServiceName "HTTP/www.upenn.edu"
		Krb5Keytab "/usr/local/apache/conf/http.keytab"
		require valid-user
SSLRequireSSL makes SSL mandatory. "AuthType" specifies Kerberos. KrbAuthRealms specifies the Kerberos realm. "KrbMethodNegotiate on" specifies the HTTP/SPNEGO method. "KrbMethodK5Passwd off" specifies that Kerberos password verification should NOT be used. KrbServiceName and Krb5Keytab specify the Kerberos service principal name and the location of it's keytab file. "require valid-user" specifies that any Kerberos authenticated user is allowed access to the protected content.

Example Webserver configuration (Microsoft IIS)

Pointer to some Microsoft technical documentation?

WebLogin: HTTP/SPNEGO with fallback to CoSign?

Say something about supporting an environment with a population of browsers that are not all Kerberos capable? Deploy 2 standalone authentication mechanisms (CoSign and HTTP/SPNEGO)? Or use CoSign's ability to fallback gracefully from SPNEGO (does it actually work?)

Summary

Penn's central authentication system is based on Kerberos. Supporting the Kerberos authentication protocol directly in web applications is one of it's a long term strategic goals. Use of HTTP/SPNEGO, despite it's current technical issues, and lack of universal support, is a step in that direction. Kerberos in web applications provides better integration with Penn's authentication infrastructure, and the convenience of secure, Single Sign-On capability. It also provides an advanced level of protection against the phishing of authentication credentials -- an increasingly wide scale problem on the Internet made possible by the ubiquitous paradigm of sending passwords directly over the network to application servers. Penn hopes that upcoming work on fully standardizing Kerberos authentication for the web proceeds quickly. New developments to better integrate Kerberos with federated identity systems are also expected to play a role here.

References