Internet DRAFT - draft-perez-abfab-kerberos-preauth-options
draft-perez-abfab-kerberos-preauth-options
ABFAB A. Perez
Internet-Draft University of Murcia
Intended status: Informational J. Howlett
Expires: September 13, 2012 Janet
March 12, 2012
Options for Abfab-based Kerberos pre-authentication
draft-perez-abfab-kerberos-preauth-options-01
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
models 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 13, 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
Perez & Howlett Expires September 13, 2012 [Page 1]
Internet-Draft Abfab-based Kerberos pre-auth March 2012
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of Abfab . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Proposed Models . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. The Kerberos client is the Abfab initiator . . . . . . . . 3
3.2. The Kerberos Client is the Abfab acceptor . . . . . . . . . 4
3.3. Commonalities . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Differences . . . . . . . . . . . . . . . . . . . . . . . . 5
4. EAP-based pre-authentication approaches . . . . . . . . . . . . 5
4.1. EAP pre-authentication . . . . . . . . . . . . . . . . . . 5
4.2. GSS-API pre-authentication . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . . 7
Perez & Howlett Expires September 13, 2012 [Page 2]
Internet-Draft Abfab-based Kerberos pre-auth March 2012
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 alternative models to typical Kerberos
cross-realm operation that build on the Abfab architecture. The goal
of this document is to describe these approaches in the expectation
that this will facilitate and inform further discussion.
2. Use of Abfab
The Extensible Authentication Protocol (EAP) [RFC3748] was originally
defined as an authentication framework for data links (such as PPP
[RFC1661]), building on the AAA frameworks provided by RADIUS
[RFC2865] and Diameter [RFC3588].
Abfab is the application of the EAP and AAA frameworks for
authentication of application-level protocols, through the use of a
Generic Security Services (GSS) mechanism that acts as an EAP lower-
layer: the GSS EAP mechanism [I-D.ietf-abfab-gss-eap].
In the GSS EAP mechanism, the GSS initiator is the EAP peer and the
GSS acceptor is the EAP authenticator. In the canonical case the GSS
acceptor will act as an EAP pass-through, using an AAA protocol to
federate authenticate to a remote AAA/EAP server.
3. Proposed Models
Two models involving the application of Abfab within Kerberos have
been proposed.
3.1. The Kerberos client is the Abfab initiator
In this model a Kerberos client, co-located with the User Agent and
acting as an EAP peer, obtains a Kerberos ticket by using an EAP
credential to authenticate against a foreign realm's KDC that is
Perez & Howlett Expires September 13, 2012 [Page 3]
Internet-Draft Abfab-based Kerberos pre-auth March 2012
acting as an Abfab relying party. A detailed description of this
model can be found in [I-D.perez-abfab-eap-gss-preauth].
The EAP credential is authenticated by the EAP server associated with
the user principal wielding the User Agent. If this ticket is a TGT,
the Kerberos client can subsequently obtain service tickets from the
foreign KDC in the usual way.
In either case, the Kerberos client is able to subsequently request a
Kerberos service ticket from the foreign KDC and authenticate to
Kerberos services within that realm.
The following figure illustrates this model:
User Kerberos EAP
Agent <----------------> KDC <----------------> Server
(EAP over (EAP over AAA)
K5 REQ/REP)
Figure 1
This model can be understood as the application of Abfab to the
Kerberos authentication message exchange.
3.2. The Kerberos Client is the Abfab acceptor
In this model a User Agent, acting as an EAP peer, initiates a
standard Abfab authentication exchange with an Abfab relying party.
A Kerberos client, co-located on the Abfab relying party, obtains a
Kerberos ticket (naming the principal wielding the User Agent) by
using the EAP tokens to authenticate against its KDC.
As in the previous model the EAP credential is authenticated by the
EAP server associated with the user principal wielding the User
Agent.
The following figure illustrates this model:
User Abfab Kerberos EAP
Agent <-------> RP <----------> KDC--------> Server
(Abfab) (EAP over (EAP over AAA)
K5 REQ/REP)
Figure 2
Having an additional actor, this model is more complex than the first
Perez & Howlett Expires September 13, 2012 [Page 4]
Internet-Draft Abfab-based Kerberos pre-auth March 2012
model. However, the relying party and KDC can be understood as a
single EAP authenticator that is split across two entities. Hence,
both entities must share access to the EAP authenticator context
(i.e. authenticator name, MSK, RADIUS keys...).
3.3. Commonalities
These model share the following in common:
o EAP is used to authenticate the user principal.
o The KDC is able to act as a point of authorisation for relying
parties within its realm.
3.4. Differences
These models are different in the following ways:
o In the first model, the KDC must (in the general case) be exposed
to KDC requests from any network location. In the second model,
the KDC only needs to be exposed to trusted Kerberos services.
o In the first model, the Kerberos client must be happy to use the
Kerberos discovery mechanism.
o In the first model, the User Agent must be happy to always use
Kerberos if it is available.
o In the first model, the Kerberos client and KDC must be modified,
but the already deployed relying parties reamain unmodified. In
the second model, the relying parties and the KDC must be
modified.
4. EAP-based pre-authentication approaches
The models described above require of a Kerberos pre-authentication
based on EAP. However, this pre-authentication can be provided by
one of the following two approaches.
4.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] (i.e. returning MORE_PREAUTH_DATA_REQUIRED
error code).
Perez & Howlett Expires September 13, 2012 [Page 5]
Internet-Draft Abfab-based Kerberos pre-auth March 2012
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], which defines the interface between EAP and the EAP lower-
layer.
This approach is applicable to any of the models.
4.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.
This approach is applicable to the first model. However, due the
specific particularities of the second model, this approach is not
easily applicable to it.
5. Security Considerations
To do
Perez & Howlett Expires September 13, 2012 [Page 6]
Internet-Draft Abfab-based Kerberos pre-auth March 2012
6. Informative References
[I-D.lear-abfab-arch] Howlett, J., Hartman, S.,
Tschofenig, H., and E. Lear,
"Application Bridging for
Federated Access Beyond Web
(ABFAB) Architecture",
draft-lear-abfab-arch-02 (work in
progress), March 2011.
[I-D.ietf-abfab-usecases] Smith, R., "Application Bridging
for Federated Access Beyond web
(ABFAB) Use Cases",
draft-ietf-abfab-usecases-01 (work
in progress), July 2011.
[I-D.ietf-abfab-gss-eap] Howlett, J. and S. Hartman, "A
GSS-API Mechanism for the
Extensible Authentication
Protocol",
draft-ietf-abfab-gss-eap-04 (work
in progress), October 2011.
[I-D.perez-krb-wg-gss-preauth] Perez-Mendez, A., Pereniguez-
Garcia, F., Lopez-Millan, G., and
R. Lopez, "GSS-API pre-
authentication for Kerberos",
draft-perez-krb-wg-gss-preauth-01
(work in progress), January 2012.
[I-D.perez-abfab-eap-gss-preauth] Perez-Mendez, A., Lopez, R.,
Pereniguez-Garcia, F., and G.
Lopez-Millan, "GSS-EAP pre-
authentication for Kerberos", draf
t-perez-abfab-eap-gss-preauth-01
(work in progress), March 2012.
[RFC1661] Simpson, W., "The Point-to-Point
Protocol (PPP)", STD 51, RFC 1661,
July 1994.
[RFC2865] Rigney, C., Willens, S., Rubens,
A., and W. Simpson, "Remote
Authentication Dial In User
Service (RADIUS)", RFC 2865,
June 2000.
[RFC3588] Calhoun, P., Loughney, J.,
Perez & Howlett Expires September 13, 2012 [Page 7]
Internet-Draft Abfab-based Kerberos pre-auth March 2012
Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol",
RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht,
J., Carlson, J., and H. Levkowetz,
"Extensible Authentication
Protocol (EAP)", RFC 3748,
June 2004.
[RFC4120] Neuman, C., Yu, T., Hartman, S.,
and K. Raeburn, "The Kerberos
Network Authentication Service
(V5)", RFC 4120, July 2005.
[RFC4137] Vollbrecht, J., Eronen, P.,
Petroni, N., and Y. Ohba, "State
Machines for Extensible
Authentication Protocol (EAP) Peer
and Authenticator", RFC 4137,
August 2005.
[RFC6113] Hartman, S. and L. Zhu, "A
Generalized Framework for Kerberos
Pre-Authentication", RFC 6113,
April 2011.
Authors' Addresses
Alejandro Perez Mendez
University of Murcia
EMail: alex@um.es
Josh Howlett
Janet
EMail: josh.howlett@ja.net
Perez & Howlett Expires September 13, 2012 [Page 8]
