Options for Abfab-based Kerberos pre-authentication
draft-perez-abfab-kerberos-preauth-options-00

Abstract

Kerberos is widely used for authentication within organisations. It is not, however, commonly used for authentication between domains or realms ("cross-realm operation"). Abfab is a new architecture, based on the AAA framework, that provides a mechanism for federating authentication between realms.

AAA protocols are already widely used for federating authentication for network access scenarios today. It has been proposed that Abfab could be used to provide a mechanism yielding cross-realm functionality for Kerberos. This document discusses two alternative approaches with the aim of informing and facilitating discussion.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 04, 2012.

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Kerberos pre-authentication using GSS-API and an EAP mechanism
• 2.1. EAP pre-authentication
• 2.2. GSS-API pre-authentication
• 3. Kerberos pre-authentication using an EAP mechanism
• 4. Security Considerations
• 5. References
• Authors' Addresses

1. Introduction

Kerberos [RFC4120] is a widely deployed system for authentication, being integrated in multiple operating systems and network applications. However, Kerberos is typically only used to manage authentication within the scope of a single realm (typically corresponding to a single organisation). While often supported by implementations, Kerberos cross-realm operation is used relatively infrequently.

The Abfab architecture [I-D.lear-abfab-arch] describes an access management model that enables the application of federated identity within a broad range of use cases. This is achieved by building on proven technologies and widely deployed infrastructures. Some of these use cases are described in [I-D.ietf-abfab-usecases].

This draft considers two new alternative approaches to typical Kerberos cross-realm operation that build on the Abfab architecture. This follows previous discussion about the respective advantages and disadvantages of both approaches.

The goal of this document is to describe these approaches in the expectation that this will facilitate and inform further discussion.

2. Kerberos pre-authentication using GSS-API and an EAP mechanism

The following figure depicts this approach and its interfaces. Two organisations, the user organisation and the resource organisation, are connected using a AAA infrastructure. The user organization has a Kerberos infrastructure deployed to authenticate access to its local services, which is also connected to the AAA infrastructure. Finally, the end user (EU) interacts with the user organisation's KDC to obtain a TGT using the Kerberos protocol.

To do: figure

The KDC acts as an EAP authenticator between the EAP peer (end user) and the EAP server (user organization AAA server). Using the Kerberos pre-authentication interface, EAP frames are exchanged between these actors until the authentication process is completed. If the authentication is sucessful, the end user is provided with the a TGT as usual.

Two alternative approaches for binding EAP frames to this exchange have been proposed.

2.1. EAP pre-authentication

In this approach, Kerberos itself becomes an EAP lower-layer. The most straightforward way to approach this is to define a new EAP-based FAST factor. This FAST factor transports EAP packets between the EU and the KDC, following the multi round-trip procedure described in RFC6113 [RFC6113] (i.e. returning MORE_PREAUTH_DATA_REQUIRED error code).

This alternative is very simple, as EAP interfaces directly with Kerberos, making the architecture more straightforward. It requires the definition of the FAST factor in such a way that implements RFC4137 [RFC4137], which defines the interface between EAP and the EAP lower-layer.

2.2. GSS-API pre-authentication

In this alternative GSS-API is used by the Kerberos client and the KDC to perform pre-authentication. Hence, a pre-authentication mechanism based on the transport of GSS-API tokens is required, such as that proposed by [I-D.perez-krb-wg-gss-preauth]. Such a pre-authentication mechanism provides a generic framework where any GSS-API mechanism can be executed, without further modification to the Kerberos infrastructure.

This alternative introduces an additional layer, the GSS-API, between EAP and Kerberos. The addition of this layer implies a higher complexity of the model, but it also comes with several advantages. The first one is the flexibility it provides. Defining a generic GSS-preauth not only allows performing EAP pre-authentication, but it can be used for any other existing GSS mechanism, and for those to be defined in the future. This implies that using this alternative would serve to integrate Kerberos into any existing federation, not only those based on AAA, just by using a different GSS mechanism instead of GSS-EAP.

Besides, from an design point of view, this alternative takes advantage of the definition and implementation efforts put on the GSS-EAP mechanism of the ABFAB WG and the Moonshot project. That mechanism has already carefully implemented the interfaces defined for an EAP lower-layer.

Finally, as discussed in [I-D.perez-krb-wg-gss-preauth], using this proposal may simplify the generation of the PA-PX-COOKIE, as instead of serializing the whole EAP state machine on each round-trip, it could be possible to exchange GSS-API context handlers.

3. Kerberos pre-authentication using an EAP mechanism

4. Security Considerations

To do

5. References

Authors' Addresses