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]