Developer Overview

Kerberos, GSSAPI, & SASL

Jay Kline Version 1.0

Developer Overview
Introduction................................................................................................................................................1 Kerberos.....................................................................................................................................................1 GSSAPI......................................................................................................................................................2 SASL..........................................................................................................................................................3 A Few Quirks.............................................................................................................................................3 Revision History
Date 2007/04/06 Author Jay Kline Initial writing Change Description Affected Section

Introduction
There are multiple was to write programs that will interact with Kerberos. This document will describe details useful for implementing Kerberos in Openfire and Spark. The XMPP protocol prefers to use SASL as its authentication mechanism, which defines a method of using the GSSAPI protocol. GSSAPI in turn uses Kerberos.

Kerberos
Java has had support for working directly with Kerberos since 1.4.2. Java has implemented these objects The Java Authentication and Authorization Service (JAAS) provides the object com.sun.security.auth.module.Krb5LoginModule (as well as modules for other protocols) which can even perform the prompting to perform an Kerberos login and obtain a TGT. JAAS is the Java equivalent to PAM, and is designed to be configured with separate configuration files, which can indicate which modules and options to use. An example JAAS configuration is provided below.
ApplicationName { com.sun.security.auth.module.Krb5LoginModule required debug=true; };

Configuration is provided by the javax.security.auth.login.Configuration object, whose default implementation is a file. It is possible to implement a separate Configuration object that pulls the information from a different source or file format. The Configuration object provides an application (specified as ApplicationName in the example) with any number of modules (give the full class name) with information about each module. A module can be required, requisite, sufficient, or optional. For the purposes of this document, we will only discuss configurations with Kerberos being the only module specified as required. If an application name is not found, the application other is looked up last to provide some defaults. Krb5LoginModule options:

useTicketCache If true, get credentials from a ticket cache. If this is false, it will attempt to prompt the user to authenticate, and not keep the credentials when done, thus avoiding the SSO concept. doNotPrompt If true, the module will make no attempt to prompt the user to authenticate. If false, the module will prompt the user to authenticate if credentials can not be obtained from the ticket cache. useKeyTab If true, the module will obtain credentials from the keytab. Set page 1

this to true for servers.

keyTab This is the location of the keytab (if useKeyTab is true). The default if this option is not set is OS dependent. storeKey Set this to true for servers. Since the server has no way of prompting a user, it needs to store the principals key the Subject's private credentials. Without this option, the server will fail since the credentials will not be stored. principal This is to be set to the principal to be used for the server. Although you can set the principal for clients too, the client principal can be determined from the credential cache, so it should be omitted.

There are other options available, but they will not be used in this document.

GSSAPI
GSSAPI is a generic interface for passing credentials between principals. Since Kerberos is still being used, the JAAS Configuration is still used. GSSAPI objects use com.sun.security.jgss as the prefix for the application name specified in the configuration file, and uses .initiate as the suffix for the client, and .accept as the suffix for the server. Specific protocols are looked up (such as .krb5.initiate) but using specific protocols can limit the flexibility of the application in the future. Obtaining new credentials is protocols specific, therefore GSSAPI can not be used to acquire new credentials. This means the doNotPrompt option should be set to true for GSSAPI applications.
/* GSSAPI Client */ com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required doNotPrompt=true useTicketCache=true; }; /* GSSAPI Server */ com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required storeKey=true }; doNotPrompt=true useKeyTab=true principal="xmpp/server.example.com@EXAMPLE.COM";

Since the goal is to have universal access to the credentials, the system property javax.security.auth.useSubjectCredsOnly must be set to false. This property when set to true (the default) only allows the GSSAPI objects to access credentials in the Subject object. When set to false, then the GSSAPI object may obtain page 2

credentials from other places, such as the credential cache used outside Java. In addition to authentication, GSSAPI provides Channel Bindings for secure communications. In essence, it is a communication channel cryptographically bound to the initial authentication. The advantage is this can be exported to outside channels. The common example is SSHv2 over a VPN, where the GSSAPI credentials initiating the VPN are shared with the SSHv2 session to avoid double encryption. This could be implemented in the XMPP protocol where the SSL keys are determined by the GSSAPI negotiation, but there would be little gain over the current implementation.

SASL
Java provides both SASL client and server objects to perform the most common authentication and authorization mechanisms, including GSSAPI. The GSSAPI SASL objects make use of the GSSAPI infrastructure, so the same configuration file will be used. SASL allows the client and server to choose a mechanism and negotiate properties for the session. This means it would be possible for the server to accept both GSSAPI and PLAIN mechanisms, so if a client does not have any GSSAPI credentials, a PLAIN login is still possible. Although this makes things easier for the client, it does reduce the security of the authentication to the weakest mechanism. SASL objects make use of callbacks to provide interaction with the application. With GSSAPI, the client already possesses the full credentials, so no callbacks are needed to obtain the information (such as the name, realm, or password). The server then only needs to make use of the AuthorizeCallback to perform the authorization after authentication takes place. Since GSSAPI and Kerberos allow the server to authenticate to the client, the SASL property SERVER_AUTH should be set to true to force the authentication. If the server cannot authenticate to the client (in the case of a compromised server, for example) the connection will be ended. Additionally, the SASL property QOP (Quality of Protection) can be set to one of three levels. The default, is to just authenticate. Additionally integrity checking and confidentiality can be added. With GSSAPI these additional levels are performed using the channel bindings.

A Few Quirks
There are a few quirks when working with this in practice. Kerberos relies heavily on encryption, where the algorithms used are dictated by the KDC. Java needs to be able to understand the encryption types to make use of the tickets or keytabs. Due to US Export Controlled Information (ECI) laws some cryptography algorithms cannot be exported, and the default install of Java will not work with those algorithms (AES-256 is one of them). Sun provides a strong Java Cryptography page 3

Extension policy as a separate download. Depending on the algorithms used, and the country you reside in, it may not be possible to use Java with Kerberos legally. The most frustrating part about needing the JCE, is when Java cannot use the encryption type specified in a ticket or key, Java acts as though it could not find any ticket or key. This gives very misleading error messages. For some reason, Java will not update the credential cache of a user with the obtained ticked via SASL+GSSAPI. This will not cause any significant problems, but is wasteful, since each repeat authentication requires requesting a new ticket from the KDC when it could have stored and reused the previous ticket. There may be a workaround for this, but it is not well documented.

page 4